How Chrome Protected Audiences API Runs On-Device Ad Auctions

What is the FLEDGE / Protected Audience API?

The fledge protected audiences api is Google Chrome’s Privacy Sandbox framework for privacy-preserving ad retargeting. It moves ad auctions from central servers into the user’s browser using Isolated Worklets. Instead of tracking users across sites with third-party cookies, advertisers store interest groups locally on the client device. When a user visits a publisher site, the browser evaluates buyer bids and seller scores internally, rendering winning ad creatives inside isolated Fenced Frames to prevent cross-site identity leakage.

Retargeting Beyond Cookies: Why Chrome Built the Protected Audience API

For decades, remarketing and behavioral retargeting relied on third-party tracking cookies. When a consumer browsed a travel booking site for flights to Tokyo without completing a purchase, the travel site’s ad network attached a tracking cookie to the browser. As that user subsequently browsed unrelated news portals or blogs, third-party scripts read the cookie, identified the user’s commercial intent, and dynamically served targeted flight advertisements.

As browser privacy standards evolved, third-party cookies were recognized as an unacceptable security and privacy vulnerability. They allowed ad exchanges to continuously log user browsing trails across millions of domains without explicit consent. However, complete elimination of remarketing capabilities threatened to destabilize digital publisher monetization ecosystems.

To resolve this tension, Google introduced FLEDGE (First Locally-Executed Decision over Groups Experiment), later formally renamed the Protected Audience API. The architectural shift is profound: ad selection and auction logic are moved from centralized server-side ad exchanges directly into the user’s local web browser. By transforming the browser into an ad auction engine, Google aimed to preserve remarketing revenue models while eliminating the unconstrained cross-site tracking capabilities historically enjoyed by third-party ad networks. However, maintaining true digital anonymity requires users to understand how these client-side APIs function alongside broader anonymous browsing principles.

Architecture of On-Device Ad Auctions: The 5 Core Components

The Protected Audience API relies on five specialized web primitives and execution containers operating within the browser. Each component handles a specific phase of the interest-based advertising lifecycle.

1. Interest Groups (`joinAdInterestGroup`)

An interest group represents a collection of users who share a common intent, interest, or commercial activity (e.g., “users who added shoes to a shopping cart in the last 7 days”). When a user performs an action on an advertiser’s website, the advertiser’s JavaScript invokes the JavaScript API method navigator.joinAdInterestGroup().

const interestGroup = {
  owner: "https://ad-network.example",
  name: "shoes-abandoned-cart",
  biddingLogicUrl: "https://ad-network.example/bidding-logic.js",
  trustedBiddingSignalsUrl: "https://ad-network.example/bidding-signals",
  userBiddingSignals: { category: "footwear", priceTier: "premium" },
  ads: [
    {
      renderURL: "https://ad-network.example/ads/running-shoe-1.html",
      metadata: { sku: "RS-9000", discount: 0.15 }
    }
  ]
};

const joinResponse = await navigator.joinAdInterestGroup(interestGroup, 2592000);

The browser validates that the domain calling the function matches the owner origin (or is explicitly authorized by it) and stores the interest group object in a local browser database for up to 30 days.

2. Buyer Bidding Scripts (`generateBid`)

When an ad space becomes available on a publisher site, the browser locates all stored interest groups matching the auction criteria. For each qualified interest group, the browser executes a buyer-provided JavaScript function named generateBid(). This script evaluates the context of the auction, inspects real-time inventory signals, and returns a numeric bid value along with the render URL of the ad candidate.

3. Seller Scoring Scripts (`scoreAd`)

The seller—typically a Supply-Side Platform (SSP) or publisher ad server—provides a JavaScript scoring script hosted at a secure endpoint. Inside the browser, the seller’s scoreAd() function receives all buyer bids submitted during the auction. The scoring script evaluates each bid based on price, publisher content filters, creative quality scores, and publisher yield optimization rules, returning a numerical score for each bid.

4. Isolated Worklets (V8 Execution Environments)

