Chapter 10 — Ethics and authorized practice

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Authorisation"]
  N2["10.2 Scope"]
  N3["10.3 Found something?"]
  N4["10.4 Disclosure"]
  N5["10.5 Privacy"]
  N6["10.6 Honesty"]
  N7["Codes of conduct"]
  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 Authorisation"]
  N2["10.2 Scope"]
  N3["10.3 Found something?"]
  N4["10.4 Disclosure"]
  N5["10.5 Privacy"]
  N6["10.6 Honesty"]
  N7["Codes of conduct"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 Authorisation]
    |
    v
[10.2 Scope]
    |
    v
[10.3 Found something?]
    |
    v
[10.4 Disclosure]
    |
    v
[10.5 Privacy]
    |
    v
[10.6 Honesty]
    |
    v
[Codes of conduct]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) distinguish authorised from unauthorised testing; (2) follow responsible disclosure; (3) respect privacy of users; (4) apply professional codes to student projects.

10.1 Authorisation

Testing systems without permission is unethical and often illegal, even to "help". Lena tests only CampusEats' test environment, under written permission from the society and Grace.

The permission names what may be tested, by whom and when, and Lena keeps a copy with her notes. Good intentions do not change the law or the harm an unplanned test can cause, such as slowing a live service at lunchtime or exposing data. If a test seems useful but is not covered, she asks first.

10.2 Scope

Permission lists systems, time and methods. The payment provider's systems are out of scope; Lena never tests them.

Lena reads the provider's terms and confirms that testing its systems requires the provider's own permission. When a test needs to involve payments, she uses the provider's sandbox with test cards, which is designed for that purpose. Methods matter too: the permission allows functional and configuration testing but not load testing, which could disrupt the shared hosting platform. Anything unclear is settled in writing first.

10.3 Found something?

If Lena finds a flaw in another system, such as a café's own website, she reports it through the university security office rather than probing further.

She records what she noticed, when and how, without trying to confirm it further, and lets the office contact the owner. Probing a system without permission, even to prove a point, could break the law and damage trust in the society's work. The office then tells her whether any follow-up is needed, and she keeps a note of the outcome.

10.4 Disclosure

Flaws in open-source packages used by CampusEats are reported privately to maintainers, with time to fix before publication.

The report describes the affected versions, the impact and a suggested fix, and Lena agrees a date with the maintainer before anything is published. If the maintainer does not respond, she asks Grace for advice rather than publishing early. CampusEats meanwhile applies its own temporary mitigation if one is possible, such as disabling the affected feature. Lena keeps all messages with the maintainer, so the timeline can be shown later.

10.5 Privacy

Order histories reveal habits and dietary needs. Developers access real data only when needed and log their access.

For most development work, the society uses synthetic orders that look realistic but describe no real student. When real data is needed, for example to investigate a failed payment, access is granted for that task only, the developer notes the reason and the log is reviewed monthly. Dietary information is treated as especially sensitive because it can reveal health or religious details.

10.6 Honesty

Students must not overstate findings or hide mistakes; the society's incident notes describe the token leak honestly.

The notes state what happened, when, the effect and what was changed, without blaming the developer who pushed the token. An honest record lets others learn from the mistake, and it builds trust with the university and the payment provider. Lena applies the same standard to her own reports: she states the limits of each test and marks results she could not reproduce.

Codes of conduct

Professional codes such as those of computing societies stress public good, honesty and competence. The developer society adopts a short code: test only with permission, protect user data, report problems, and admit mistakes. New members agree to it when they join, and it is discussed at the first meeting each term.

When mistakes happen

If someone breaks a rule by accident, such as viewing real data without need, they report it and the society reviews how to prevent it. A blame-free approach encourages honest reporting.

Record keeping

Permission letters and scope documents are stored with the project files.

Worked example

A friend asks Lena to check whether a rival society's app has the same session-cookie problem. She declines, explaining that she has no permission, and suggests the friend tell that society about the general issue.

Synthetic case. Situations are synthetic.

Errors and limits

Laws on computer misuse differ by country; when unsure, ask before acting.

Exercises

• EX028 — Scope contents. What does testing permission specify?
  Show marking criteria

  Rubric: 3 = systems, time, methods; 2 = two; 1 = one; 0 = none.
• EX029 — Rival app. Why did Lena decline to check the rival app?
  Show marking criteria

  Rubric: 3 = no permission; 2 = partial; 1 = vague; 0 = none.
• EX030 — Privacy rule. How is developer access to real data controlled?
  Show marking criteria

  Rubric: 3 = only when needed; logged; 2 = partial; 1 = vague; 0 = none.

Synthesis

Act only with permission, disclose responsibly and protect users' privacy.

Continue studying — chapter 10 of 40

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →