Intent to Deprecate and Remove: Protected Audience

Intent to Deprecate and Remove: Protected Audience

Contact emails

paulj...@chromium.org

Explainer

https://github.com/WICG/turtledove/blob/main/FLEDGE.md

Specification

https://wicg.github.io/turtledove/

Summary

The Protected Audience API provides a method of interest-group advertising without third-party cookies or user tracking across sites.

Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Protected Audience API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page).

Blink component

Blink>InterestGroups

Web Feature ID

None

Motivation

Chrome has announced that the current approach to third-party cookies will be maintained. Since that announcement there has been virtually no interest in the Protected Audience API. Use of the joinAdInterestGroup() API has decreased by almost 100x and use of the runAdAuction() API has decreased by more than 10x. Of the auctions occurring today, virtually none of them have winners (determined by looking at the “Success” bucket count of the Ads.InterestGroup.Auction.Result UMA), implying that they are not providing useful benefit to the pages initiating them.

Initial public proposal

https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/.

Developer-facing impact

Given that virtually none of the Protected Audience auctions occurring today have winners, we estimate the lost utility from this removal to be negligible.

User-facing risks

The user-facing risks are small. While removing the JavaScript API could cause pages to break, the impact should be limited to sites that don't employ standard defensive coding or feature detection, which should be rare since not all browsers implement the API.

If usage warrants, we will take steps to avoid any risk of page breakage, e.g. by temporarily retaining a stub implementation of Navigator APIs joinAdInterestGroup(), runAdAuction(), leaveAdInterestGroup(), clearOriginJoinedAdInterestGroups(), getInterestGroupAdAuctionData(),  canLoadAdAuctionFencedFrame(), createAuctionNonce(), updateAdInterestGroups(),  protectedAudience.queryFeatureSupport(), deprecatedReplaceInURN(), deprecatedURNtoURL(),  and adAuctionComponents() that mimic current behavior when a user has disabled Protected Audience.

Estimated milestones

Planning to deprecate in M144 and remove in M150.

Currently 0.22% of page loads use the Protected Audience API. These are driven by a small number of third-party ad tech scripts present on a large number of sites. We will continue to monitor usage as well as provide comprehensive updates on privacysandbox.google.com with the status of the API and deprecation plans.

We will also proactively work toward reducing usage to low levels once this intent is approved, including disallowing any new enrollment sign-ups, and contacting enrolled sites to inform them about the deprecation timelines.

Protected Audience features that were never launched beyond 20% Stable (TextEncoder support, Creative scanning via BYOS/V1 trusted scoring signals, Selectable Reporting IDs) will be ramped down by the end of 2025.

Protected Audience services, Bidding and Auction services and Trusted Key Value service, will not onboard new clients once deprecation is approved. We will work with onboarded clients and plan to turn down the services by the end of year as usage is negligible today. This will have no user-facing or web-compat impact.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6552486106234880

Hi API Owners,

Protected Audience API was deprecated in Chrome-144 with a plan to remove it in Chrome-150. Currently the usage is 1.1% of page loads.

We are proposing the following as next steps for removal and associated timelines:

1. M150: Remove all Ads API-related entries from Chrome settings and UI surfaces (e.g., chrome://settings/adPrivacy) via field trial. After this point, all API invocations for field-trial enabled browsers will always reject. Since the API can already be disabled for one of many reasons, scripts must already handle such rejections (or they’re already significantly broken).
2. M152: Permanently remove the underlying implementation code for the API, and replace it with a lightweight stub API. The stub will remain removable via field trial. 

3. M152 Canary/Beta: Begin a controlled rollout of the stub API removal via a field trial.
4. M152 Stable: Assuming there are no regressions or breakage after reaching 1% stable, we will request additional approval for full removal at this stage. 

At this time, we are seeking LGTMs for steps #2 and #3.

Thanks,

Paul