When Math Saves Our Privacy
On 18 June 2026 I joined ing.tonic., the after-hours “out of office” talk series run by the Department of Information Engineering at the University of Padova (UNIPD). The format is deliberately informal: four meetups at a bar, an aperitivo in hand, tackling topics “we’d like to know more about” — proof that engineering is not so far from everyday life.
This evening’s session, “Anonimi ma identificabili: quando la matematica salva la nostra privacy” (“Anonymous but identifiable: when math saves our privacy”), was led by Francesco Silvestri, professor of Big Data Computing and Computer Architecture at the department. The setting was Arcella Bella in Parco Milcovich, Padova — a community space, not a lecture hall.
The core question of the night: how anonymous is our data, really? And the surprisingly elegant answer from the world of mathematics: differential privacy.
Anonymous but Identifiable
The talk opened with a sobering truth: deleting names and surnames is rarely enough to protect anyone. Through real and sometimes startling examples — from New York City taxi trip records to “anonymized” medical datasets — Silvestri showed how seemingly harmless data can reveal identities, habits, and deeply personal information.
The reason is quasi-identifiers. A record stripped of your name still carries your ZIP code, birth date, gender, the route of your taxi ride, or the timestamp of a hospital visit. Cross-reference enough of those attributes against a public dataset and re-identification becomes trivial. Anonymization that only removes the obvious fields is a comforting illusion.
This is the same class of risk I cover in my work on EU data residency and digital sovereignty and confidential computing: protecting data at rest and in transit is necessary, but it does not address what can be inferred from the data you choose to publish.
The Idea: Two Almost-Identical Datasets
Differential privacy starts from a beautifully simple thought experiment. Take two datasets that are nearly identical — they differ by exactly one person. If an analysis of the two datasets produces essentially the same answer, then no observer can tell whether your record was included. Your participation becomes undetectable.
To achieve this, differential privacy applies noise modification: it injects carefully calibrated random noise into the data or the query result. The noise is the protection. Tune it correctly and an attacker cannot reverse-engineer any single contribution, yet the overall statistic remains useful.
The Coin Flip: Randomized Response
The most intuitive mechanism Silvestri demonstrated is randomized response, a technique that predates computers (it was invented for sensitive surveys in the 1960s).
Imagine you want to measure how many people in a group did something embarrassing or risky, without anyone having to admit it directly. Each person flips a coin in private:
- 50% of the time, they answer truthfully.
- 50% of the time, they give a random answer.
Because half the responses are pure noise, no individual answer can be trusted — plausible deniability is built in. But here is the magic: across many people, the randomness averages out. The aggregate signal is real, and you can mathematically subtract the known bias of the coin to recover an accurate estimate.
The error shrinks as the number of participants grows — the more people you have, the more the true signal emerges. The noise protects the individual without distorting the collective result.
This is exactly why Apple uses the coin-flip technique to estimate which emoji and features people use across hundreds of millions of devices: it learns the aggregate trend while never seeing any one person’s choice.
Many Algorithms for Many Problems
There is no single differential privacy algorithm. Randomized response is just the friendly entry point. Different problems — counting, averages, histograms, machine learning training, location analytics — call for different mechanisms (Laplace noise, Gaussian noise, the exponential mechanism, and more). The unifying principle is the same: we can play with the noise.
That tunability is the whole point, and it leads directly to the central tension of the field.
The Privacy-Utility Trade-Off
Extracting information from data and protecting the people in it pull in opposite directions:
- More noise → less utility. The data is safer but blurrier and less useful.
- Less noise → less privacy. The analytics are sharper but individuals are more exposed.
Differential privacy makes this trade-off explicit and measurable through a privacy budget (commonly denoted epsilon). Instead of hoping anonymization “feels safe”, you choose a quantifiable level of protection appropriate to the sensitivity of the data and the risk you are willing to accept. This is a far stronger footing than the binary “anonymized vs. not” thinking that fails in practice.
A lighter-weight cousin is k-anonymity, which guarantees each record is indistinguishable from at least k − 1 others. It is simpler and cheaper than full differential privacy, but offers weaker guarantees — a reasonable choice for some datasets, insufficient for others.
Where It Shows Up in the Real World
The talk grounded the theory in production systems and active research:
- Apple — randomized response to estimate emoji and feature usage at scale.
- OpenDP and similar libraries — bringing rigorous differential privacy to analysts and engineers.
- Mobility research — differential privacy applied to movement and location data, a notoriously re-identifiable category.
- National statistics — agencies publishing population data with formal privacy guarantees.
The LLM Angle: Models Can Leak Their Training Data
One point resonated strongly with my own work on AI security and AI model governance. An adversary can ask questions of a large language model and extract information about how it was built — including hints about the data it was trained on.
This is the domain of membership inference and model extraction attacks: by probing a model carefully, an attacker can sometimes determine whether a specific record was in the training set, or reconstruct fragments of sensitive training data. Differential privacy is one of the strongest defenses here — differentially private training (DP-SGD) bounds how much any single training example can influence the final model, capping what an attacker can ever recover. It connects directly to how I think about protecting models and data at the edge and content provenance and trust.
Four Pillars of Protecting Privacy
Silvestri closed by zooming out from the math. Real privacy protection, he argued, rests on four complementary pillars:
- Regulation — laws like the GDPR that set the rules of the game.
- Design — privacy built into systems from the start, not bolted on afterward.
- Methodologies — mathematical techniques like differential privacy that provide provable guarantees.
- Technologies — the security stack that enforces it all (encryption, isolation, confidential computing).
And a fifth, uncomfortable consideration he left us with: our own behavior. When an app is free, what are we actually paying with? The most elegant mathematics in the world cannot protect data we hand over without a second thought.
Key Takeaways
- Removing names is not anonymization. Quasi-identifiers make re-identification easy — NYC taxi trips and “anonymized” medical records are cautionary tales.
- Differential privacy adds intelligent noise. Two datasets differing by one person should yield the same answer, hiding any individual’s participation.
- Randomized response is the gateway concept. The coin flip gives plausible deniability per person while preserving the aggregate signal — the error shrinks as the crowd grows.
- Privacy and utility are a tunable trade-off. A privacy budget (epsilon) makes the balance explicit instead of guessing.
- LLMs can leak their training data. Differentially private training is a principled defense against membership inference and model extraction.
- Math is necessary but not sufficient. Regulation, design, technology, and personal behavior all have to work together.
A genuinely curious, formula-free evening that made a hard topic feel close to home — exactly what the ing.tonic. series sets out to do.
Resources
- ing.tonic. / UNIPD — upto.dei.unipd.it — Department of Information Engineering, University of Padova
- OpenDP — Open-source tools for differential privacy
- Google’s Differential Privacy libraries — Production differential privacy
- The Algorithmic Foundations of Differential Privacy — Dwork & Roth (the canonical reference)
- Confidential Computing in 2026 — Protecting data in use
- OWASP Top 10 for LLM Applications — AI security risks including data leakage
