Differential privacy is the closest thing the privacy engineering field has to a mathematical guarantee. But a guarantee is only as meaningful as the parameters backing it. In practice, the epsilon values chosen for real-world deployments at Apple, Google and the Census Bureau reveal a contested landscape where the math is clean but the policy decisions are anything but. As of 2026, the field is still arguing about what epsilon value is actually acceptable, and the stakes are higher than most deployment teams acknowledge.
This review examines the epsilon choices made in three landmark public deployments, explains why those choices have drawn sustained technical criticism and walks through how the composition theorem transforms individual epsilon budgets into something far less protective than advertised.
What Epsilon Actually Measures
Differential privacy, formalized by Dwork, McSherry, Nissim and Smith in their foundational work, provides a bound on how much any single individual's data can affect the output of a computation. The formal definition: a randomized mechanism M satisfies epsilon-differential privacy if for all datasets D and D' differing by one record, and for all output sets S, the ratio of Pr[M(D) in S] to Pr[M(D') in S] is bounded above by e^epsilon.
Epsilon is a privacy loss parameter. Smaller epsilon means stronger privacy. Larger epsilon means the mechanism leaks more information about any individual record. The problem is that epsilon is unit-free. There is no universally accepted threshold below which a deployment is considered private and above which it is not. The field has informal conventions, not standards.
Researchers working from the framework established in Dwork and Roth's "The Algorithmic Foundations of Differential Privacy" (Foundations and Trends in Theoretical Computer Science, Vol. 9, 2014) generally treat epsilon values below 1 as strong, values between 1 and 10 as moderate and values above 10 as weak for most threat models. What the major deployments actually use is sobering by that rubric.
Apple's Local Differential Privacy Choices
Apple disclosed its use of local differential privacy in 2016 for collecting emoji usage, new word frequencies and health data from iOS and macOS devices. The company published a technical overview that revealed per-user epsilon values ranging from approximately 1 to 14 depending on the data type. Emoji and new word collection operated at epsilon near 1. Health-type telemetry operated at higher values.
The distinction between local and central differential privacy matters here. Local DP applies noise at the device before any data leaves. No trusted curator is needed. The tradeoff is that local DP requires much more noise to achieve the same utility as central DP at a comparable epsilon, and to recover useful aggregate statistics from locally perturbed data, Apple must query large numbers of users, which re-introduces composition risk at the analyst level.
A research critique published on arXiv (Tang et al., arXiv:1709.02753) examined Apple's deployment and found that the effective epsilon per user per day was considerably higher than the per-query figure once realistic query repetition was accounted for. The researchers estimated that repeated daily collection across the full suite of Apple telemetry could push effective per-user epsilon into ranges that materially weaken the privacy guarantee. Apple has not publicly revised its epsilon documentation in response, though its privacy white papers have been updated since.
The local DP architecture does have genuine advantages. Because no central server ever holds unperturbed data, the threat model excludes server-side breaches entirely. But claiming strong epsilon-DP protection at the device level while running high-frequency aggregation across hundreds of millions of devices is a tension the deployment literature has not fully resolved.
Google RAPPOR and the Epsilon Debate
Google's RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response) system, described by Erlingsson, Pihur and Korolova in their 2014 CCS paper, was one of the first large-scale local DP deployments in a production environment. It was used to collect Chrome browser statistics, including default search engine settings and homepage configurations.
RAPPOR uses a two-layer randomization process: a permanent randomized response that encodes a user's true value, and a transient randomized response applied per report. The permanent layer uses epsilon_1 and the transient layer uses epsilon_2. The paper's example parameters set epsilon_1 plus epsilon_2 at approximately 4 for typical deployments, and the authors explicitly acknowledged that these were engineering tradeoffs calibrated for utility rather than derived from a privacy-first principled selection.
The deeper issue with RAPPOR was exposed by Alvim, Chatzikokolakis, Palamidessi and Pazii (and others in the local DP analysis literature): because RAPPOR's permanent randomization is fixed per user, an attacker with multiple observations of the same user across time can partially reconstruct the permanent randomized response and reduce the effective privacy guarantee. This is a known limitation of the RAPPOR design rather than an implementation error, but it illustrates how epsilon values stated at mechanism design time can diverge from realized privacy loss under realistic adversary models.
Google has since moved toward more sophisticated mechanisms including its open-source libraries under the differential privacy GitHub repository and its use of DP-SGD for federated learning workloads. The epsilon values in those contexts remain variable and context-dependent, and the company's published guidance acknowledges the difficulty of specifying a single acceptable threshold.
The Census Bureau's TopDown Algorithm
The most consequential and most contested differential privacy deployment to date is the Census Bureau's use of the TopDown Algorithm (TDA) for the 2020 Decennial Census. The Bureau applied differential privacy to protect individual responses in the census microdata, replacing earlier disclosure avoidance techniques based on cell suppression and swapping.
The global epsilon chosen for the 2020 redistricting data product was 17.14. That figure is not a typo. The Bureau allocated epsilon across geographic and demographic hierarchies using a hierarchical allocation scheme, and the total privacy loss budget for the full person-level data release was set at this value after extensive internal debate and external comment periods.
The choice generated significant technical pushback. The research collective that published "Differential Privacy and the 2020 US Census" (multiple authors, circulated as a working paper and reviewed by the American Statistical Association's Privacy and Confidentiality Committee) argued that epsilon values in the range of 17 provide only marginal formal protection above no-privacy baselines for many realistic attack models. The practical interpretation: the mathematical guarantee at epsilon equals 17 means that an adversary's posterior probability of inferring a protected record characteristic is bounded, but the bound is so loose that it offers limited resistance to inference attacks using auxiliary information.
The Bureau's counterargument is pragmatic. The census is used for congressional apportionment, federal funding allocation and redistricting. Accuracy requirements are legally mandated. At very low epsilon, the noise introduced by DP mechanisms degrades small-area statistics to the point where redistricting data becomes unreliable. The epsilon choice was ultimately a societal tradeoff between privacy protection and data utility for governance purposes, not a purely technical decision.
That framing is accurate, but it also reveals the core limitation of deploying differential privacy without consensus on minimum acceptable epsilon. When the social utility pressure is high enough, epsilon can be raised to whatever value makes the data useful, at which point the mathematical privacy guarantee provides cover without substance.
The Composition Theorem in Practice
Even if individual epsilon values were set at principled levels, the composition theorem ensures that privacy budgets degrade with every additional query or release. The basic sequential composition theorem states that if k mechanisms each satisfy epsilon_i-DP, their sequential composition satisfies (sum of epsilon_i)-DP. Privacy loss is additive under sequential composition.
Advanced composition results (Dwork, Rothblum and Vadhan, STOC 2010) give tighter bounds. For k adaptive mechanisms each satisfying epsilon-DP, advanced composition gives approximately sqrt(2k ln(1/delta)) times epsilon plus k times epsilon times (e^epsilon minus 1) for (epsilon', delta)-DP. For small epsilon the improvement is meaningful. For epsilon values in the range Apple and the Census Bureau deployed, the practical difference narrows.
The Renyi differential privacy framework (Mironov, arXiv:1702.07476) offers a more composable accounting method. RDP tracks privacy loss as a Renyi divergence across alpha-orders rather than as a single epsilon. This allows tighter composition accounting for Gaussian mechanisms and is now standard in libraries like Google's DP library and OpenDP. But RDP-based accounting still cannot rescue a deployment where the base epsilon is already high before composition begins.
In a real engineering context, consider an analytics pipeline that runs five daily aggregate queries on a user population, each with epsilon equals 2. Sequential composition gives a daily total of epsilon equals 10. Over a 30-day month, naive composition reaches epsilon equals 300 for any user present throughout the period. Even advanced composition with delta equals 10^-6 gives an effective epsilon far above any principled privacy threshold. Privacy budgets in production systems are almost never tracked this rigorously, and the deployment literature rarely discloses cumulative composition across the full operational lifetime of a system.
Engineering With a Privacy Budget
Principled epsilon selection requires working backward from the threat model rather than forward from utility requirements. The question is not "what epsilon preserves enough accuracy" but rather "what epsilon bounds the adversary's ability to reconstruct protected attributes given realistic auxiliary knowledge."
Several frameworks attempt to operationalize this. The GDP (Gaussian Differential Privacy) framework by Dong, Roth and Su (Journal of the Royal Statistical Society Series B, 2022) unifies DP analysis under a hypothesis testing interpretation and provides cleaner composition results for Gaussian mechanisms. It reframes epsilon selection as a question about the distinguishability of a protected individual, which maps more directly to concrete privacy harms than the abstract ratio bound in the original definition.
For engineering teams building production systems, the practical guidance from the OpenDP project (opendp.org, developed at Harvard and MIT) and from NIST's Privacy Framework is to document composition explicitly. Every query against a dataset should consume from a finite, tracked budget. Once that budget is exhausted, no further queries should be permitted without either adding new data or accepting a privacy cost disclosure.
Budget management is not a feature most analytics stacks support natively. Building it requires treating the privacy budget as a system resource, analogous to compute or storage, with instrumentation, alerting and enforcement at the data access layer. This is an area where the PDAOS architecture that Own Your Data Inc explores in the context of personal data origination systems becomes directly relevant. When data subjects control their own data assets and consent receipts are cryptographically bound, the privacy budget is an individual-level quantity that belongs to the subject, not the analyst.
Where Epsilon Standards Are Heading
As of 2026, there is no binding international standard specifying minimum epsilon for DP deployments under GDPR, CCPA or HIPAA. The EDPB has issued guidance on pseudonymization and anonymization (Opinion 5/2014 and subsequent guidelines) but has not formally adopted differential privacy as a recognized anonymization standard with specific parameter requirements. The FTC's enforcement activity around privacy engineering has focused on process and consent architecture rather than cryptographic parameters.
The most active standard-setting work is happening at NIST, where the Privacy Engineering program has produced NISTIR 8062 on privacy risk management and subsequent publications on DP deployment guidance. IEEE's P7002 working group on data privacy engineering and ISO/IEC JTC 1/SC 27 are both tracking DP as a component of broader privacy engineering standards, but binding parameter requirements remain years away.
The research community has converged informally on several positions. Epsilon below 1 is considered strong for most threat models. Epsilon between 1 and 3 is considered workable with careful composition accounting. Epsilon above 10 provides formal guarantees that are increasingly difficult to translate into concrete privacy protections for realistic adversary models. The Census Bureau's epsilon of 17.14 sits well above the range where most privacy researchers are comfortable, even accounting for the specific data type and social utility arguments.
What the field needs is not a single universal epsilon threshold but a structured disclosure regime: any public DP deployment should publish its base epsilon per mechanism, its composition accounting methodology, its assumed threat model and its worst-case cumulative epsilon over the operational lifetime of the system. That level of transparency would allow independent researchers to audit claims, regulators to establish informed expectations and data subjects to understand what the privacy guarantee actually covers.
The mathematics of differential privacy is precise. The deployment practices surrounding it are not. Closing that gap is one of the central challenges in privacy engineering in 2026, and it requires treating epsilon not as a technicality to be satisfied but as a commitment to be honored.