Differential privacy is one of the most mathematically rigorous frameworks ever applied to data release. It comes with a proof. It comes with a parameter. That parameter is called epsilon, and the choice of its value is where the rigor often stops and the politics begin.
In 2026 the three most-cited real-world deployments of differential privacy remain Apple's on-device telemetry system, Google's RAPPOR protocol and the U.S. Census Bureau's 2020 Decennial Census disclosure avoidance system. Each made epsilon choices that the academic community has contested at length. Understanding why requires a precise grip on what epsilon is, how it compounds across queries and what it means for the populations whose data is inside the mechanism.
This review covers the technical ground that product teams and privacy engineers need to evaluate these deployments honestly.
What Epsilon Actually Measures
The formal definition of epsilon-differential privacy states that a randomized mechanism M satisfies epsilon-DP if for any two neighboring datasets D and D' differing in exactly one record, and for any output set S, the probability ratio of M(D) falling in S versus M(D') falling in S is bounded by e raised to the power of epsilon.
In plain terms: epsilon controls how much any single person's data can change the output distribution of the mechanism. Small epsilon means the mechanism's output looks nearly identical whether or not your record is included. Large epsilon means your data has measurable influence on the result.
The canonical mental model is that epsilon represents a privacy loss budget. Spend less of it and individuals are better protected. Spend more of it and the data is more useful but the privacy guarantee weakens exponentially. Because the bound is expressed as e^epsilon, the difference between epsilon equals 1 and epsilon equals 10 is not linear. It is a factor of roughly 22,000 in the likelihood ratio.
Practitioners sometimes anchor on epsilon values in the single digits as "reasonable." The academic literature is considerably more skeptical. Cynthia Dwork and Aaron Roth, whose 2014 monograph "The Algorithmic Foundations of Differential Privacy" remains the canonical reference, noted that epsilon values above roughly 1 begin to lose the intuitive guarantee that an adversary learns almost nothing new about any individual. That monograph is freely available at nowpublishers.com.
The field does not have a single agreed threshold. That absence of consensus is precisely the epsilon problem.
The Composition Theorem in Practice
Differential privacy composes. Run two epsilon-DP mechanisms on the same dataset and the combined privacy loss is at most epsilon-1 plus epsilon-2 under basic composition. Run k mechanisms each with epsilon budget epsilon-0 and the total loss is k times epsilon-0. This is basic composition and it is a worst-case bound.
Advanced composition theorems, particularly those in the Renyi differential privacy framework developed by Ilya Mironov (arXiv:1702.07476), tighten this bound when mechanisms are run repeatedly. The Privacy Loss Random Variable approach and the moments accountant technique used by Google's TensorFlow Privacy library (arXiv:1607.00133) allow tighter tracking of cumulative privacy loss under Gaussian mechanisms.
But these tighter bounds require assumptions. They assume independence between queries. They assume the mechanism is applied correctly. They assume the adversary's side information is bounded in a particular way. In production systems none of those assumptions hold cleanly.
The practical consequence is that any system collecting multiple telemetry signals, running multiple analytics passes or answering multiple user queries against the same underlying dataset faces a composition problem. The per-query epsilon looks defensible. The aggregate epsilon after a year of operation may not be. This is the composition theorem in practice and it is rarely disclosed to users.
Apple's Epsilon Choices and the Criticism They Drew
Apple announced local differential privacy for iOS telemetry in 2016. By 2017 researchers at the University of Pennsylvania, led by Steven Wu and Aaron Roth, published a technical analysis (available at the time on Roth's faculty page) noting that Apple's per-feature epsilon values ranged from 1 to 14, with a daily total epsilon budget as high as 14 per day per device.
That daily budget compounds. A device transmitting data every day for a year accumulates a theoretical composition loss that, under basic composition, is orders of magnitude beyond any academically defensible privacy guarantee. Apple argued that local differential privacy provides protection at the point of collection, before data leaves the device, and that the server never sees raw records. That architectural distinction is real and important. Local DP is strictly stronger than central DP in the threat model where the data collector is untrusted.
The criticism, though, was not about the architecture. It was about the epsilon values chosen within that architecture. A per-feature epsilon of 14 means the output distribution of the mechanism shifts by a factor of up to e^14 (roughly 1.2 million) depending on whether a particular value is present. At that scale the mathematical privacy guarantee is largely symbolic.
Apple's position, consistent with its public documentation on apple.com/privacy, is that local DP provides meaningful protections even at higher epsilon values when combined with device-level aggregation limits, on-device processing and restricted data retention. That is a defensible engineering argument. It is not a mathematical privacy argument in the classical DP sense.
The episode illustrated a recurring pattern: organizations adopting differential privacy as a communications asset while making epsilon choices that the framework's original designers would not endorse.
Google's RAPPOR and Local Differential Privacy
Google's RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response) protocol, described in the 2014 CCS paper by Erlingsson, Pihur and Korolova, uses local differential privacy to collect Chrome browser statistics at scale. The protocol applies a two-step randomized response mechanism that provides longitudinal privacy guarantees even when the same user reports multiple times.
RAPPOR's epsilon parameters in its original publication were set to achieve what the authors described as "reasonable utility" on Chrome telemetry workloads. The per-report epsilon values were in the range of 2 to 8 depending on the data type. The longitudinal component added a permanent randomization step that provides deniability across multiple observations, a property the authors called "memoization."
The memoization approach is technically elegant. It bounds the privacy loss from repeated observation of the same individual by fixing a randomized encoding at enrollment. The permanent randomized response is drawn once and cached. Subsequent responses are derived from the permanent response rather than the raw value. This means that an adversary observing multiple RAPPOR reports from the same device cannot triangulate the true value beyond what they could infer from a single report.
The critique of RAPPOR from the academic community has focused less on epsilon values and more on the disclosure architecture. The mechanism protects against a passive server-side adversary. It does not protect against adversaries with auxiliary information, correlated side channels or the ability to link RAPPOR reports to other behavioral signals that Google's own systems process. The W3C Privacy Interest Group (PING) has noted similar concerns in the context of web platform telemetry APIs at w3.org/Privacy.
The Census Bureau's 2020 Deployment and Its Aftermath
The Census Bureau's deployment of differential privacy for the 2020 Decennial Census was the highest-stakes real-world application of the framework to date. The TopDown Algorithm, described in detail in the Bureau's published documentation and the accompanying arXiv preprint (arXiv:1910.06477), applies a hierarchical DP mechanism to produce redistricting data products.
The Bureau chose a global epsilon of 19.61 for the Person data and 2.52 for the Housing Unit data. These values emerged from an extended public comment process and reflected a policy tradeoff between data accuracy for small geographies (counties, census tracts and blocks) and formal privacy protection.
The controversy was significant and multidimensional. A coalition of state governments and demographers argued that the accuracy loss at small geographic levels made the data unsuitable for redistricting and small-area estimation. The American Statistical Association published formal comments raising concerns about the methodology. Researchers including Philip Leclerc and others at the Census Bureau itself published responses defending the approach.
From a pure DP standpoint, an epsilon of 19.61 is extremely high. The ratio e^19.61 is approximately 330 million. At that scale the formal guarantee is that membership in the dataset changes the output distribution by a factor of up to 330 million. That is not a privacy guarantee in any intuitive sense. The Bureau's defense was that the threat model for census reconstruction attacks justified even a weak DP guarantee as meaningful protection against specific adversaries, particularly database reconstruction attacks of the type described by Dinur and Nissim (2003).
That defense has merit within a narrow threat model. It does not satisfy the broader definition of privacy protection that differential privacy was designed to provide. The Census deployment made visible a tension that exists in every large-scale DP deployment: the epsilon value that produces useful data at population scale is often the epsilon value that provides negligible individual protection.
What Epsilon Value Is Actually Defensible
The academic literature does not specify a universal defensible epsilon. What it does offer are principled arguments about thresholds.
Dwork and Roth's original framing suggested that epsilon should be thought of as a small constant, ideally 0.1 to 1.0, for strong individual privacy guarantees. The interpretation is that at epsilon equals 1, an adversary with complete background knowledge about every other individual in the dataset still cannot increase their posterior probability about your specific record by more than a factor of e (roughly 2.718). That is a meaningful bound.
The Apple Differential Privacy Team's internal documentation (partially disclosed in response to researcher requests) described per-user daily budgets that aggregate well above this range. Frameworks like Google's differential privacy library on GitHub set epsilon defaults for demonstration purposes at values between 1 and 10 with explicit warnings that production deployments require careful calibration.
NIST's Special Publication 800-188, which covers de-identification of government datasets, acknowledges differential privacy as a technique and notes that epsilon selection requires domain-specific risk analysis rather than universal thresholds. That document is available at csrc.nist.gov.
The emerging consensus among privacy engineers is that epsilon values above 1 require explicit justification tied to a specific threat model and a specific adversary capability assumption. Epsilon values above 10 should be considered high-risk deployments where the DP label functions as compliance branding rather than mathematical protection.
Practitioners should also evaluate the neighboring dataset definition. Epsilon guarantees depend entirely on how "neighboring" is defined. A definition that treats entire households as a single unit rather than individual records can inflate apparent epsilon sensitivity. The definition should be disclosed alongside the epsilon value in any transparency-oriented deployment.
Consent Architecture and the Epsilon Disclosure Problem
The epsilon problem is not only a technical calibration problem. It is a consent and transparency problem.
When Apple, Google or the Census Bureau deploys differential privacy, users and respondents are told that their data is "protected by differential privacy." That statement is technically true at any positive epsilon value. The statement is also nearly meaningless without the epsilon value, the composition accounting methodology, the neighboring dataset definition and the threat model being disclosed alongside it.
This is the intersection where privacy engineering meets consent architecture. The Personal Data Asset Origination System (PDAOS), described in Dr. Patrick Fisher's work at mydatakey.org, frames this as a data fiduciary obligation. A system that claims to protect individual data through mathematical mechanisms should disclose the parameters of those mechanisms in machine-readable consent receipts that individuals can audit and challenge.
The W3C Consent Receipt specification and the IETF's ongoing work on privacy-preserving measurement (see the Privacy Preserving Measurement working group at datatracker.ietf.org) gesture toward this disclosure architecture. Neither fully resolves the epsilon transparency problem.
In The Invisible Data (Volume 6 of The Invisible Series), the argument is made that mathematical privacy mechanisms are a form of contractual commitment to the individuals whose data they process. A contract whose key terms are undisclosed is not a contract. An epsilon value that is not disclosed is not a privacy commitment. It is a privacy assertion.
The difference matters. Assertions can be made without accountability. Commitments can be audited, challenged and enforced. Privacy engineering at scale requires moving from assertion to commitment. That requires disclosing epsilon alongside every differential privacy claim, publishing composition accounting under realistic operational assumptions and treating the privacy budget as a public-facing specification rather than an internal engineering parameter.
Until that standard becomes the norm, the epsilon problem in public deployments is not a calibration failure. It is a transparency failure dressed in mathematics.
Key Takeaways for Privacy Engineers
- Evaluate epsilon values in context of the full composition budget, not the per-query budget
- Require disclosure of the neighboring dataset definition alongside any epsilon claim
- Use Renyi DP or zero-concentrated DP accounting for tighter composition bounds in multi-query systems
- Treat epsilon values above 1 as requiring explicit threat-model justification
- Publish privacy budgets in machine-readable formats compatible with emerging consent receipt standards
- Distinguish between local DP and central DP guarantees when communicating protection levels to non-technical stakeholders