Production Multi-Party Computation Is Here - Divvi Up<br>Production Multi-Party Computation Is Here

This June, we gave a talk at USENIX PEPR with a deliberately provocative claim: multi-party computation for telemetry isn't a research curiosity anymore. It has crossed the line from academic prototype to production infrastructure, and it's running at internet scale today, processing billions of contributions from real users in Mozilla Firefox and other applications. The video and slides are available from USENIX.<br>The measurement dilemma<br>Every organization that builds software wants to know how it's actually being used. How fast do pages load? Which features get reached for, and which go untouched? How often does something error out? This kind of telemetry is what separates informed engineering from guesswork.<br>The conventional way to get it is to collect raw measurements on a central server. Even with the best intentions and the strictest data-handling policies, that approach carries an inherent privacy cost: the server sees every individual measurement. The data becomes a liability the moment it arrives at the server– something to secure, to govern, and to worry about in the event of a breach or a subpoena.<br>And there's a cruel twist: The data that would be most useful to gather is often exactly the data that carries the greatest privacy liability. The measurements that reveal the most about how people actually use your software are frequently the ones too sensitive to responsibly collect in raw form, so the most valuable telemetry goes ungathered. That’s the dilemma: You need the data to build better software, but collecting it as individual records is exactly the thing that puts people's privacy at risk.<br>Multi-party computation (MPC) has promised a way out of this bind for decades. In principle, it lets a set of servers compute an aggregate – a sum, a histogram, a count – without any single one of them ever seeing an individual contribution. In practice, real-world deployments have been vanishingly rare: The techniques were expensive, hard to configure correctly, and operationally awkward enough that almost nobody ran them outside a research setting. That's what has changed – and it's what the rest of this post is about.<br>How DAP works<br>The system underneath Divvi Up is the Distributed Aggregation Protocol, or DAP – being standardized at the IETF, not a research prototype, designed from the ground up for production deployment. The core idea is straightforward:<br>Before a client sends a measurement anywhere, it splits that value into two secret shares using a Verifiable Distributed Aggregation Function (VDAF). One share goes to a server called the Leader, the other to a server called the Helper – and crucially, the two are run by different organizations. Neither share reveals anything on its own because it is indistinguishable from random noise, so the only way to recover an individual measurement would be for operators to collude. Because they run separate infrastructure with independent incentives and oversight, that's a meaningful trust boundary.<br>The Leader and Helper then jointly verify and aggregate the shares — using zero-knowledge proofs to reject malformed inputs without either server ever seeing an underlying value – and only the final aggregate is ever reconstructed: a sum, a histogram, a count, never an individual contribution. That's the whole game: Individual measurements go in, and only the aggregate comes out.

For a fuller walkthrough — including the upload, aggregate, and collect phases and a diagram of the flow — see how Divvi Up works.<br>What changed from prior MPC systems<br>If MPC has been around for decades, why hasn't it shown up in production until recently? The techniques achieved the privacy goals the whole time. What kept them out of real systems wasn't the cryptography – it was three practical barriers. DAP and Divvi Up were built to take down each one.<br>Performance<br>General-purpose MPC lets you compute any function jointly across parties, and that generality is expensive – far too expensive for the volume of telemetry a real application produces.<br>DAP sidesteps the problem by refusing to be general-purpose. The VDAFs it builds on don't compute arbitrary functions. Instead they compute the specific handful that telemetry actually needs: sums, counts, histograms, and specializing makes them fast. On the client, encoding a measurement into its secret shares is sub-millisecond, even on constrained devices and inside mobile browsers. That is a deliberate design target: this has to run on the web platform, on real users' hardware, without noticeable performance impact.<br>Expertise<br>Prior MPC deployments typically needed a cryptographer in the loop to design and validate each new configuration. That's a hard dependency to carry, and it doesn't scale past a handful of specialized projects.<br>DAP standardizes the cryptography. It defines safe, vetted configurations for common measurement types, so the...