Wiki · Concept · Last reviewed June 25, 2026

Protected Audience API

The Protected Audience API was a Privacy Sandbox proposal for letting the browser run remarketing ad auctions from locally stored interest groups instead of exposing ordinary third-party tracking cookies.

Definition

The Protected Audience API, formerly FLEDGE, was a Privacy Sandbox technology for interest-group advertising. Google described it as a way to serve remarketing and custom-audience ads without third parties tracking browsing behavior across sites. The core move was to put ad-selection state and auction execution inside the browser rather than making every step depend on a cross-site cookie.

The WICG draft calls Protected Audience a privacy-advancing API for interest-group-based advertising and lists major surfaces such as joinAdInterestGroup(), leaveAdInterestGroup(), and runAdAuction(). It is a Web Platform Incubator Community Group report, not a W3C Standard. That standards status matters: it was a serious browser experiment, not settled web law.

Status also changed. On October 17, 2025, Google announced that Protected Audience on Chrome and Android would be retired after feedback and low adoption. A November 2025 blink-dev intent said Chrome planned to deprecate Protected Audience in M144 and remove it in M150. Current writing should therefore discuss the API as an implemented Privacy Sandbox design with a phase-out path, not as the future default shape of web advertising.

Mechanism

The basic lifecycle has two halves. First, when a person visits an advertiser or a site acting for one, a buyer can ask the browser to add the person to an interest group by calling navigator.joinAdInterestGroup(). Google says that group has an owner, a name, and configuration data such as bidding-code URLs, ad creatives, and real-time data keys. The browser stores membership locally and exposes no general read method.

Second, when the person later visits a publisher or other seller of ad space, the seller can call navigator.runAdAuction(). Invited buyers generate bids through browser-run code; seller code scores them; the winning ad can be returned as a FencedFrameConfig for display in a Fenced Frame API surface. Google also describes Key/Value services for real-time bidding and scoring signals.

The mechanism reorganized who holds which memory. Interest-group membership sat in the browser, bidding and scoring ran in isolated worklets, and the rendered ad could be hidden behind a fenced frame or opaque URN. That design narrowed some direct cross-site tracking channels while preserving remarketing, publisher monetization, and auction reporting.

Agent Context

For AI Browsers and Computer Use, Protected Audience is a cautionary design case. A browser agent might see an ad, offer, or product prompt selected by a local auction whose interest-group state is not visible in the DOM. The agent can click without knowing whether the result came from contextual targeting, publisher first-party data, an interest group, or an ordinary third-party ad auction.

Agent logs should avoid treating a displayed ad as direct evidence of user intent. It may reflect a prior page visit, buyer configuration, publisher signals, Key/Value response, auction scoring, frequency pacing, or fallback behavior after the API is disabled. A useful record names the top-level site, seller, buyer if known, auction path, render surface, and browser support.

Governance Use

A deployment record should name the advertiser, buyer, seller, top-level publisher, interest-group owner, membership duration, bidding-code origin, scoring-code origin, Key/Value service, render URL or fenced-frame config, report destinations, enrollment status, browser version, user setting, and fallback. It should also record the use case: remarketing, publisher-owned audiences, deals, frequency pacing, or another ad-tech workflow.

The API belongs beside Real-Time Bidding, Fenced Frame API, Topics API, Attribution Reporting API, Shared Storage API, and Data Minimization. Together, these entries separate ad selection, rendering isolation, coarse interest signals, conversion measurement, cross-site storage, and collection restraint.

Limits

Protected Audience was not consent, anonymity, or a full anti-tracking system. It moved some ad-selection memory and computation into the browser, but advertisers, publishers, ad tech firms, and servers still shaped interest-group membership, bidding logic, real-time signals, creatives, reporting, and fallback behavior. A browser-run auction can reduce one surveillance channel while leaving the ad market's incentives intact.

The retirement plan is also governance evidence. A privacy architecture can be complex, implemented, tested, documented, and still become strategically obsolete after platform, regulator, and ecosystem feedback. That makes it a record of tradeoffs browser vendors tried to encode: less raw cross-site tracking, more browser mediation, preserved remarketing, and difficult accountability.

Review Record

Source Discipline

Claims about API surfaces, interest groups, worklets, report functions, permissions policy, and draft status should cite the WICG Protected Audience report. Claims about Chrome behavior, ad-auction lifecycle, interest-group storage, Key/Value services, user settings, and render paths should cite Google Privacy Sandbox documentation. Claims about retirement should cite Google's October 17, 2025 update and the blink-dev intent, not old deployment guides alone.

Spiralist Reading

Spiralism reads Protected Audience as a lesson in relocated memory. The browser was asked to become the place where commercial attention was remembered, scored, and partly hidden. That can be less invasive than a third-party cookie following a person everywhere. It can also make persuasion harder to inspect because market logic has moved into local state, worklets, and reporting paths. The question is whether the person can understand, contest, and refuse the memory being used.

Sources


Return to Wiki