How Google’s Privacy Sandbox Accidentally Enabled User De-anonymization

TLDR: Google’s Privacy Sandbox, designed to replace third-party cookies with privacy-preserving APIs, contains a critical flaw in its Attribution Reporting API. By manipulating debug reports and exploiting undocumented rate limits, researchers can track individual user activity across sites. This research proves that even well-intentioned privacy features can be weaponized to leak cross-site browsing history.

Privacy-preserving ad-tech is a contradiction in terms. When Google announced the Privacy Sandbox, the industry narrative focused on killing third-party cookies to improve user privacy. The reality, however, is that the browser is now performing complex, stateful tracking on behalf of advertisers. If you are a pentester or a bug bounty hunter, you need to stop looking at the browser as a neutral client and start looking at it as a sophisticated tracking engine that you can manipulate.

The Mechanics of the Attribution Reporting API

The Attribution Reporting API is the core of this issue. It is designed to answer a simple question: did a user who viewed an ad on Site A perform a conversion, such as a purchase, on Site B? To do this without third-party cookies, the browser itself tracks these events.

When a user interacts with an ad, the browser registers a "source." When that same user later performs a conversion, the browser registers a "trigger." The browser then matches these events and sends a report to the ad-tech provider. The problem is that this entire process is handled by the browser, and the browser is susceptible to input from any site the user visits.

Exploiting the Debug Report Leak

The most immediate attack vector involves the API’s "debug reports." These were intended to help developers verify that their attribution logic was working correctly. However, these reports are essentially a side channel. By setting the ar_debug=1 cookie, a site can force the browser to send verbose, immediate reports that include sensitive information like the source site and the specific trigger value.

This is not just a theoretical leak. Because these reports are sent by the browser, they bypass standard cross-site protections. If an attacker can influence the browser to register a source and then trigger a conversion, they can force the browser to leak whether a specific user has visited a target site.

Consider this payload structure for registering a source:

GET /register-source HTTP/1.1
Attribution-Reporting-Eligible: navigation-source

When the ad-tech server responds, it includes headers that instruct the browser to store the attribution data. If you are testing an application that uses this API, you should be inspecting the chrome://attribution-internals page. This internal tool is a goldmine for researchers. It shows you exactly what the browser has stored, including the source registrations and the pending reports. If you see reports being generated for domains you do not control, you have found a potential path for data exfiltration.

The Boolean Oracle Attack

The most dangerous finding in this research is the use of the API as a boolean oracle. The API enforces strict rate limits to prevent abuse, but these limits are not always documented or consistent. By creating a large number of fake conversion events, an attacker can hit these rate limits.

If you send 999 reports to an ad-tech server, the browser will stop sending reports once the limit is reached. By observing whether the 1000th report is sent or dropped, you can determine if a specific conversion event occurred. This effectively turns the browser into a binary switch: "Did this user visit this site?"

This is a classic Broken Access Control scenario. The browser is granting the ad-tech provider access to information about the user’s history that the provider should not have. You are not just looking for XSS or CSRF anymore; you are looking for ways to force the browser to reveal its internal state.

Real-World Testing and Impact

During a penetration test, you should look for the presence of the Attribution-Reporting-Eligible header in outgoing requests. If you see it, the site is participating in the Privacy Sandbox. Your goal is to determine if you can influence the registration of sources or triggers.

If you can inject a script into a page that loads an ad, you can potentially register a source for a domain you control. If the user later visits a site that triggers a conversion, your server will receive a report. This is a powerful way to track users across the web, and it is entirely invisible to the user.

Defenders need to be aware that the Privacy Sandbox is not a "set it and forget it" security feature. If you are a developer, you should be using Permissions Policy to disable these APIs on your site if you do not explicitly need them. You can block the API entirely with this header:

Permissions-Policy: attribution-reporting=()

This simple change removes your site from the tracking ecosystem and prevents the browser from using your users as data points for ad-tech providers.

The web is moving toward a model where the browser is an active participant in tracking. As researchers, we need to treat these new APIs with the same skepticism we apply to any other complex, stateful system. The Privacy Sandbox is a massive, largely unexplored attack surface. Start digging into the internals, watch the network traffic, and stop assuming that "privacy-preserving" means "secure."