Chapter 14 — Privacy foundations

Chapter 14 — Privacy foundations

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Identifying personal data"]
  N2["14.2 Data minimisation"]
  N3["14.3 Reducing linkability"]
  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 Identifying personal data"]
  N2["14.2 Data minimisation"]
  N3["14.3 Reducing linkability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Identifying personal data]
    |
    v
[14.2 Data minimisation]
    |
    v
[14.3 Reducing linkability]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) identify personal data; (2) apply data minimisation; (3) reduce linkability on a shared ledger.

14.1 Identifying personal data

Personal data is any information relating to an identifiable person. For Lantern Hill this includes names, addresses, phone numbers, shift times and, importantly, voucher transactions linked to member codes, because a code can be tied back to a person through the database. Sofia maps where each item is stored and who can see it. She discovers that shift times reveal when a member is away from home, which some members would consider sensitive. Privacy is not only about secrets; it is about people's reasonable expectations of how information about them is used and who can see it.

14.2 Data minimisation

Data minimisation means collecting and keeping only what is needed. Sofia reviews the shift database and proposes removing birth dates, which were collected but never used, and deleting shift notes after a year. On the ledger she keeps only codes and amounts. She also asks whether the shop needs to see member names at the till; it does not, because the wallet proves entitlement. Each removal shrinks what could be leaked or misused. Minimisation is especially important for blockchain systems, because ledger data cannot easily be deleted once it has been written and copied to every node.

14.3 Reducing linkability

Even pseudonymous codes can be linked to people by patterns, such as a member who always spends at the same time each week. Sofia proposes that member codes on the ledger be different from those used in the database, with the link held only in the database under access control. She also suggests letting members use a fresh address each year. NIST IR 8202 notes that transparent ledgers expose transaction patterns, so designs must consider this. These measures reduce, but do not eliminate, linkability. She states the remaining risk plainly in her report for the board to accept or reject.

Worked example

Sofia removes unused birth dates, separates ledger codes from database codes and offers yearly fresh addresses, stating remaining linkability honestly.

Synthetic case. Member data and measures are synthetic; NIST IR 8202 is a real source.

Errors and limits

Assuming pseudonymous codes are anonymous ignores linkage through behaviour patterns.

Exercises

• EX040 — Sensitive pattern. Why can shift times be sensitive? Rubric: 3 = they reveal when a member is away from home;; 2 = absence;; 1 = not sensitive;; 0 = none.
• EX041 — Minimisation step. Name one minimisation step. Rubric: 3 = remove unused birth dates;; 2 = delete old notes;; 1 = collect more;; 0 = none.
• EX042 — Linkability measure. How are ledger codes separated? Rubric: 3 = different codes on the ledger, link held in the database;; 2 = separate codes;; 1 = same codes;; 0 = none.

Synthesis

Mapping, minimising and de-linking data protect members on a shared ledger.

Continue studying — chapter 14 of 40

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