Walk through a concrete linkage attack: a hospital removes names and publishes records with Age, Gender, ZIP, and Diagnosis, while the commune publishes a public voter list (Name, Age, Gender, ZIP). What can an attacker recover, and what is the residual leak for records that aren't unique?

Question

Accepted Answer

By matching the shared quasi-identifiers (Age, Gender, ZIP), the attacker re-attaches names to most records and learns their diagnosis; even a tie of two candidates still leaks the sensitive value to a 1-of-2 guess.

* Joining two tables on shared quasi-identifiers re-attaches a name to a diagnosis. *
The mechanics, step by step:

Shared QIDs = Age, Gender, ZIP (they appear in both tables). Diagnosis exists only in the hospital release (the sensitive attribute); Name only in the voter list (the direct identifier).
Linkage: join the two tables on {Age, Gender, ZIP}. Any hospital record whose QID combination is unique in the voter list gets exactly one name — and its diagnosis is now attached to a real person.
Typical result: in an 8-record toy hospital release, 6 of 8 records (75%) link to a single name; only one QID combination (e.g. two 28-year-old women in the same ZIP) ties.

The subtle lesson is the residual leak on the tied records: even when two names match, the attacker learns that one of these two women has migraine and the other has anxiety — a 1-of-2 attribute disclosure, far worse than the 1-of-8 uncertainty before linkage. Non-unique does not mean safe.
Tip: "We removed the names" is pseudonymization, not anonymization. The fix is k-anonymity (generalise age into ranges, ZIP into 600*) plus l-diversity on the diagnosis — and verifying no equivalence class is smaller than k before publishing.