Escaping the Privacy Sandbox with Client Side Deanonymization Attacks

Escaping the Privacy Sandbox with Client Side Deanonymization Attacks

Speakers: Eugene Lim, Security Engineer

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=cFFhHXPsilw

Overview

In this insightful DEF CON talk, Eugene Lim, also known as Space Raccoon, delved into the intricacies of Google's Privacy Sandbox and exposed critical client-side deanonymization vulnerabilities within its Attribution Reporting API. While Google positions the Privacy Sandbox as a privacy-preserving alternative to third-party cookies, Lim's research demonstrates that its complex design and attempts to satisfy conflicting interests of advertisers and privacy advocates have introduced significant security flaws. The talk served as a deeper dive into findings previously presented on the main stage, offering granular technical details and a behind-the-scenes look at the research process.

Lim’s work is particularly timely given the ongoing debate around online privacy and advertising. Despite Google’s recent decision to delay the complete phase-out of third-party cookies, the Privacy Sandbox remains actively deployed and utilized across a vast array of Chromium-based browsers and by major ad technology platforms beyond Google itself. This research underscores the persistent challenges in designing truly private advertising systems and highlights how even well-intentioned privacy mechanisms can be subverted when fundamental assumptions about web security are altered or overlooked.

The presentation not only unveiled specific attack vectors—including a bypass of Referrer-Policy: no-referrer via debug reports and a novel destination hijacking technique leveraging undocumented rate limits for deanonymization—but also served as a call to action for security researchers to scrutinize the often-opaque world of ad technology. Lim effectively illustrated that the pursuit of both extensive user tracking for advertisers and robust privacy guarantees for users often leads to compromises that can be exploited, challenging the very notion of "privacy-preserving ad tech" as an oxymoron.

Background

▶ Watch: Introduction to talk, speaker, and Privacy Sandbox (0:00)

The digital advertising landscape is undergoing a significant transformation, primarily driven by increasing privacy regulations like GDPR and CCPA, as well as growing consumer adoption of ad blockers and privacy-enhancing tools. For decades, third-party cookies have been the backbone of online ad targeting and conversion tracking, allowing advertisers to build comprehensive user profiles across different websites. However, the widespread privacy concerns associated with these cookies have led major browsers, most notably Google Chrome, to announce their eventual deprecation.

In response to this shift, Google introduced the Privacy Sandbox, a suite of experimental JavaScript APIs designed to replace the functionalities of third-party cookies while ostensibly enhancing user privacy. The Privacy Sandbox operates within a walled garden ecosystem, requiring ad technology companies to apply and be whitelisted by Google to utilize its APIs. Furthermore, it incorporates concepts like Trusted Execution Environments (TEEs) for aggregated data analysis, aiming to prevent direct access to individual user data. However, Lim’s research focused specifically on the client-side JavaScript APIs, particularly the Attribution Reporting API, which is central to tracking ad conversions without traditional cross-site identifiers.

The Attribution Reporting API's core function is to determine if a user's interaction with an ad (e.g., viewing or clicking) eventually led to a desired action, known as a conversion (e.g., a purchase or sign-up) on an advertiser's website. Google's design attempts to achieve this in a privacy-preserving manner by introducing several mechanisms:

1. Randomization: Introducing delays and randomness in when reports are sent to obscure individual timing.
2. Limited Information: Restricting the types and amount of data that can be captured within the API schema (e.g., integers, debug keys).
3. Rate Limits: Imposing caps on how much information can be collected for a specific user over time.
4. Statistical Noise: Deliberately adding ambiguity to individual data points, ensuring aggregate data remains accurate while making individual tracking more difficult.

Despite Google's announcement to delay the complete phase-out of third-party cookies, Lim emphasized that the Privacy Sandbox is not only still in active use but also widely adopted by major ad tech platforms like Criteo, Facebook, and Amazon, extending its reach far beyond Google's own DoubleClick platform. This pervasive deployment, coupled with the inherent complexity and often opaque nature of ad technology, makes understanding its security implications crucial. Lim's research highlights that the tension between meeting advertiser demands for detailed conversion tracking and satisfying user privacy expectations creates a fertile ground for vulnerabilities, as attempts to bridge this gap often lead to "escape hatches" that undermine the intended privacy protections.

Key Findings

▶ Watch: Google's reversal on cookies and why research still matters (2:50)

Eugene Lim's research uncovered two primary client-side deanonymization attacks against Google's Privacy Sandbox, specifically targeting the Attribution Reporting API:

1. Attribution Reporting Debug Reports Bypass of Referrer-Policy: no-referrer: Lim discovered that the debug reports feature, intended as a transitional "escape hatch" to provide advertisers with more detailed data during the Privacy Sandbox's early stages, inadvertently bypasses the browser's Referrer-Policy: no-referrer directive. This policy is commonly used by websites to prevent the leakage of their origin URL to third-party resources they embed. The debug reports, however, transmit additional "debug information" that includes the top-level site's origin, effectively leaking cross-site browsing activity even when robust referrer policies are in place. This undermines a fundamental web security assumption and has implications for technologies like SafeFrame, an iframe standard designed to isolate ads and prevent top-level site leakage.

1. Destination Hijacking and Rate Limit Oracle for User Deanonymization: This was the most significant finding. Lim observed that Google DoubleClick ads were consistently injecting two additional, seemingly arbitrary domains (debugconversion1.com and debugconversion2.com) as potential conversion destinations alongside the legitimate advertiser's domain. Lim promptly registered these domains. By controlling these debug domains and exploiting an undocumented rate limit within the Attribution Reporting API (specifically, a limit of 1,000 reports per destination), he was able to construct a boolean oracle. This oracle could determine with high confidence whether a user had previously visited a specific website or performed a particular conversion action. This technique allows an attacker to deanonymize a user's browsing history, a capability explicitly forbidden by the Privacy Sandbox's design goals.

These findings collectively demonstrate that despite Google's efforts to build a privacy-preserving ad technology, the practical implementation contained critical flaws that allowed for the very cross-site tracking and individual deanonymization it sought to prevent. The attacks highlight the inherent difficulty in balancing advertiser needs for data with user privacy, leading to complex systems where unintended side effects and vulnerabilities can emerge.

Technical Deep Dive

▶ Watch: Key reasons to understand Privacy Sandbox technology (3:40)

The core of Lim's research revolves around the Attribution Reporting API, an experimental JavaScript API in Chrome and Chromium browsers designed to track ad conversions without relying on third-party cookies. The API operates through a two-step process:

1. Source Registration: When a user views or clicks an ad on a publisher's website, the browser makes an asynchronous call to an ad tech server (e.g., Google's DoubleClick). This request contains information about the ad. The ad tech server responds with an Attribution-Reporting-Register-Source HTTP header, which includes a JSON string containing metadata about the ad, such as its intended destination. This source information is then stored locally in the user's Chrome browser storage. The header might look something like:

Lim observed fields like reporting origin, destination, aggregation keys, and debug key being stored, all potentially used to identify a session uniquely.

1. Conversion Trigger: If the user later performs a conversion action (e.g., makes a purchase, signs up) on the advertiser's website, a second request is sent by the browser. This request, again triggered by an HTML element with an attribution source attribute or an XHR option, signals a conversion. The ad tech server responds with an Attribution-Reporting-Register-Trigger HTTP header. This response can include filters which allow the ad tech platform to specify conditions for a valid conversion (e.g., "only count if the user bought flights to Peru, not Singapore").

1. Matching and Reporting: The browser then attempts to match the newly received trigger information with any stored source registrations. If a match is found based on criteria like destination and filters, the browser sends an event report to the ad tech server, confirming a successful conversion. Importantly, this entire process—from source registration to conversion report—is handled asynchronously by the browser itself, outside the direct control or JavaScript context of the website the user is currently viewing.

Lim's research methodology involved deep inspection of this process. He used the Chrome debug tab (accessible via chrome://attribution-internals) to observe real-time source registrations and triggers, noting the detailed information being captured. He also used network traffic analysis tools to monitor HTTP requests and responses containing Attribution-Reporting headers, identifying a wide range of ad tech platforms beyond Google using these APIs (e.g., Taboola, Quora, Facebook, LinkedIn).

A crucial aspect of his research involved understanding the Privacy Sandbox's "walled garden" nature. While it requires companies to be whitelisted, Lim found it initially easy to sign up as an individual (though Google later suspended his account and tightened validation, requiring a valid TIN). Being whitelisted is essential, as Chrome blocks attribution callbacks from non-approved domains. He also extensively leveraged Google's GitHub documentation for the Privacy Sandbox, noting that it often contained more detailed, and sometimes revealing, information and "to-do" comments than the corporate-facing documentation. One such "to-do" hinted at the cross-site leak issue with debug reports: "consider adding support for top level sites to opt into receiving debug reports without cross-sight leak."

Attack 1: Debug Reports Cross-Site Leak

The debug reports mechanism was designed as a temporary measure to give advertisers more granular, non-aggregated data. Lim demonstrated that these reports inherently bypass the Referrer-Policy: no-referrer HTTP header. This policy is a common mitigation used by websites to prevent their origin URL from being sent in the Referer header when loading third-party resources. For example, if websiteA.com loads an image from websiteB.com with no-referrer set, websiteB.com shouldn't know that the image was loaded from websiteA.com.

