Anonymization and Re-Identification: Why Removing Names Is Not Enough
📑 On this page
- A concrete example: location traces
- Direct identifiers
- Quasi-identifiers
- Auxiliary information
- Pseudonymization
- Generalization and suppression
- K-anonymity
- Linkage attacks
- Membership inference
- High-dimensional data
- Re-identification testing
- Controlled access
- Synthetic data
- Differential privacy
- Context can change
- Governance
- Prefer aggregates when rows are unnecessary
- Knowledge check
- The one idea to remember
Deleting a name column does not necessarily make a dataset anonymous.
People can be recognized through combinations of facts and information available elsewhere.
Anonymization is a claim that people cannot reasonably be identified in the released data context; re-identification reconnects records to identities using direct or indirect clues.
That claim depends on the data, attacker, auxiliary information, access conditions, and future releases.
A concrete example: location traces
A dataset replaces names with random IDs but keeps dated location points.
An observer knows where one person lives and works. Matching night and daytime locations may isolate one trace. Additional public posts can confirm it.
No name appeared in the release, yet the movement pattern acted as a fingerprint.
Direct identifiers
Direct identifiers explicitly name or contact a person:
- full name,
- email,
- phone number,
- account number,
- government identifier,
- and exact address.
Removing or tokenizing them is useful, but it handles only the easiest linkage path.
Quasi-identifiers
Quasi-identifiers are fields that may identify someone in combination:
- age,
- postcode,
- job,
- rare diagnosis,
- dates,
- location,
- household structure,
- or event sequence.
Each field may look harmless alone. Their intersection can be unique.
Auxiliary information
Attackers do not examine a dataset in isolation. They can combine it with:
- public records,
- social media,
- leaked databases,
- news stories,
- purchased data,
- and their own knowledge.
Risk analysis should model realistic external information, not assume the released table is the only source.
Pseudonymization
Replacing identities with stable codes is pseudonymization, not necessarily anonymization.
Pseudonyms are useful for limiting routine exposure and separating systems. If a mapping exists or records remain linkable, authorized or unauthorized parties may reconnect them.
Protect mappings separately and limit who can join across datasets.
Generalization and suppression
Generalization reduces precision:
- exact age becomes an age band,
- timestamp becomes month,
- postcode becomes region.
Suppression removes high-risk fields or rare records. Both reduce re-identification risk but also reduce analytical value.
The right balance depends on the intended analysis.
K-anonymity
A dataset has k-anonymity for selected quasi-identifiers when each combination appears in at least k records.
This reduces uniqueness but has limits. If everyone in a group shares the same sensitive diagnosis, membership can still reveal it. It also may not resist attackers with substantial background knowledge.
Related models attempt to improve diversity or distribution properties, but none is a universal guarantee.
Linkage attacks
A linkage attack matches patterns across datasets.
Exact matching is not required. Probabilistic linkage can use spelling similarity, dates, household relationships, and rare event combinations. Repeated releases make linkage easier because overlapping information accumulates.
Evaluate the release programme, not only one snapshot.
Membership inference
Sometimes the sensitive fact is whether a person appears in a dataset at all.
Presence in a study, clinic cohort, or disciplinary dataset can reveal information even if individual values are hidden. Aggregate statistics can also leak membership when groups are small or many related queries are allowed.
High-dimensional data
Mobility, browsing, purchase, genetic, and behavioural datasets contain many dimensions. Sparse combinations tend to be distinctive.
Removing a few obvious columns may leave most uniqueness intact. Rich data often requires controlled access, aggregation, synthetic approaches, or formal privacy methods rather than public row-level release.
Re-identification testing
Test with a realistic adversary:
- available auxiliary data,
- likely knowledge,
- computing resources,
- incentives,
- and permitted access.
Measure uniqueness, linkage success, confidence, and harm. Independent review can challenge assumptions made by the releasing team.
Do not perform tests in ways that expose real people unnecessarily.
Controlled access
Risk can be reduced through the environment:
- approved researchers,
- purpose restrictions,
- secure workspaces,
- query limits,
- output review,
- audit logs,
- and penalties for misuse.
Access controls do not transform data mathematically, but they reduce realistic attack opportunity and can preserve more utility.
Synthetic data
Synthetic records are generated to resemble patterns in source data.
They are not automatically private. A generator may reproduce rare records or leak training examples. Evaluate memorization, similarity to real individuals, downstream utility, and disclosure risk.
Differential privacy
Differential privacy provides a formal bound on how much one person's inclusion can influence a randomized output.
It is especially useful for aggregate statistics or trained models, with a measurable privacy budget. It does not solve poor access control, excessive source collection, or all group-level harms.
Context can change
A release considered low risk today may become linkable after a new public dataset or future release appears.
Record assumptions, review high-value releases, limit unnecessary persistence, and plan withdrawal where possible. Public release may be impossible to reverse.
Governance
Define:
- who approves release,
- acceptable residual risk,
- intended users and purposes,
- prohibited linkage,
- monitoring,
- incident response,
- and review dates.
Anonymization is a risk decision with accountable evidence, not an automatic export option.
Prefer aggregates when rows are unnecessary
If users need a trend, publish the trend rather than a person-level table. Minimum group sizes, query controls, and carefully designed statistical release mechanisms can preserve the intended insight while removing many linkage opportunities.
Start from the question the release must answer. Row-level detail should require a specific justification, a stronger access environment, and evidence that safer representations cannot meet the purpose.
Knowledge check
- How do quasi-identifiers differ from direct identifiers?
- Why is pseudonymization not necessarily anonymization?
- How can repeated releases increase linkage risk?
- What does controlled access contribute?
- Why must synthetic data still be tested?
The one idea to remember
De-identification is not column deletion. Anonymization must withstand realistic linkage using unique patterns, auxiliary information, repeated releases, and the access context while balancing analytical utility and accountable residual risk.