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.
The measurement dilemma
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.
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.
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.
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.
How DAP works
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:
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.
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.
What changed from prior MPC systems
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.
Performance
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.
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.
Expertise
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.
DAP standardizes the cryptography. It defines safe, vetted configurations for common measurement types, so the decision of how to measure something privately has already been made and reviewed. To be clear about what this does and doesn't remove: it lowers the cryptographic barrier specifically. You still need data science and privacy engineering expertise – especially around differential privacy budgets and experiment design – but you no longer need to make novel cryptographic design decisions to get started.
Operations
The hardest barrier was never really technical. It was this: where do you find an independent party willing to actually run the second server?
The whole security model depends on two organizations that don't collude – which means you can't just spin up both aggregators yourself. Someone else, with separate infrastructure and separate incentives, has to operate the other half. That's a genuine problem, and it's the one that stopped most would-be deployments of MPC cold.
Divvi Up exists to answer exactly that question. ISRG operates one aggregator as a service; you operate the other, or vice versa.
The numbers
Divvi Up has been running in production for more than three years. In that time it has processed over 4.5 billion reports, routinely bursting past 450 million reports in a single week, ample capacity to aggregate telemetry from very large cohorts of users. And "bursting" is the operative word, because real telemetry workloads are spiky: A discrete measurement experiment can drive burst volumes orders of magnitude above baseline. Handling those spikes gracefully is what production usage actually looks like.
None of the infrastructure behind this is exotic. Janus is a fairly ordinary Rust web service running on commodity cloud infrastructure, the same kind you'd reach for to build any scalable web application. There's no bespoke research setup and no specialized hardware.
A notable deployment is with Mozilla Firefox, which has strict rules against collecting any data that could reveal to Mozilla, even indirectly, what websites a user visits. With Divvi Up, Firefox can gather telemetry that previously would not have been safely accessible, while giving strong, publicly verifiable guarantees that nobody off-device can learn what a user is doing online. We wrote about that use case in detail in Divvi Up in Firefox. None of it is specific to Firefox: The system is general-purpose, and any application that needs privacy-preserving measurement can use it.
The software exists
Our aggregator, Janus, is open source, written in Rust, does not require exotic infrastructure to run, and implements the IETF DAP specification. Anyone can build a compatible aggregator and interoperate rather than trust a black box to hold up their side of the trust boundary. Janus is available as a container, and we’ll continue to maintain it as we operate our service.
Getting started
Practical MPC aggregation isn’t a research demo anymore – it’s running at Internet scale today, and it’s ready for your use cases. If you can instrument your application to send telemetry to a REST endpoint, you can use DAP.
The best way is to start small. Pick a single, simple metric – a counter like “how many users hit error X today” – and prove the pipeline end-to-end. Counters are one of the well-defined VDAFs built into DAP, so there’s no cryptographic design work to do. Once that works, expand to histograms, bit vectors, more metrics, more of your application. The cryptography is done for you.
Everything you need is open-source and standards-based. Janus is on GitHub. We publish client libraries in TypeScript, Rust, and Java. The DAP and VDAF specifications are IETF standards in progress - interoperability is a design goal, and we hope to see aggregators beyond Divvi Up emerge in the ecosystem. You can put together your own Leader and Helper, or you can use Divvi Up for one of those roles and be running quickly.
Some places to go next:
- divviup.org
- Getting started tutorial -- up and running in 5 minutes with Docker
- IETF PPM working group
We’d love to talk more about how DAP could work for your application, whether you use Divvi Up or not. Contact us.