The Privacy Sandbox

This page has to be written differently from the others. The Privacy Sandbox is a programme in flight: designs are published, renamed and withdrawn, and any confident statement about its current state is likely to be wrong within a year. What follows is the shape of the idea, the APIs that have been announced, and an explicit marker wherever the details may have moved.

TL;DR#

• The Privacy Sandbox on Android aims to replace the Advertising ID with APIs that give advertisers useful signals without a cross-app identifier.¹
• The three pillars that have been described: Topics (interest-based targeting), Protected Audience (remarketing without cross-app IDs) and Attribution Reporting (measuring ad conversions without a joinable identifier).
• SDK Runtime is the process-isolation piece: ad SDKs run in a separate process with restricted access.
• Status is developer preview / evolving for most components, with timelines that have slipped more than once.
• The design principle is on-device computation plus aggregated reporting, rather than a centralised identifier.

Mental model#

Imagine a city that has decided to ban loyalty cards.

Shops still need to know roughly what neighbourhoods are interested in, and advertisers still need to know whether an ad led to a sale. So the city builds three public utilities:

• A noticeboard where each person can post a few interest categories, chosen on their own device and visible only in aggregate (Topics).
• A closed auction house where an advertiser can show an ad to people who previously visited their shop, without learning who they are (Protected Audience).
• A sealed receipt box where a sale can be recorded and reported only in aggregate, with noise added (Attribution Reporting).

The city does not need to know who bought what. It needs the utilities to produce useful statistics without a list of names.

Where the analogy breaks#

A city can compel shops to use its utilities. Android cannot compel advertisers, and it shares the advertising ecosystem with iOS and the open web, each of which is building different utilities. The analogy also hides the hardest part: aggregation with noise is a statistics problem, and the accuracy/privateness trade-off is the entire design.

The big picture#

The difference to hold on to is joinability. An identifier is dangerous because it joins data across contexts. The sandbox APIs are designed so that the answer to any single query is useful, and the answers cannot be joined into a profile.

Deep dive#

What problem it is solving#

The Advertising ID is resettable and opt-out-able, which made it acceptable for a while. But it is still a single value that any SDK can read and send anywhere, and once two apps' logs contain it, the join is trivial and permanent.

Privacy Sandbox is the response to a specific regulatory and platform pressure: keep advertising measurable without a joinable identifier. The design constraint is severe — the replacement must be useful enough that advertisers do not route around it.¹

The three pillars#

Topics. The device maintains a small set of interest topics, derived from app usage on-device.¹ An app can ask for topics, but only a limited number, and the topics are coarse (a few hundred categories). The design intent is that a topic is shared by millions of people, so it identifies a crowd rather than a person.

Protected Audience. Remarketing — "show this ad to people who visited my site" — without a cross-app identifier. The mechanism involves on-device ad selection: the device holds the relevant audiences, runs the auction locally, and reports only the outcome. The advertiser learns that an ad won, not who saw it.

Attribution Reporting. Measuring whether an ad led to a conversion, with aggregatable reports and event-level reports that are deliberately noisy and delayed.¹ The API is designed so that a report is useful in aggregate and useless for tracking an individual.

SDK Runtime#

The most architecturally interesting piece is not about advertising at all. SDK Runtime runs third-party SDKs in a separate process with a restricted set of capabilities, instead of loading them into the app's process.

The motivation: an ad SDK loaded into your app inherits your app's permissions and your app's access to data. Running it in a separate runtime lets the platform give it a narrower set of capabilities than the app has.

That idea — isolating SDKs rather than trusting them — is the part most likely to outlive the specific advertising APIs, because it addresses a problem every app has regardless of the advertising debate.

Why the status is genuinely uncertain#

Three forces keep the design moving:

• Regulatory negotiation. The programme is shaped by conversations with competition authorities and privacy regulators, and commitments made in one jurisdiction change the design globally.
• Ecosystem incentives. Advertisers and publishers push for more signal; privacy advocates push for less. The APIs land somewhere in between and move as the balance shifts.
• Technical difficulty. Aggregation with noise, on-device auctions and cross-app reporting are hard to build correctly, and some designs have been simplified or dropped after review.

The honest summary for a developer: know the shape, do not memorise the API.

What an app developer should do now#

• Do not build new architecture around the Advertising ID. It is the thing being replaced.
• Prefer first-party data. An account ID and an app-set ID are unaffected by this programme.
• Keep analytics separable from advertising. If your analytics can work without an identifier, it will survive whatever replaces it.
• Watch SDK Runtime, because the isolation model is likely to affect any third-party SDK, not just ad SDKs.

Health Connect, briefly#

Health Connect is a separate platform effort with a similar philosophy: instead of every fitness app reading sensors directly, health data is mediated by a platform API with per-type permissions and user control. It is not part of the Privacy Sandbox, but it belongs to the same decade-long shift from "apps access data directly" to "apps request a mediated view".

How to read a Sandbox announcement#

Given how much the programme moves, a useful skill is reading an announcement and separating the durable idea from the implementation detail.

The durable part is almost always a principle: on-device computation, aggregation with noise, isolation of third-party code, or removing a join key. Those principles have survived every redesign.

The implementation detail is almost always a limit: how many topics, how long a delay, which report type, which class name. Those change, and code written against them is fragile by construction.

When you read about a new Privacy Sandbox API, ask which part is the principle and which part is the current number. The principle is worth designing for; the number is worth checking again next quarter.

Why "wait and see" is a defensible strategy#

For most app teams, the correct response to the Sandbox is not to adopt it early. It is to avoid dependencies that will need to be unwound.

That means three things: do not build a feature whose value depends on a cross-app identifier; keep the analytics you actually need separable from the advertising you do not; and make sure the app works when the Advertising ID is zeroed, because on some devices and some user settings it already is.

The teams that will have the easiest transition are the ones whose data model was already first-party. That is not a coincidence — the programme is designed to reward exactly that.

How it evolved#

Under the hood#

• ‹›AppOpsManager.java↗the operation-level layer that any new privacy API ultimately reports through
• ‹›AppOpsService.java↗the recorded access log the Dashboard and auditing read
• ‹›↗the Mainline module that owns permission and privacy enforcement on modern releases

The packages/modules/Permission entry is the structural point: privacy enforcement is now a Mainline module, so it can be updated without a full OS release. That is why new privacy behaviour sometimes arrives on devices that have not had a platform upgrade.

Curiosity corner#

• The Privacy Sandbox is not one thing. It is a programme with several unrelated APIs that share a philosophy, and components can be added or dropped independently.
• Aggregation with noise is not a hack. Differential privacy is the formal basis for "useful in aggregate, useless for an individual", and the noise is the feature.
• The strongest privacy change in this era is not in the Sandbox at all. It is the ordinary runtime permission model, which is boring and effective.

Try it#

$ 
adb shell pm list packages | grep -i adservices

package:com.google.android.adservices

$ 
adb shell am start -a android.settings.ADVANCED_PRIVACY_SETTINGS

Settings → Privacy → Ads

Build it#

The useful exercise here is not writing Sandbox code — it is designing your analytics so it does not depend on an identifier. Take one analytics event in your app and ask what it would take to count it without a user id. If the answer is "nothing", your analytics is already future-proof.

Check yourself#

Sources#