RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response

RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response. In 2014, Úlfar Erlingsson, Vasyl Pihur, and Aleksandra Korolova presented this work at the ACM SIGSAC Conference on Computer and Communications Security. RAPPOR is a telemetry design in which a client randomizes its value before the collector receives it. The collector can then estimate population patterns without seeing each client’s unmodified answer. The central question is whether this arrangement can preserve useful signals while reducing trust in a central collector.

Start with local differential privacy: the client adds randomness before sending data, so the collector never receives the original value. RAPPOR first hashes a string into a Bloom filter. It then creates a permanent randomized response and remembers that noisy result. Repeated reports of an unchanged value therefore converge toward the saved noisy pattern, not the original bit pattern. A second layer, called instantaneous randomized response, adds fresh randomness whenever the client submits a report and supplies a privacy guarantee for that individual report.

The design challenge has two sides. Each report must conceal enough about its client, while reports from many clients must still preserve enough aggregate structure for useful frequency estimates. Time adds another problem. If the same setting is reported repeatedly, can the collector average away the noise? Memoization is intended to cap what repeated reports reveal about a stable value. But when values change, or when the system collects several correlated properties, privacy loss can continue to grow. The study examines this tension between repeated-report privacy and statistical usefulness.

On the client, RAPPOR hashes a string into the Bloom filter, applies the remembered permanent randomization, and then adds fresh report-time randomization. On the server, the researchers total the reported bits across clients. They divide clients into cohorts that use different hash functions, helping separate values that would otherwise collide. A statistical selection method called Lasso narrows a predefined list of candidate strings. Least-squares estimation then assigns frequencies, while multiple-testing control reduces false leads caused by checking many candidates. Basic RAPPOR can avoid Bloom-filter collisions when that candidate list is known; a one-time variant removes the permanent layer.

The privacy and accuracy results need to be considered together. For an unchanged value, arbitrarily many reports may expose the remembered randomized pattern, but no more; the researchers derived a finite privacy bound across repeated collection for that fixed-value case. Accuracy was expensive for rare signals. Under the evaluated one-time privacy setting, detecting roughly 1 percent frequency required about 1 million reports. Rarer signals required vastly more data. The mechanism can therefore recover common population patterns at scale without making rare values easy to measure.

The evaluation included Windows process-list reports and a Chrome homepage experiment. Chrome’s opt-in usage-statistics population supplied about 14 million respondents per day. Even at that scale, the researchers expected difficulty detecting very rare signals. In the homepage experiment, only a very small fraction of the candidate URLs passed the statistical test after an adjustment designed to limit false discoveries, although they represented most of the estimated probability mass. The analysis also surfaced unexpected domains. These measurements support recovery of concentrated, relatively common signals, while leaving the rare and poorly specified tail difficult to interpret.

The finite repeated-report bound applies when a value remains unchanged. Changing values and collections of correlated statistics can increase privacy loss. Multiple accounts or devices may also weaken memoization’s intended benefit, while correlations between properties or cohorts may enable tracking. Useful accuracy can require suitable parameters, very large samples, and a known candidate list. Hash collisions, flawed assumptions, rare values, and changing populations can constrain decoding and interpretation. Retention limits and access controls can also be required.

For security and telemetry teams, the operational lesson is to evaluate the whole collection program, not one report in isolation. Do not interpret epsilon—the privacy-loss number attached to an individual report—as a lifetime guarantee. Set a privacy budget for the collection period that covers correlated reports, memoization choices, and collection across multiple accounts or devices. If accumulated loss is too high, reduce collection or add more noise. Even with RAPPOR, minimize what you collect and govern how long data is retained and who can access it. For rare values, validate expected detection performance against the actual population before deployment.

RAPPOR lets clients randomize data before sending it while still allowing a server to estimate population patterns. The measurements also show the cost: rarer targets require sharply larger samples. Privacy engineers, security architects, and telemetry teams may find the approach suitable for stable, common signals in a sufficiently large population. They should not assume it can accurately recover rare or changing values. Nor should they treat a per-report privacy guarantee as lifetime protection. Before deployment, budget privacy across the full collection period and test accuracy under actual conditions. Minimize collection, limit retention, and control access.