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 identified from the ordinary details left behind: their age, their town, their sex. Once one row is tied to one person, everything sensitive in that row is exposed.
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. Anonymous data in this strict sense 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 best-known result, 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.
Quote that 87% 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 still holds, since nearly two thirds of people are still one lookup away from their own name. The risk also 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 unique.
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 no other row shares its combination of matched columns. Toggle which quasi-identifiers count, and generalize them, and watch the unique rows (red) merge into larger groups (orange, then green).
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 narrowed down to a group smaller than 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 come before 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: no one can be narrowed down to a group smaller than k. It promises nothing about what the group itself reveals. If all five people in a group share a diagnosis, finding the group reveals the diagnosis, and k = 5 has not protected the sensitive information. That is the homogeneity attack. The usual patch is l-diversity, which requires each group to hold at least l different values of the sensitive column, not merely k members.
The demo above shows a milder version of the same problem. Generalize both age and ZIP and all 15 groups hold exactly two people, so k = 2 and no row is unique any more. Each pair still has two different diagnoses, though. A snoop who knows their neighbor is a woman in her twenties in ZIP region 0 has a 50% chance of naming her diagnosis. Guessing the table's most common diagnosis would succeed only 1 time in 6. Stop matching on age altogether and k climbs to 4, yet the odds only fall to 37%.
A newer approach stops editing rows altogether. 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. The guarantee covers every conceivable attacker, including one holding outside information you never thought of, and k-anonymity cannot offer that. The US Census Bureau used it to protect the 2020 census. The cost is accuracy: the noise is real, small counts suffer most, and someone has to decide how much accuracy to give up for how much privacy.
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, and check that your groups are not all hiding the same sensitive value. For sharing, prefer aggregate or synthetic data. Collect the minimum, and stay inside the consent you were given.
Why it matters: a privacy breach breaks a promise to a real person, and it can expose exactly the sensitive facts they trusted you to guard. Unlike an untidy file, it cannot be cleaned up afterward. 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 you should know 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 instead adds calibrated random noise to whatever gets published. The amount is 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. 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 is most useful 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 protect people more.
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 it 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 has the same diagnosis, locating the group reveals the diagnosis. This is called the homogeneity attack. The usual patch, l-diversity, requires each group to hold several different values of the sensitive column. Check two further gaps. 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, and prefer controlled access over an open file whenever revealing the sensitive column could harm someone.