Start with the failure
In 2006 Netflix published a hundred million film ratings so that researchers could compete to improve its recommendations. Names were stripped out. Two years later Arvind Narayanan and Vitaly Shmatikov showed that if you knew roughly when a person had rated a handful of films — from their public IMDb reviews, say — you could find them in the released data and read everything else they had watched.
Nothing in that release was a mistake in the ordinary sense. No identifier was left in by accident. The lesson is harder than that: a person's behaviour is itself an identifier. Enough ratings, enough locations, enough purchases, and the pattern belongs to one person and no other.
That is the problem I have spent my research life on, and it is why I do not trust the word anonymised on its own.
The guarantee
Differential privacy, set out by Cynthia Dwork and colleagues in 2006, turns privacy from a property of a dataset into a property of a computation. It asks a single question: if I take you out of the data entirely, does the answer change?
Formally, a mechanism is ε-differentially private if for any two datasets that differ by one person, and any possible output, the probability of producing that output changes by at most a factor of e^ε. In plain language: whatever the system publishes, it would have been almost exactly as likely to publish it if you had never been in the data at all.
That is why it is a real guarantee and k-anonymity was not. It makes no assumption about what an attacker already knows. Someone can arrive holding your IMDb profile, your friends' records, next year's dataset — the bound still holds.
ε is the knob. A small ε means the outputs barely shift when you are added or removed, so very little about you leaks, and the answers are noisier. A large ε means sharper answers and a weaker promise. There is no universally correct value, which is the honest and uncomfortable part: ε is a policy decision wearing mathematical clothes.
How it is actually done
The mechanism is usually noise. You work out the sensitivity of the query — the most its answer could change if one person were swapped out — and you add random noise scaled to that. Count how many people in a city have a condition, and one person changes the count by one, so you add noise of about that size. The published number is wrong by a little and useless for identifying anyone.
Two consequences follow, and they are what makes the engineering hard. First, privacy composes: every query you answer spends part of a fixed budget, and once it is spent you must stop. Second, noise that is tolerable on a count of a million is devastating on a count of four. Differential privacy is kindest to large populations and hardest on small ones — which is exactly the opposite of where the sensitivity usually lies.
Where the noise is added matters too. In the central model a trusted curator holds the raw data and releases private answers, which is how the 2020 United States Census was published. In the local model your device perturbs your data before it leaves, so nobody ever holds the truth — which is how Apple and Google collect usage statistics. Local is a stronger promise and a far worse deal on accuracy.
Where my own work sits
Recommenders are the hard case. A recommendation is a statement about one person by construction, so the noise lands exactly where the usefulness lives. My thesis question was narrow and practical: how much privacy can you buy before the recommendations stop being worth making?
The answers, across these papers, were that it depends on where in the pipeline you spend the budget. Perturbing the released data is the blunt approach. Spending the budget inside the model — on the training step, on a compact sketch of a user's history, or on a generator that makes synthetic data for everyone downstream — buys more utility for the same ε. Combining differential privacy with cryptography lets you avoid trusting a central server at all, at the cost of a heavier protocol.
The most recent work moves the question onto sequence models, where a recommendation depends on the order of what you did, not just the set. Order is more identifying than people expect.
- Utility-based differentially private recommendation systemBig Data 9(3), 203-218, 2021
- Privacy preserving hybrid recommender system based on deep learningTurkish Journal of Electrical Engineering and Computer Sciences 29(5), 2385, 2021
- Privacy preserving bloom recommender system2021 International Conference on Computer Communication and Informatics, 2021
- Confluence of Cryptography and Differential Privacy: A Hybrid Approach for Privacy Preserving Collaborative FilteringProceedings of the International Conference on Paradigms of Communication, 2022
- Elevating privacy: A differential privacy infused approach to GAN for robust data synthesis for deep learning modelsAdvanced Computing and Communications Conference, pp. 267-278, 2024
- Privacy-Preserving Sequential Recommendation: Enhancing User Privacy with Differentially Private RNNs, GRUs, and Transformers2025 3rd International Conference on Advancements in Electrical, Electronics, 2025
What to take away
If you remember three things: anonymisation is not a property you can check by looking at a table; differential privacy bounds what any output can reveal, no matter what the attacker knows; and the cost is always accuracy, so the interesting question is never whether to use it but where in the system to spend the budget.
If you are starting a project, start by asking what the smallest group in your data looks like. That number will tell you more about whether this will work than any choice of ε.
What to read next
Outside work, not mine. Each title links to a Google Scholar search, which will find you whichever version is open access.