To prevent buyer bidding scripts and seller scoring scripts from communicating with each other or leaking user identity to external servers, Chrome executes these scripts inside isolated V8 execution containers called Isolated Worklets. An Isolated Worklet is a lightweight, heavily restricted thread that lacks DOM access, cannot read window properties, cannot access localStorage or cookies, and has all arbitrary network access (e.g., fetch, WebSocket, XMLHttpRequest) completely disabled.

5. Fenced Frames & Untrusted Render Containers

Even if an ad auction is conducted privately inside an Isolated Worklet, rendering the winning ad inside a traditional HTML <iframe> would expose the user’s identity. In a standard iframe, the ad creative could execute JavaScript that communicates with the host publisher page via window.postMessage(), or leak identity by embedding user IDs in external image URL parameters.

To solve this, Chrome introduced Fenced Frames (<fencedframe>). A Fenced Frame is a secure HTML element specifically engineered for privacy-sensitive embedded content:

• No Cross-Boundary Messaging: Fenced Frames cannot communicate with their parent host page via JavaScript messaging APIs.
• Network State Isolation: Network requests originating inside a Fenced Frame do not share un-partitioned HTTP caches, cookies, or socket pools with the host page.
• Opaque Source URLs: The host publisher page cannot inspect the actual URL rendered inside the Fenced Frame; it only receives an opaque internal URN identifier (e.g., urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).

Detailed Execution Flow of a Protected Audience Auction

Conducting an on-device ad auction requires a highly structured multi-stage execution pipeline managed entirely by the browser engine.

Auction Stage	Location & Entity	Primary Function & API Call	Privacy Boundary Applied
1. Group Registration	Advertiser Site / Client Browser	navigator.joinAdInterestGroup()	Stored in client-side SQLite DB; invisible to host site.
2. Signal Retrieval	Trusted Key-Value (KV) Server	HTTP GET to TEE Endpoint	Server runs inside TEE; logs no user IP or request keys.
3. Buyer Bidding	Client Browser (Buyer Worklet)	generateBid()	No DOM, storage, or external network access permitted.
4. Seller Scoring	Client Browser (Seller Worklet)	scoreAd()	Scores bids in isolation; cannot modify buyer payloads.
5. Ad Rendering	Publisher Page / Fenced Frame	<fencedframe src="urn:uuid:...">	Opaque URL rendering; no parent-child DOM messaging.

Stage 1: Interest Group Membership Registration

When a consumer browses an e-commerce platform, advertiser tracking scripts evaluate user behavior. If the user meets retargeting criteria, the script registers an interest group. The browser enforces limits on interest groups: a single origin can store up to 2,000 groups, and total interest group storage per browser profile is capped to prevent storage bloat.

Stage 2: Real-Time Signal Retrieval via Trusted Key-Value Services

Bidding scripts require dynamic real-time information, such as current product stock availability or remaining campaign budgets. Because standard network fetch() calls are disabled inside Isolated Worklets, Chrome fetches real-time data from special Trusted Key-Value (KV) Services.

To satisfy strict privacy guarantees, KV Services must run inside cloud-based Trusted Execution Environments (TEEs) with cryptographic attestation. The TEE guarantees that the server operator cannot inspect, log, or record incoming key queries, ensuring that retrieval of bidding signals does not create a covert tracking channel.

Stage 3: Client-Side Bidding Script Execution (`generateBid`)

The browser spawns a dedicated Isolated Worklet for each interest group owner and invokes generateBid():

function generateBid(interestGroup, auctionSignals, perBuyerSignals, trustedBiddingSignals, browserSignals) {
  const ad = interestGroup.ads[0];
  const priceMultiplier = trustedBiddingSignals.inStock ? 1.0 : 0.0;
  
  return {
    bid: 2.50 * priceMultiplier,
    render: ad.renderURL,
    allowComponentAuction: false
  };
}

The worklet calculates the bid based on local interest group metadata and remote trusted signals, returning the result to the browser auction runner.

Stage 4: Seller Scoring Script Execution (`scoreAd`)

Once all buyer bids are generated, the browser collects the outputs and passes them into the seller’s Isolated Worklet, invoking scoreAd():

