Section 2.10

Data Privacy Basics

You promised your participants their data would be kept private, and you meant it. But "I deleted the names" is a much weaker guarantee than it feels like. The people in your rows can often be picked back out from the ordinary details left behind (their age, their town, their sex), and once one row is tied to one person, everything sensitive in that row is exposed. Protecting privacy is a skill, not a checkbox.

Three words that aren't synonyms

These get used loosely and it matters, because they promise different things:

  • Anonymous: the data never contained identifying information and cannot be traced to a person, by you or anyone, even in principle. Truly anonymous data is rare and hard to achieve.
  • De-identified: the obvious identifiers (name, email, exact address) have been removed, but the remaining details might still allow re-identification. This is what most "anonymized" datasets actually are.
  • Pseudonymized: direct identifiers are replaced with a code (participant P037), and a separate, secured key links codes back to people. It's reversible by design, useful for follow-ups, but the data are not anonymous as long as that key exists.

Quasi-identifiers and re-identification

Identifiers come in two kinds. Direct identifiers (name, ID number) point at one person on their own. Quasi-identifiers — age, sex, ZIP code, job, dates — don't single anyone out alone, but in combination they narrow the field fast, and often to one. In the result everyone cites, Latanya Sweeney showed that 87% of Americans were uniquely identified by just their 5-digit ZIP code, date of birth, and sex, three facts on almost every "de-identified" record. Cross-reference them with a public voter roll and the "anonymous" medical data has names again.

That 87% is worth quoting carefully, because it came from the 1990 census. When Philippe Golle repeated the calculation on 2000 census data the figure fell to 63%. Use the lower number; the conclusion survives it intact, since a coin-flip's worth of your participants is still one lookup away from their own name. And the risk climbs with every column you keep: each one multiplies the combinations, so the same high-dimensional geometry that makes nearest neighbors meaningless also makes each person unmistakable.

Below is a "de-identified" table of 30 people: no names, but with the usual quasi-identifiers and a sensitive diagnosis. Choose which columns a snoop is allowed to match on, and coarsen them, to see how many people become uniquely identifiable.

🔎 Re-identification Demo

A row is unique, and so re-identifiable, when nobody else shares its combination of matched columns. Toggle which quasi-identifiers count, and generalize them, and watch the unique rows (red) collapse into safer groups (green).

Match on:
Generalize:
Uniquely identifiable
k-anonymity

unique (k = 1) small group (k = 2–4) well-hidden (k ≥ 5)

k-anonymity and sharing safely

The readout above labeled k is k-anonymity: a dataset is k-anonymous if every person shares their quasi-identifier combination with at least k − 1 others, so no one can be pinned down more precisely than a group of k. Higher k is safer. You raise it by making values less precise:

  • Generalize. Replace exact age with a band, a full ZIP with its region, a birth date with a birth year. Each step merges people into larger, safer groups (you watched k climb above).
  • Suppress. Drop a column entirely, or blank out the one ultra-rare record that can't be hidden any other way.
  • Aggregate or synthesize. Share group summaries instead of rows, or a synthetic dataset that reproduces the statistical structure without any real person in it.

Two habits sit upstream of all of this. Data minimization: don't collect what you don't need; the birth date you never use is only a liability. And consent scope: you may only use and share data in the ways your participants agreed to, which is as much a research-ethics duty as a technical one. When in doubt, share less, generalize more, and keep any re-identification key locked away from the data it unlocks.

What k-anonymity does not protect

k-anonymity guarantees one thing precisely: nobody can be narrowed down past a group of k. It promises nothing about what the group itself gives away. Should all five people in a group share a diagnosis, finding the group finds the diagnosis, and k = 5 has protected nothing anyone cared about. That is the homogeneity attack, and the usual patch is l-diversity, which asks each group to hold at least l genuinely different values of the sensitive column rather than merely k members.

The demo above leaks a milder version of the same thing. Generalize both age and ZIP and all 15 groups hold exactly two people, so k = 2 and every row turns green. Each pair still carries two different diagnoses, though, so a snoop who knows their neighbor is a woman in her twenties in ZIP region 0 has a 50% chance of naming her diagnosis, against the 1 in 6 they would manage by guessing the table's most common one. Stop matching on age altogether and k climbs to 4, yet the odds only fall to 37%. Identity is hidden. The sensitive fact is not.

The modern answer gives up on sanitizing rows. Differential privacy adds calibrated random noise to whatever gets released, in an amount tuned so the result would be nearly as likely whether or not any one person were in the dataset at all. That is a guarantee about every conceivable attacker, including one holding outside information you never thought of, which is exactly what k-anonymity cannot offer. The US Census Bureau used it to protect the 2020 census. You pay in accuracy: the noise is real, small counts suffer most, and somebody has to decide how much privacy to buy.

Removing names is not anonymizing. Ordinary quasi-identifiers (age, sex, ZIP) re-identify most people in combination (63% of Americans on 2000 census data). Aim for k-anonymity by generalizing and suppressing, check that your groups are not all hiding the same sensitive value, prefer aggregate or synthetic data for sharing, collect the minimum, and stay inside the consent you were given.

Why it matters: a privacy breach is more than an untidy file: it's a broken promise to a real person, and it can expose exactly the sensitive facts they trusted you to guard. Decide what's identifying while you write your codebook, minimize at collection, and generalize before you ever share. The precise ethical and legal duties (consent, storage, retention, when confidentiality may be broken) belong to research ethics, and the Ethics course covers them in Privacy & Confidentiality.

Common questions

Should I be using differential privacy?

For a typical thesis dataset, almost certainly not, but it is worth knowing what it is because it is becoming the standard elsewhere. Every technique in this lesson edits the rows and hopes no attacker can undo the edit. Differential privacy abandons that and adds calibrated random noise to whatever gets published, in an amount chosen so that the published result would be nearly as likely whether or not any one person had taken part. That is a mathematical promise covering every possible attacker, including one holding information you never anticipated, and the amount of noise is set by a parameter (usually written ε) that measures how much privacy each release spends. The US Census Bureau protected the 2020 census this way. It earns its keep when many statistics are released from one dataset, or when queries keep arriving; for a single deposited file, minimizing what you collect, generalizing quasi-identifiers, and controlling who gets access will do more real work.

What's the difference between anonymized and pseudonymized data?

Anonymized data cannot be traced back to a person by anyone, even in principle — there's no key and the remaining fields don't re-identify. Pseudonymized data replaces direct identifiers with a code (participant P037) while a separate, secured key still links codes to people; it's reversible by design, which is handy for follow-ups but means the data are not anonymous as long as that key exists. Keep the key stored apart from the data, with access tightly limited, and treat the dataset as identifiable until the key is destroyed.

My dataset is k-anonymous. Is it safe to share?

Safer, not safe. k-anonymity means every person shares their combination of quasi-identifiers with at least k − 1 others, so it bounds how precisely someone can be identified. It says nothing about what their group reveals. If every member of a group carries the same diagnosis, locating the group locates the diagnosis, which is called the homogeneity attack; the usual patch, l-diversity, requires each group to hold several genuinely different values of the sensitive column. Two further gaps are worth checking. The guarantee assumes you correctly listed every quasi-identifier, so one overlooked column (an unusual job title, a rare test date) voids it. And it applies to the table in front of you, not to that table combined with another release of the same people. Confirm the diversity inside your groups, then prefer controlled access over an open file whenever the sensitive column is genuinely sensitive.