Running a per-element LINDDUN pass over a transit card tap ledger, which threats dominate and where?

## Why per-element, and what the elements are LINDDUN's value comes from being systematic: rather than brainstorming privacy concerns, you walk each element of the system model and ask which of the seven threat types apply to *that* element. Coverage becomes visible — an unexamined element × type pair is an empty cell somebody can point at — and the output is reviewable by someone who was not in the room. For a city transit smartcard system, the elements are: - the **rider** (the data subject in the model), - the **tap event flow** from gate reader to the fare backend, - the **tap and fare ledger** where every tap is stored under a card number, - the **analytics process** that produces journey and occupancy statistics. ## The mapping table The classic LINDDUN mapping restricts which threat types apply to which kind of element: | Element | Linkability | Identifiability | Non-repudiation | Detectability | Disclosure | Unawareness | Non-compliance | | --- | --- | --- | --- | --- | --- | --- | --- | | Data store | x | x | x | x | x | | x | | Data flow | x | x | x | x | x | | x | | Process | x | x | x | x | x | | x | | Data subject / external entity | x | x | | | | x | | The shape matters more than memorising the cells. **Unawareness only lands on the person**, because it describes what the subject understands and can control, which is not a property a database can have. Conversely, non-repudiation, detectability, disclosure and non-compliance are properties of how the system handles data, so they do not attach to the human element. ## What dominates on this system **Linkability on the ledger.** The card number is stable across years of travel. Every tap under it joins into one series, which is a movement history: where this person enters and leaves the network, at what times, how often, and with which other card taps in a repeated correlation. This threat is present even if nobody in the organisation ever tries to name the rider, and it is the one that survives every access control you put in front of the data, because the linkage is a property of the stored schema rather than of who reads it. **Identifiability as the escalation.** The card number is a pseudonym, not anonymity. It becomes identifying at the first join with an identified record: a top-up paid with a named payment card, a registered concession or student card, a lost-card replacement tied to a customer record, or — with no join at all — a daily 07:40 tap at one residential station and a 08:20 tap at one office station, which is a home-and-work pair narrow enough to name a person. **Unawareness on the rider.** The rider was told the card is anonymous because it carries no name. That framing is false in the way that matters, and the gap between the rider's understanding and what the ledger supports is the unawareness threat. **Detectability on the flow and ledger.** Even without reading a trip, being able to tell that a particular card was active on a given day is a harm in itself for some riders — presence at a location on a date, inferred purely from the existence of a record. **Non-compliance on the store and the analytics process.** The stated policy might say taps are kept for fare settlement and dispute handling; if the analytics process reads a multi-year window for planning purposes, the processing has drifted from the stated purpose and the retention that supports it. ## Getting the adversary right The attacker position changes which threats are leading. Here, take an **insider analyst with legitimate query access** to the ledger — planning staff whose job is to run route analyses. Under that adversary, disclosure to an unauthorised outsider is not the top threat; it is already assumed that this person can read the data. What matters is that the data they are entitled to read is *linkable*, so a legitimate route query is one join away from a movement profile for an individual. Threat models that assume only an anonymous external attacker systematically miss this, and it is the single most common reason a privacy pass on an analytics platform comes back empty. ## Practical discipline Two habits keep the pass honest. First, walk elements in a fixed order and record every cell you consider, including the ones you dismiss and why — a dismissal with a reason is a finding, an absence is not. Second, follow the derived copies: exports to a planning warehouse, caches, and backups are elements too, and linkability that was scoped away in the primary ledger often survives untouched in them.