Differential privacy in one paragraph, and where it does not fit

What it is

NIST SP 800-226 describes differential privacy as a mathematical framework that quantifies privacy loss to entities when their data appears in a dataset. The one-paragraph version: a mechanism that answers queries about a dataset is differentially private if its output distribution changes by at most a bounded factor, parameterised by epsilon, when any one person's record is added or removed. The mechanism achieves this by adding calibrated random noise to results, and every answered query consumes part of a privacy budget. The guarantee is a property of the mechanism, not of the data, and it holds whatever else an attacker knows. Implementations exist: Google's differential-privacy repository provides building-block libraries with noise addition primitives and differentially private aggregations, end-to-end frameworks and an accounting library for tracking privacy budget.

Why it matters

Its guarantee holds regardless of auxiliary information and composes across repeated queries, which is exactly where suppression and aggregation give no guarantee at all. NIST SP 800-226 also names privacy hazards: common pitfalls that arise when the mathematics is realised in software.

How to apply

• Fits: releasing aggregate statistics (counts, sums, means, histograms) about a large population, especially when the release is repeated or exposed as a query interface, and when the accuracy loss from noise is acceptable at the population sizes involved.
• Does not fit: record-level data (a customer table cannot be made differentially private and remain a customer table); small groups, where the noise swamps the signal; operations that need exact answers (billing, a person's own data, reconciliation); free text and images; one-off internal analyses where access control plus pseudonymisation is simpler and adequate.
• Use a library rather than adding noise by hand: NIST SP 800-226 states that practitioners should use well-tested implementations provided by libraries rather than implementing the mechanisms themselves, and lists floating-point arithmetic among its privacy hazards.
• Decide epsilon and the total budget per release as a documented product decision; record every release against the budget.
• Keep the raw pseudonymised table and the differentially private release apart; giving both to the same consumers removes the point.

Pitfalls

Choosing a large epsilon to preserve accuracy and calling the result private; NIST SP 800-226 flags as a hazard that large values of epsilon may not provide meaningful privacy. Applying the mechanism per query without tracking the total. Treating it as a substitute for minimisation and retention rather than as a release mechanism for aggregates.