function scoreAd(adMetadata, bid, auctionConfig, trustedScoringSignals, browserSignals) {
  let score = bid * 1.2; // Apply publisher yield multiplier
  if (adMetadata.sku === "BANNED-ITEM") {
    return 0; // Filter out prohibited creatives
  }
  return score;
}

Stage 5: Winning Ad Selection, Fenced Frame Rendering, and Reporting

The browser identifies the bid with the highest numerical score. Instead of returning the raw ad URL to the publisher page, the browser registers the winning ad in an internal map and returns an opaque URN. The publisher creates a <fencedframe> element and assigns the URN as its source. Finally, the browser sends delayed, aggregate event reports to the winning buyer and seller reporting endpoints.

Privacy Pros and Cons: Does On-Device Auctioning Truly Protect Users?

The Protected Audience API represents a significant architectural improvement over unconstrained third-party cookie tracking, but security researchers have highlighted notable privacy trade-offs.

Privacy Advantages: Eliminating Raw Cross-Site Identity Profiles

• No Cross-Site Cookie Ingestion: Ad exchanges can no longer build centralized, real-time browsing histories by aggregating cookie IDs across millions of domains.
• Client-Controlled State: Users can inspect, clear, or block individual interest groups directly through browser developer tools or settings pages.
• Strict Isolation Containers: The combination of Isolated Worklets and Fenced Frames prevents ad creatives from extracting publisher page content or DOM state.

Privacy Disadvantages: Interest Profiling, State Persistence, and Micro-Targeting Leaks

• Local Interest Accumulation: Over time, a user’s browser accumulates dozens of interest groups spanning healthcare, financial, political, and commercial categories. An adversary who gains access to the browser’s local state can reconstruct a vivid psychological and behavioral profile of the user.
• Timing and Micro-Auction Side-Channels: By observing subtle differences in execution timing between worklets, malicious publishers can infer how many interest groups a user belongs to, gradually leaking user entropy.
• Fingerprinting Cross-Contamination: Interest group evaluation engine state can be correlated with underlying GPU and hardware rendering quirks. To learn more about hardware parameter exposure, view our analysis of how a browser fingerprint explained exposes hardware configurations to passive scripts.

Why Big Tech and Ad Networks Still Dominate On-Device Ad Targeting

While the Protected Audience API democratizes on-device auction infrastructure in theory, in practice it reinforces the market dominance of major advertising platforms and tech giants.

Operating an infrastructure compliant with the Protected Audience API requires running complex Key-Value Services inside cryptographically attested cloud Trusted Execution Environments (TEEs) on AWS Nitro or Google Cloud. The immense engineering overhead, cloud hosting expenses, and algorithmic complexity of maintaining thousands of client-side bidding scripts severely disadvantage smaller independent ad networks.

Furthermore, major platforms possessing vast first-party authentication ecosystems (such as social networks and retail media giants) can bypass client-side retargeting limitations entirely by leveraging deterministic first-party logins, leaving smaller ad tech vendors dependent on complex Privacy Sandbox APIs.

How to Block or Spoof Interest Group Telemetry with Send.win Isolated Profiles

For digital marketing professionals, e-commerce managers, affiliate operators, and competitive intelligence researchers, client-side interest group accumulation creates severe operational hazards. Managing multiple commercial accounts or ad buying profiles on a standard browser installation causes interest group leakage across accounts, resulting in account linking, shadow-banning, and campaign contamination.

Standard browser solutions like clearing browsing history or opening Incognito tabs fail to maintain clean environments across continuous multi-account workflows. Send.win provides two execution options: the native Sendwin Browser desktop client (requires installation for direct local profile control) and Cloud Browser Sessions (runs isolated environments in the cloud with no local software install needed). True operational security requires complete structural isolation through multi-profile anti-detect architecture and strict session isolation.

Breaking Interest Group Persistence Across Operational Accounts

Send.win neutralizes Protected Audience API telemetry by completely segregating the local storage, API state, and hardware signatures of every browser profile:

