Local vs Central DP

Every time a company publishes statistics about its users, it faces a dilemma: release enough to be useful, but not so much that an individual's secret can be reconstructed. Differential privacy (DP) — introduced by Cynthia Dwork and colleagues in 2006 — turns that dilemma into mathematics. It guarantees that the output of any query looks almost the same whether or not your record is included in the dataset, controlled by a single parameter $\varepsilon$ (epsilon): smaller means more private, larger means more accurate.

But differential privacy is not a single mechanism — it is a contract. And the contract has a crucial fine print: who do you trust to hold the raw data?

• In the central model, users hand their real data to a trusted curator. The curator answers queries and adds noise only to the final output. Because the curator sees everything, the noise can be calibrated perfectly — accuracy is high.
• In the local model, no curator is trusted. Each user randomizes their own data before sending it. Nobody ever sees raw data, not even the server. The price: every answer is much noisier, because individual randomization compounds.

This single design choice — central or local — has dominated the engineering of real privacy systems for two decades, from Apple's keyboard analytics to the US Census Bureau's reconstruction of population counts.

The demo below runs the same counting query — "how many people answered YES?" — on a synthetic group of 100 users, under both the central and local models. Drag the epsilon slider to control the privacy budget and watch how the two models diverge.

<!-- {{c_html_intro}} -->
<div class="panel">
  <div class="row-label">
    <span class="badge central">{{label_central}}</span>
    <span class="sub">{{label_central_sub}}</span>
  </div>
  <div class="row-label">
    <span class="badge local">{{label_local}}</span>
    <span class="sub">{{label_local_sub}}</span>
  </div>
</div>
<div class="slider-row">
  <label for="eps">&#949; = <span id="eps-val">1.0</span></label>
  <input type="range" id="eps" min="0.1" max="4" step="0.1" value="1.0" />
  <span class="eps-hint">{{label_eps_low}} &larr; &nbsp; &rarr; {{label_eps_high}}</span>
</div>
<div class="slider-row">
  <label for="truth">{{label_truth}}: <span id="truth-val">60</span>%</label>
  <input type="range" id="truth" min="10" max="90" step="5" value="60" />
</div>
<div class="btns">
  <button id="run-btn" type="button">{{btn_run}}</button>
  <button id="reset-btn" type="button" class="ghost">{{btn_reset}}</button>
</div>
<div id="chart" class="chart"></div>
<div id="status" class="status"></div>

/* {{c_css_intro}} */
* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; }
.panel { display: flex; gap: 1rem; margin-bottom: .6rem; flex-wrap: wrap; }
.row-label { display: flex; align-items: center; gap: .4rem; }
.badge { font: 700 12px system-ui; padding: .2rem .55rem; border-radius: 6px; }
.badge.central { background: #1d3557; color: #fff; }
.badge.local { background: #e63946; color: #fff; }
.sub { font-size: .78rem; color: #555; }
.slider-row { display: flex; align-items: center; gap: .6rem; margin: .35rem 0; flex-wrap: wrap; }
label { font-size: .88rem; font-weight: 600; min-width: 9rem; }
input[type=range] { flex: 1; min-width: 120px; max-width: 220px; }
.eps-hint { font-size: .72rem; color: #888; }
.btns { display: flex; gap: .5rem; margin: .6rem 0; }
button { font: 600 14px system-ui; padding: .45rem .9rem; border: 1px solid #1d3557;
         background: #1d3557; color: #fff; border-radius: 8px; cursor: pointer; }
button.ghost { background: #fff; color: #1d3557; }
.chart { display: flex; gap: 4px; align-items: flex-end; height: 140px;
         border-bottom: 2px solid #ccc; margin: .5rem 0; position: relative; }
.bar-wrap { display: flex; flex-direction: column; align-items: center; flex: 1; height: 100%; justify-content: flex-end; }
.bar { width: 100%; border-radius: 4px 4px 0 0; transition: height .3s; min-height: 2px; }
.bar.truth { background: #a8c5e8; }
.bar.central { background: #1d3557; }
.bar.local { background: #e63946; }
.bar-tick { font-size: .65rem; color: #666; margin-top: 3px; text-align: center; }
.status { font-size: .88rem; font-weight: 600; min-height: 1.4em; margin-top: .3rem; }
.status.ok { color: #0a7d33; }

// Code not found

Notice: for small $\varepsilon$ (high privacy) the central answer stays close to the truth while the local answer bounces wildly. For large $\varepsilon$ (low privacy) both converge, but you have given up privacy protection. The fundamental trade-off is built into the mathematics — not an implementation detail you can engineer away.

The accuracy gap is not a tuning problem — it is a mathematical lower bound.

For estimating a simple proportion (fraction of YES answers), the noise levels are:

• Central DP: the curator adds Laplace noise with scale $\frac{1}{\varepsilon}$ to the true count. Standard deviation $\sim \frac{1}{\varepsilon}$. With $n$ users the relative error is $\frac{1}{\varepsilon n}$ — it shrinks as you add more data.
• Local DP: each user flips their answer with probability $\frac{e^{\varepsilon}}{e^{\varepsilon}+1}$ (randomized response, proposed by Warner in 1965 and proved $\varepsilon$-DP). The server must debias the collected answers. Standard deviation of the final estimate $\sim \frac{1}{\varepsilon \sqrt{n}}$ — it shrinks much more slowly.

The gap: central DP achieves error $O\!\left(\frac{1}{\varepsilon n}\right)$; local DP achieves error $O\!\left(\frac{1}{\varepsilon \sqrt{n}}\right)$. To match central DP's accuracy, local DP needs $\sqrt{n}$ times more users for the same $\varepsilon$ — a provable impossibility theorem (Kasiviswanathan et al., 2011) that holds even with unbounded computation.

This is not unique to counting queries. For any function of the data, local DP incurs a $\sqrt{n}$ sample-complexity penalty. The intuition: in the local model, the server must do statistical estimation just to undo each user's randomization before it can answer the real question. The noise from $n$ independent users adds up like a random walk — standard deviation $\sqrt{n}$ — not like a single controlled perturbation.

Is the local model ever better? Yes — when you cannot trust a central curator at all. Differential privacy only promises privacy against the mechanism; a corrupt central server is not covered. Local DP is the right choice when the curator is the adversary.

See also differential privacy for the baseline $\varepsilon$-DP definition.

The central/local split is not theoretical — it drives real system designs:

• Apple (local DP): since iOS 10, Apple collects keyboard usage, emoji statistics, and Health app data using local DP on-device before any transmission. Apple explicitly does not trust even itself with raw user behavior.
• Google RAPPOR (local DP): Chrome sends browser statistics (default home page, crash flags) using randomized response. Each Chrome instance randomizes its own report; Google's servers see only the noisy aggregate.
• US Census Bureau (central DP): the 2020 Decennial Census used the TopDown algorithm — a central DP mechanism applied to the full census database. The raw microdata stays inside the Bureau; only the privatized counts are released.
• Meta / LinkedIn (mixed): these companies often use central DP internally for model training (federated or not) and local DP for data collection from devices, combining both layers for defense in depth.

The choice comes down to one question: who is the adversary? If it is an external attacker trying to re-identify data from published statistics, central DP is more accurate and sufficient. If it is the data collector itself — or a subpoena — local DP is the only option. See differential privacy for the formal definition that underlies both models.

Differential privacy promises that your presence in a dataset leaves only a controlled mathematical footprint. But the promise comes in two flavors: you can hand raw data to a curator and let them manage the noise (central DP), or you can randomize your own data before it ever leaves your device (local DP).

Central DP wins on accuracy — but it requires trusting the curator with your real data. Local DP requires trusting nobody — but the $\sqrt{n}$ accuracy penalty is not negotiable; it is a mathematical theorem. There is no clever implementation that closes the gap.

The right choice depends entirely on your threat model. If you are engineering a system today, the question is not "which is better?" but "who is the adversary?" — and that question has a very human answer hiding behind the math.