Chapter 14 — Privacy foundations

Chapter 14 — Privacy foundations

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Library privacy"]
  N2["14.2 Pseudonymisation"]
  N3["14.3 When encryption helps"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Library privacy"]
  N2["14.2 Pseudonymisation"]
  N3["14.3 When encryption helps"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Library privacy]
    |
    v
[14.2 Pseudonymisation]
    |
    v
[14.3 When encryption helps]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply privacy principles to library data; (2) use pseudonymisation and its limits; (3) decide when encryption supports privacy.

14.1 Library privacy

Libraries have a long tradition of protecting what patrons read. Priya studies Tidewell's privacy policy and applicable data-protection law, identifying principles: collect only needed data, use it only for stated purposes, keep it no longer than necessary and protect it appropriately. Reading history is especially sensitive because it can reveal health, religion or politics. Cryptography supports these principles but cannot replace them; encrypting data that should not have been collected still leaves a risk. She lists which principles each Tidewell system currently meets or misses.

14.2 Pseudonymisation

For a study of branch usage, Grace asks for loan data without identities. Priya replaces card numbers with keyed pseudonyms computed with HMAC, using a key held by the consortium. Unkeyed hashing would fail, because card numbers follow a known format and could be hashed exhaustively. She notes that pseudonymised data is still personal data under many laws, because the key holder can re-identify it, and that rare combinations, such as one patron borrowing unusual books at a small branch, can identify people even without card numbers.

14.3 When encryption helps

Priya maps where encryption supports privacy: TLS keeps reading choices private on the network, database encryption protects against stolen backups, and end-to-end encryption would protect messages between patrons and librarians. Encryption does not help when the consortium itself misuses data or keeps it too long, which is why retention limits and access logs matter. She recommends deleting loan histories after return unless patrons opt in to keep them, which removes risk more effectively than any cipher. Grace takes the deletion proposal to the board for approval.

Worked example

Priya pseudonymises loan data with HMAC under a consortium key, flags re-identification risks, and recommends deleting histories after return by default.

Synthetic case. Tidewell's data and study are invented.

Errors and limits

Pseudonymised data can often be re-identified. Encryption does not prevent misuse by authorised holders.

Exercises

• EX040 — Sensitive reading. Why is reading history especially sensitive? Rubric: 3 = it can reveal health, religion or politics;; 2 = personal;; 1 = not sensitive;; 0 = none.
• EX041 — Unkeyed hashing. Why does unkeyed hashing of card numbers fail? Rubric: 3 = known format allows exhaustive hashing and matching;; 2 = guessable;; 1 = it works;; 0 = none.
• EX042 — Default deletion. What default does Priya recommend for loan histories? Rubric: 3 = delete after return unless patrons opt in;; 2 = delete;; 1 = keep;; 0 = none.

Synthesis

Privacy depends on minimisation and purpose limits; cryptography such as keyed pseudonyms and encryption supports, but cannot replace, those principles.

Continue studying — chapter 14 of 40

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →