Chapter 4 — Programming I

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 First programs with personal data"]
  N2["4.2 Validating input"]
  N3["4.3 Functions and responsibility"]
  N4["4.4 Testing with fake data"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 First programs with personal data"]
  N2["4.2 Validating input"]
  N3["4.3 Functions and responsibility"]
  N4["4.4 Testing with fake data"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 First programs with personal data]
    |
    v
[4.2 Validating input]
    |
    v
[4.3 Functions and responsibility]
    |
    v
[4.4 Testing with fake data]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write simple programs that handle personal data safely; (2) avoid logging identifiers; (3) validate input to reduce collection errors.

4.1 First programs with personal data

Zara's first programming course uses Python. Her first assignment, a booking script, asks for a patient's name and birth date and prints a confirmation. Prof. Holm points out that her debugging prints include the full birth date, which would end up in logs if the script ran on a server. Logs are often kept longer and protected less than databases. Zara replaces the print with a message that contains only a booking reference, a habit that the EDPB guidance on data protection by design would describe as protecting data by default.

4.2 Validating input

The booking form accepts free text for the reason for the visit. Zara notices that patients type far more than needed, including medications and family history. She changes the form to offer a short list of visit types and a limited free-text field with a clear note on what to include. Validating and limiting input is a programming technique, but it also applies the data minimisation principle in Article 5(1)(c) of the GDPR, which requires personal data to be adequate, relevant and limited to what is necessary.

4.3 Functions and responsibility

As her script grows, Zara splits it into functions: one to collect input, one to validate, one to store. She adds a function that pseudonymises a patient identifier with a keyed hash before it is passed to analytics. The key is kept separately, which matches the GDPR definition of pseudonymisation in Article 4(5). She learns that putting privacy logic in a single function makes it easier to test and harder to forget, and that a function name such as pseudonymise also documents intent for other developers.

4.4 Testing with fake data

Zara's tests use invented patients generated by the script, never real data copied from Pellmore. She writes a test that checks that no log line contains a birth date pattern. Prof. Holm calls this a privacy unit test and asks the class to add one to every assignment. The habit of testing privacy properties automatically will become important later in the verification laboratories, where Zara will test entire systems, but it begins with a few lines in a first-year programming exercise and a commitment never to use real records for development.

Worked example

Zara removes birth dates from debug output, limits free text, isolates pseudonymisation in one function and adds a privacy unit test that scans logs for birth dates.

Synthetic case. The script and patients are synthetic; GDPR Articles 4(5) and 5(1)(c) and EDPB Guidelines 4/2019 are real.

Errors and limits

A keyed hash is pseudonymisation, not anonymisation; anyone with the key can re-link.

Exercises

• EX010 — Debug logging. Why is printing birth dates in debug output risky? Rubric: 3 = logs are kept longer and protected less than databases;; 2 = mentions logs;; 1 = harmless;; 0 = none.
• EX011 — Free text limits. Which GDPR principle does limiting free-text input apply? Rubric: 3 = data minimisation in Article 5(1)(c);; 2 = mentions minimisation;; 1 = names another;; 0 = none.
• EX012 — Privacy unit test. What does Zara's privacy unit test check? Rubric: 3 = that no log line contains a birth-date pattern;; 2 = mentions logs;; 1 = omits;; 0 = none.

Synthesis

Chapter 4 builds safe programming habits. Chapter 5 trains communication.

Continue studying — chapter 04 of 50

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →