Escaping the Privacy Sandbox with Clientside Deanonymization Attacks

Escaping the Privacy Sandbox: Client-Side Deanonymization Attacks

Speaker: Eugene Lim (Space Raccoon)

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/

Overview

Google's Privacy Sandbox is the industry's most ambitious attempt to replace third-party cookies with privacy-preserving alternatives for the web advertising ecosystem. Conceived as a way to maintain the functionality advertisers depend on — conversion tracking, audience targeting, attribution — while eliminating the cross-site tracking that makes third-party cookies a privacy liability, the Privacy Sandbox represents years of design effort, IETF and W3C standardization work, and Chrome engineering investment. Its APIs are live in Chrome and Chromium-based browsers including Microsoft Edge, serving hundreds of millions of users today.

At DEF CON 33, Eugene Lim (online handle: Space Raccoon), an application security researcher from Singapore, presented a systematic attack analysis of Privacy Sandbox APIs — specifically the Attribution Reporting API and Shared Storage API — demonstrating that client-side security bugs in these APIs can be exploited to deanonymize users, cross-site track users (the exact behavior the sandbox was designed to prevent), and perform data exfiltration through what he characterized as "insecure worklet code." The research is significant not only for its technical findings but for its context: Google announced in April 2025 (shortly after Lim submitted his talk) that it was abandoning plans to use the Privacy Sandbox to fully replace third-party cookies — but the Privacy Sandbox APIs remain live, deployed, and used by ad tech companies.

Background

▶ Watch: Introduction: Chrome's Privacy Sandbox and its goals (0:02)

Why the Privacy Sandbox Was Built

Third-party cookies enable the tracking of users across websites by embedding resources from a shared third-party domain (typically an ad network) that sets and reads cookies regardless of which first-party site the user is visiting. This mechanism is the foundation of:

• Cross-site user tracking: Building behavioral profiles of users across their entire web activity.
• Conversion attribution: Determining whether a user who viewed an ad on site A subsequently made a purchase on site B.
• Audience targeting: Matching users to advertising segments based on aggregated browsing history.

The privacy implications are well-understood, and browsers have progressively restricted third-party cookies through a combination of vendor policy (Safari's ITP, Firefox's Total Cookie Protection) and legal pressure (GDPR, ePrivacy Directive, CCPA). Chrome's late adoption of restrictions created the impetus for the Privacy Sandbox project.

Privacy Sandbox Architecture

The Privacy Sandbox encompasses several distinct APIs designed to replace specific third-party cookie use cases:

• Attribution Reporting API: Replaces cross-site conversion tracking. Records "sources" (ad impressions/clicks) and "triggers" (conversions) and produces aggregated, privacy-protected attribution reports.
• Protected Audience API (formerly FLEDGE): Enables on-device ad auctions using locally stored interest group membership, avoiding server-side user profile lookups.
• Topics API: Infers the user's broad interest categories from browsing history for ad targeting, without exposing specific URLs.
• Shared Storage API: Provides cross-site read/write storage with access restrictions designed to prevent direct cross-site data leakage.

The design philosophy is "privacy through computation" — perform the advertising function on the client device, return only aggregated or noise-protected results, and prevent any single party from correlating user data across sites in a way that identifies individuals.

The Worklet Architecture

Several Privacy Sandbox APIs use a "worklet" execution model. A worklet is an isolated JavaScript execution context with restricted capabilities:

• Cannot make network requests.
• Cannot access most browser APIs.
• Communicates results only through defined, constrained output channels (aggregated reports, filtered outputs).

The worklet model is supposed to enable computation on sensitive data while preventing that data from being exfiltrated. The research identifies cases where this containment fails.

Key Findings

▶ Watch: Browser fingerprinting techniques that bypass Privacy Sandbox (12:29)

1. Attribution Reporting API: Cross-Site Tracking via Source/Trigger Manipulation

The Attribution Reporting API operates through a source-trigger registration flow:

Source registration: When a user views or clicks an ad on a publisher site, the browser registers an attribution source. The source includes a destination (the advertiser's origin) and is stored in client-side browser storage.

Trigger registration: When the user performs a conversion action on the advertiser's site (purchase, signup), the browser looks up matching sources and generates an attribution report.

Lim identified that the matching logic between sources and triggers, and the contents of the attribution reports produced, can be manipulated by adversarial ad tech code to encode cross-site user identifiers:

• Source data encoding: The source registration accepts a source_event_id — a value set by the ad server that is encoded into attribution reports. A malicious ad network can use this field to encode a user-specific identifier rather than a generic ad campaign ID.
• Trigger data correlation: The trigger registration accepts trigger_data which is also encoded into reports. By coordinating source and trigger registrations, an ad tech company controlling both sides of an attribution flow can encode a user identifier that survives across both endpoints.
• Report content as a covert channel: Attribution reports are sent to reporting endpoints controlled by the ad network. The combination of source_event_id and trigger_data in a report — even if nominally "aggregated" — can be structured to identify specific user sessions.

The result is a mechanism that functionally replicates cross-site user tracking through the Privacy Sandbox's own attribution reporting infrastructure.

2. Shared Storage API: Covert Cross-Site Data Exfiltration

The Shared Storage API provides a key-value store that any origin can write to but can only read from within a restricted worklet context. The intent is to allow cross-site computations (like frequency capping) without exposing raw data to the calling origin's main context.

Lim demonstrated that limitations in the Shared Storage worklet's containment model allow exfiltration of data written by one origin to be read and exfiltrated by another:

• Worklet timing channels: The Shared Storage worklet's output channels (specifically the selectURL operation, which allows choosing between a set of URLs based on storage values) create observable timing differences that can encode data bits.
• URL selection as a binary channel: The selectURL operation returns one of N provided URLs based on computation in the worklet. An adversary controlling the calling context can provide URLs that, when fetched, signal data values back to the adversary's server — effectively reading Shared Storage values through the "privacy-safe" output channel.
• Cross-origin data correlation: Data written by an origin during a legitimate user interaction can be read by a different origin via the worklet covert channel, undermining the cross-origin isolation that Shared Storage is designed to enforce.

3. Identity Deanonymization Through API Combination

The most significant finding combines multiple Privacy Sandbox APIs:

1. Topics API exposes browsing history categories that can narrow the population a user belongs to.
2. Attribution Reporting API can encode a persistent cross-site identifier in report fields.
3. Shared Storage can persist this identifier and make it accessible across sites via the worklet channel.

The combination produces a mechanism for cross-site user tracking and deanonymization that uses only APIs Google designed for privacy preservation — exploiting the gaps between individual APIs' threat models rather than breaking any single API's encryption or access controls.

Technical Deep Dive

▶ Watch: Live demo: identifying users across sites using Privacy Sandbox APIs (27:29)

Attribution Reporting API: The Source-Trigger Flow

The complete attribution flow that enables the attack:

1. User visits publisher site hosting an ad served by attacker-controlled ad network.
2. Ad network registers source: Sends a response with the Attribution-Reporting-Register-Source header, setting source_event_id to a value encoding the user's identity (e.g., a hash of IP address, browser fingerprint, or first-party cookie).
3. User visits advertiser site (the "destination") and performs a conversion action.
4. Ad network script registers trigger: Sends a request with the Attribution-Reporting-Trigger header, including trigger_data that encodes the user's identity on the advertiser side (derived from advertiser's first-party data).
5. Browser generates attribution report: The browser's attribution reporting system matches the source (from publisher visit) to the trigger (from advertiser conversion) and sends a report to the reporting endpoint specified in the source registration.
6. Attacker correlates: The attacker's reporting endpoint receives a report containing the source_event_id (user ID from publisher side) and trigger_data (user ID from advertiser side). Since both encode the same user, this constitutes a cross-site linkage of the user's identity across the publisher and advertiser sites.

The "aggregation" that Privacy Sandbox is supposed to enforce is an option in the API's aggregate report type — the event-level report type used in this attack does not enforce aggregation in the same way, and the encoding of user identifiers in the event ID fields is not restricted by the API.

Shared Storage Worklet: The selectURL Covert Channel

The selectURL operation in Shared Storage worklets:

The calling context:

By iterating across multiple bits (calling selectURL multiple times with different URL sets), an attacker can exfiltrate arbitrary data stored in Shared Storage by any origin. The worklet's restrictions prevent direct return of the value to JavaScript, but the URL selection output channel was not designed with this covert channel model in mind.

The "Privacy Through Computation" Threat Model Gap

The fundamental insight is that Privacy Sandbox's threat model assumes that the constrained output channels of worklets (aggregated reports, URL selections) cannot be used to reconstruct individual user identifiers. The research demonstrates this assumption fails when:

• Event-level API parameters accept arbitrary attacker-controlled values.
• Output channels with small state spaces (URL selection from N options) can be iterated to exfiltrate arbitrary data.
• Multiple APIs with overlapping access to client-side state can be chained to correlate data across their individual privacy boundaries.

Demo / Proof of Concept

▶ Watch: How users and researchers can detect these attacks (37:29)

Lim demonstrated:

1. Live Chrome debug view: Showing source registrations, trigger registrations, and attribution reports being generated in real time in a test browsing session — using the Chrome DevTools attribution reporting debugger.

1. Cross-site tracking PoC: A test scenario with a publisher site and an advertiser site, both controlled by the attacker, showing how a user identifier encoded in source registration data survived through to the attribution report and was received at the attacker's reporting endpoint.

1. Shared Storage exfiltration: A proof-of-concept demonstrating the selectURL covert channel, exfiltrating a stored value from Shared Storage through URL selection to an attacker-controlled server.

The demos ran in an unmodified Chrome browser with no extensions, exploiting only the native Privacy Sandbox API behavior.

Defensive Implications

▶ Watch: Policy and technical recommendations for Privacy Sandbox (42:29)

For Browsers and Google

• Restrict source_event_id cardinality: Limiting the entropy of the source_event_id field (e.g., capping it to a small number of bits, or enforcing aggregation requirements before it is included in reports) would reduce its utility as a cross-site user identifier channel.
• Enforce aggregation uniformly: The distinction between event-level and aggregate report types creates a gap where event-level reports can be used without the privacy protections that aggregate reports enforce. Review whether event-level reports are necessary for legitimate use cases.
• Redesign selectURL output semantics: Add rate limiting, noise injection, or other privacy mechanisms to the selectURL output channel to prevent iterative exfiltration.
• Threat model documentation: Explicitly document that Privacy Sandbox APIs are not designed to prevent ad networks that control both publisher and advertiser integrations from correlating users across those properties.

For Web Developers and Site Owners

• Audit third-party ad code: Ad tech scripts integrated into publisher and advertiser sites can perform Attribution Reporting API registrations. Review what values these scripts are encoding in source and trigger fields.
• Implement CSP restrictions on reporting endpoints: Content Security Policy can restrict which origins your site is allowed to send attribution reports to, limiting which parties receive correlated user data.
• Understand that Privacy Sandbox is not a privacy guarantee for users: Implementing Privacy Sandbox APIs does not make your site privacy-preserving if the ad tech partners you work with exploit the API's flexibility to perform cross-site tracking.

For Users

• Disable Privacy Sandbox features: In Chrome, navigate to Settings → Privacy and Security → Ad privacy and disable all three categories (Ad topics, Site-suggested ads, Ad measurement). This prevents Privacy Sandbox APIs from functioning on your device.
• Use browsers that don't implement Privacy Sandbox: Firefox and Safari do not implement Privacy Sandbox APIs; many Chromium-based browsers allow disabling them.
• Understand that Privacy Sandbox is still third-party code on your device: The APIs run client-side in your browser, and the JavaScript that controls them is served by ad networks — shifting where tracking computation happens, but not eliminating the ad network's role in your browsing session.

Key Takeaways

1. Privacy Sandbox APIs can be misused to perform cross-site tracking — the exact behavior they were designed to prevent. The design assumptions about attacker capabilities do not match the capabilities of sophisticated ad tech networks.
2. Worklet containment is not complete. The selectURL output channel creates a covert channel for data exfiltration that was not accounted for in the worklet threat model.
3. "Privacy through computation" requires careful threat modeling of output channels. Moving computation to the client does not achieve privacy if the results of that computation can be used to transmit data back to the server.
4. Event-level API parameters are an under-restricted information channel. Fields like source_event_id that accept arbitrary attacker-controlled values and are included in reports should be treated as a potential tracking vector.
5. Privacy Sandbox APIs are live and used. Google's April 2025 announcement that it was not fully replacing third-party cookies does not remove the existing APIs from production browsers — the attack surface is present in current Chrome, Edge, and other Chromium-based browsers.

About the Speaker

Eugene Lim (online handle: Space Raccoon) is an application security practitioner based in Singapore, where he works in application security for a mid-size organization. Outside his day job, he conducts independent vulnerability research across a broad range, from hardware to web technologies (including connected consumer devices). His research into Privacy Sandbox APIs reflects an interest in the intersection of advertising technology, browser security, and privacy engineering — a space where, as he noted, ad tech companies' incentive to minimize documentation about how their systems work creates significant under-researched attack surface.