• Database Partitioning: Every Send.win profile operates with its own isolated SQLite storage engine. Interest groups joined in Profile A are completely invisible to Profile B.
• API Behavior Control: Operators can selectively disable Privacy Sandbox APIs, block joinAdInterestGroup() calls, or inject randomized interest group configurations to obscure operational intent.
• Hardware & Canvas Obfuscation: Unique WebGL, Canvas, AudioContext, and navigator hardware parameters are spoofed per profile, preventing side-channel fingerprint correlation across auctions.
• Proxy and Geolocation Realignment: Dedicated proxy configuration ensures every profile maintains geographic and network consistency, adhering to strict safe browsing protocols across automated and manual operations.
• Flexible Plans & Automation API: Pro ($9.99/mo or $6.99/mo annual, 150 profiles, 5GB storage) and Team ($29.99/mo or $20.99/mo annual, 500 profiles, 20GB storage, 16 seats) include full Automation API support for Playwright, Puppeteer, and Selenium, plus a 30-day free trial with no credit card required.

Frequently Asked Questions

What was the original name of the Protected Audience API?

The Protected Audience API was originally developed under the acronym FLEDGE (First Locally-Executed Decision over Groups Experiment) within Google Chrome’s Privacy Sandbox initiative.

How does the Protected Audience API select which ad to display?

Instead of sending user browsing data to external ad exchanges, the user’s browser runs an on-device auction. It fetches buyer bidding scripts and seller scoring scripts, executing them inside restricted Isolated Worklets to evaluate bids and select the winning ad creative locally.

What is an Interest Group in the context of FLEDGE?

An Interest Group is a client-side data object stored locally in the browser representing a group of consumers with common interests or shopping behaviors (e.g., users who abandoned a shopping cart). It includes bidding script URLs, ad candidate render URLs, and buyer metadata.

What is an Isolated Worklet and why is it necessary?

An Isolated Worklet is a lightweight V8 JavaScript execution container with zero access to the DOM, local storage, cookies, or arbitrary network APIs. It is necessary to prevent buyer and seller scripts from exchanging private user data or communicating with external tracking servers during an ad auction.

How do Fenced Frames differ from standard HTML iframes?

Fenced Frames prohibit JavaScript messaging (`postMessage`) with the parent publisher page, do not share un-partitioned HTTP caches or cookies with the host page, and load ad content via opaque URNs, preventing the parent host site from discovering which ad or interest group won the auction.

What are Trusted Key-Value Services?

Trusted Key-Value Services are cloud endpoints hosted inside cryptographically verified Trusted Execution Environments (TEEs). They provide real-time bidding signals (such as stock levels or budget limits) to Isolated Worklets without logging or tracking user IP addresses or request keys.

Can advertisers track individual users using the Protected Audience API?

The API is designed to prevent cross-site identity tracking. However, local accumulation of interest groups over time can leak user entropy, and side-channel timing attacks or browser fingerprint correlation can still expose operational identities if profiles are not properly isolated.

How does Send.win prevent interest group tracking across multiple accounts?

Send.win segregates every browser profile into its own self-contained environment. Local Privacy Sandbox storage, interest group databases, hardware fingerprints, and proxy routing are completely isolated, preventing ad networks from linking multi-account operations through client-side ad auction telemetry.

Automate Fledge Protected Audiences Api With Send.win

Send.win pairs isolated, fingerprint-managed browser profiles with a full Automation API, so your scripts run in profiles that look and behave like real, separate users:

• Selenium, Puppeteer & Playwright support – drive any profile programmatically (Team plan)
• Isolated profiles – each with its own fingerprint, cookies, and storage
• Built-in residential proxies – with automatic timezone, locale, and WebRTC matching
• Desktop app for Windows, macOS & Linux – plus cloud sessions when you don’t want a local install

Try the instant cloud browser demo — no install, straight from your browser. Then compare plans: a 30-day free trial with no credit card, and paid plans from $6.99/month billed annually.

Related Products & Resources

• Download
• Pricing
• Proxy Browser Setup Browser Isolation Guide 2026
• Web Browsing Security Privacy Security Guide 2026
• Webgl Fingerprinting Complete Guide 2026