However, when an ad served on websiteA.com triggers an Attribution API source registration with debug reports enabled, the debug report sent to the ad tech server (even if it's a third-party origin) will still contain information about websiteA.com's origin. This constitutes a cross-site leak, as it effectively bypasses the intended privacy protection of no-referrer. This is particularly problematic for technologies like SafeFrame, an iframe standard designed to isolate ad content and prevent ads from accessing information about the top-level site. Lim showed that the Attribution API's debug reports could be used to leak the top-level site's URL even when the ad was embedded within a SafeFrame, undermining its security guarantees.

To test this, Lim had to find a way to serve custom HTML/JavaScript ads. While most ad platforms sanitize uploaded ad creatives carefully, Google Ads' desktop software allowed him to upload HTML5 ads with custom JavaScript, bypassing the need to spend $10,000 typically required for arbitrary ad content. His custom HTML included the attribution source attribute, allowing him to observe the debug report behavior.

Attack 2: Destination Hijacking and Rate Limit Oracle

The more impactful attack centered on destination hijacking. Lim discovered that Google DoubleClick ads were programmatically injecting two additional, non-standard destinations into the source registration header for every ad: debugconversion1.com and debugconversion2.com. These domains were available for registration, which Lim promptly did.

By controlling these domains, Lim turned them into attacker-controlled endpoints for Attribution API reports. The crucial insight came from exploiting an undocumented rate limit within the Attribution API. He found that the browser would only send up to 1,000 reports for a specific destination. This limit, intended to prevent excessive data collection, became the foundation of his boolean oracle.

Here's how the oracle works:

1. Setup: The attacker, controlling debugconversion1.com, serves an ad that includes debugconversion1.com as an additional potential conversion destination.
2. Scenario A (User DID NOT visit target website / perform conversion): If the user later visits debugconversion1.com (which the attacker controls), the attacker can trigger 1,000 conversion reports to their own domain.
3. Scenario B (User DID visit target website / perform conversion): If the user had previously visited a specific target website (e.g., samrush.com from the talk example) and a legitimate conversion report was already sent for that ad (which also included debugconversion1.com as a potential destination), then when the user later visits debugconversion1.com, the attacker can only trigger 999 additional reports to their domain. This is because one report was already consumed by the legitimate conversion.

By observing whether 999 or 1,000 reports are received on debugconversion1.com after the user visits it, the attacker can infer whether the user performed a conversion action on the target website. By strategically varying the "filters" in the conversion trigger, the attacker can refine the information extracted, effectively deanonymizing a user's browsing history by determining if they visited specific sites or performed specific actions. This provides a binary (yes/no) answer to questions about a user's past browsing behavior, completely circumventing the Privacy Sandbox's intended privacy protections.

Lim emphasized that these attacks highlight the inherent conflict in designing "privacy-preserving" ad technology. The constant need to provide some form of data to advertisers, even if aggregated or limited, introduces complexity and potential "escape hatches" that can be abused for deanonymization.

Demo / Proof of Concept

▶ Watch: Overview of Privacy Sandbox components and design (4:40)

While Eugene Lim's talk did not feature a live, interactive demonstration of the exploits, his presentation thoroughly detailed the methodology and observations that served as his proof of concept. The attacks were validated through a combination of practical experimentation and deep analysis of the Privacy Sandbox's mechanisms.

For the Referrer-Policy: no-referrer bypass, Lim described how he uploaded custom HTML5 ads containing the attribution source attribute via the Google Ads desktop software. This allowed him to inject his own JavaScript and HTML into ad creatives, which would then trigger Attribution API calls. By monitoring network requests and responses using standard browser developer tools and observing the debug reports, he confirmed that the top-level site's origin was indeed leaked, even when a no-referrer policy was in effect. This direct observation of the leaked referrer information within the debug reports served as the proof.

For the destination hijacking and rate limit oracle attack, the proof of concept involved:

1. Identifying Injected Domains: Lim systematically observed the Attribution-Reporting-Register-Source headers from Google DoubleClick ads and noticed the consistent injection of debugconversion1.com and debugconversion2.com.
2. Domain Acquisition: He then acquired these domains, gaining control over the endpoints that would receive conversion reports.
3. Oracle Construction: By crafting specific scenarios where a user either did or did not trigger a legitimate conversion on a target website, and then subsequently driving the user to his controlled debugconversion1.com to trigger a large number of reports, he could differentiate between 999 and 1,000 received reports. This difference served as the binary signal confirming the user's prior action. The ability to reliably differentiate these report counts, combined with the ability to filter for specific conversion types, empirically demonstrated the deanonymization capability.

These steps, meticulously documented and explained, constituted the practical validation and proof of concept for both attack vectors, showcasing how the Privacy Sandbox's design could be subverted for privacy-invasive purposes.

Defensive Implications

▶ Watch: Focus: Client-side attacks and the Attribution API (6:40)

Eugene Lim's research offers several critical defensive implications for various stakeholders in the web ecosystem:

1. For Ad Technology Platforms (including Google):

• Rethink "Escape Hatches": Features like "debug reports," intended as temporary or transitional, often become permanent attack surfaces. Their design must be rigorously scrutinized for unintended information leakage, especially when they bypass existing browser security mechanisms like Referrer-Policy.
• Robust Sanitization and Whitelisting: Ad platforms must implement stricter sanitization for uploaded ad creatives, not just for traditional XSS but also for novel API calls that might trigger cross-origin requests or information leaks. The whitelisting process for Privacy Sandbox participation needs continuous strengthening to prevent malicious actors from gaining access.
• Thorough Security Audits of New APIs: The introduction of complex, experimental APIs like the Attribution Reporting API requires extensive security review before widespread deployment. This includes considering interactions with existing web security models (e.g., Referrer-Policy, SafeFrame) and potential side effects of design choices (e.g., injected debug domains, undocumented rate limits).
• Transparent Documentation of Rate Limits and Behaviors: Undocumented behaviors, such as the 1,000-report rate limit, create exploitable information asymmetry. All critical API behaviors and limits should be publicly documented to allow for broader security scrutiny.
• Minimize Injected Debug Domains: The practice of injecting debugconversionX.com domains by ad platforms should cease. If debug destinations are necessary, they should be tightly controlled by the ad platform itself and not left open for acquisition.

1. For Browser Vendors (especially Chromium-based):

• Holistic Security Model Review: When integrating new web APIs, browser developers need to assess their impact on the entire web security model, not just their isolated functionality. Interactions with referrer policies, iframe sandboxing, and other privacy mechanisms must be thoroughly evaluated.
• Strengthen API Design for Privacy: The core design principles of privacy-preserving APIs need continuous re-evaluation. The tension between advertiser data needs and user privacy is difficult, but the current compromises appear to favor data collection, leading to deanonymization risks.

1. For Website Owners and Publishers:

• Understand Ad Tech Risks: Even if you decline third-party cookies, understand that other mechanisms like the Privacy Sandbox APIs might still be active and collecting data.
• Monitor Network Traffic: Regularly inspect network traffic from your website, particularly those related to ad delivery, to identify any unexpected or suspicious API calls or domain injections.
• Advocate for Stronger Privacy Controls: Support and pressure browser vendors and ad tech companies to prioritize user privacy in their API designs.

1. For End-Users:

• Maintain Vigilance: Ad blockers and privacy extensions are still valuable, but new tracking methods will continually emerge. Stay informed about new privacy-invasive techniques.
• Inspect Browser Internals: Tools like chrome://attribution-internals can provide insight into what data is being tracked by the Privacy Sandbox APIs, empowering users to understand their digital footprint.
• Be Skeptical of "Privacy-Preserving Ad Tech": Lim's talk reinforces that this concept is often an oxymoron. Users should be aware that efforts to collect data for advertising, even with privacy claims, often come with inherent risks to individual anonymity.

Key Takeaways

• "Privacy-preserving ad tech" is inherently challenging and often an oxymoron. The need to satisfy both advertisers' data requirements and users' privacy expectations creates complex systems prone to vulnerabilities.
• The Privacy Sandbox, despite its intentions, has significant client-side deanonymization flaws. Eugene Lim's research exposed critical vulnerabilities in the Attribution Reporting API, demonstrating that it can be used for cross-site tracking and user deanonymization.
• Debug reports bypass Referrer-Policy: no-referrer and undermine SafeFrame. A transitional feature designed to aid advertisers inadvertently leaks top-level site information, compromising existing web security and privacy mechanisms.
• Undocumented rate limits can be weaponized for privacy invasion. By combining destination hijacking with an unadvertised 1,000-report rate limit, a boolean oracle can be created to infer a user's past browsing history or conversion actions.
• Ad technology remains an under-researched attack surface. The complexity and opacity of ad tech, coupled with its pervasive presence across the internet, make it a fertile ground for security researchers to uncover new vulnerabilities.
• Browser vendors and ad platforms must rigorously scrutinize new API designs. A holistic review of how new APIs interact with existing web security models is crucial to prevent unintended side effects and privacy compromises.

About the Speaker(s)

Eugene Lim, who goes by the hacker handle Space Raccoon online, is a Security Engineer by profession. In his day job, he works with a team focused on cybersecurity. Beyond his professional role, Lim is an enthusiastic hobbyist in reverse engineering and low-level research. His previous research endeavors include investigating the security of smart weighing scales connected to the internet, a project that, like his work on the Privacy Sandbox, highlights his interest in uncovering vulnerabilities in seemingly innocuous or complex connected technologies. His presentation style is characterized by a deep technical understanding, a clear explanation of complex systems, and a passion for exploring under-researched areas of cybersecurity.