Chapter 10 — Engineering ethics and safety
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Professional duties"]
N2["10.2 Privacy"]
N3["10.3 Accessibility"]
N4["10.4 Authorisation"]
N5["10.5 Honesty"]
N6["Data minimisation"]
N7["Fair access"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Professional duties"]
N2["10.2 Privacy"]
N3["10.3 Accessibility"]
N4["10.4 Authorisation"]
N5["10.5 Honesty"]
N6["Data minimisation"]
N7["Fair access"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Professional duties]
|
v
[10.2 Privacy]
|
v
[10.3 Accessibility]
|
v
[10.4 Authorisation]
|
v
[10.5 Honesty]
|
v
[Data minimisation]
|
v
[Fair access]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) apply professional ethics to endpoint work; (2) protect patron privacy; (3) consider accessibility and harm.
10.1 Professional duties
Engineers owe care to the public. At Fernhill, the public are patrons, many of whom rely on library PCs for job applications and benefits.
For Mateo the duty is concrete. A patron applying for a job may have typed personal details on a library PC; protecting those details is part of the engineering, not an extra. Designs that stop working too often would also fail those patrons, since many have no other computer. Both the security and the reliability of the service are owed to them.
10.2 Privacy
The project aims to stop personal data being left behind. It must not create new privacy risks, such as logging what patrons browse. Logs record system events, not content.
Mateo writes down what each log records and checks that none of it identifies a patron or the content of their session. Restore results, durations and blocked installation attempts are enough. The data protection officer reviews the list. If a future feature needs more data, the question goes back to her before any code is written.
10.3 Accessibility
Some patrons use screen readers and magnifiers. A strict design that blocks these tools would harm them. Requirements must include accessibility.
Mateo met patrons who rely on these tools at the Central branch and tested the application control rules on a lab PC with the same software installed. Two tools were blocked by the first draft and were added to the approved set. Accessibility is checked in every release test, not just once, because a change to another rule can break it unexpectedly.
10.4 Authorisation
Mateo works only on Fernhill systems with Marta's written agreement and tests on lab PCs, not in-use machines.
Testing on lab PCs means a mistake affects nobody using the library. When a test needs a branch PC, Mateo asks Marta, schedules it outside opening hours and records what he did. The written agreement protects him as well as Fernhill: if something goes wrong, it shows that he acted within what was allowed. Work outside the agreement, however well meant, is not part of the project.
10.5 Honesty
Reports state limitations and do not overclaim security.
Mateo's reports describe what was tested, what was found and what remains uncertain. A claim such as the PCs are secure is avoided; instead he writes which risks the design reduces, by how much on the evidence, and which it does not address. Dr Novak checks reports for overclaiming and asks him to remove words that promise more than the evidence shows. Honest limits help Fernhill decide where to spend effort next, and they protect his credibility when something goes wrong later.
Data minimisation
Mateo applies data minimisation: collect only what the design needs. Restore success, duration and installation attempts are enough to run and improve the service. Patron identities, browsing history and documents are never collected. When in doubt, he asks Fernhill's data protection officer.
He records these decisions in the project's ethics notes, reviewed each term by Dr Novak.
Fair access
Public PCs often serve people without other internet access. A design that causes frequent outages or confusing restrictions harms them most, so reliability and clear notices are ethical as well as technical goals.
Ethics review
Dr Novak reviews the project's ethics notes each term, checking privacy, accessibility and authorisation decisions.
Authorisation in practice
Marta's written agreement lists what Mateo may do: configure lab PCs, read restore and event logs, and propose changes. Changes to branch PCs need Marta's approval.
Worked example
During design, a colleague suggests recording screenshots to detect misuse. Mateo refuses on privacy grounds and proposes logging only installation attempts and restore results.
Synthetic case. Synthetic.
Errors and limits
Security designs can harm the people they protect if privacy and accessibility are ignored.
Exercises
- EX028 — Privacy boundary. What may logs record? Rubric: 3 = system events, not content; 2 = partial; 1 = vague; 0 = none.
- EX029 — Accessibility. Why include accessibility in requirements? Rubric: 3 = patrons use assistive tools; 2 = partial; 1 = vague; 0 = none.
- EX030 — Screenshot idea. How did Mateo respond to the screenshot suggestion? Rubric: 3 = refused; log installs and restores only; 2 = partial; 1 = vague; 0 = none.
Synthesis
Ethics shapes what a secure design may and may not do.
Continue studying — chapter 10 of 50
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →