Privacy Sandbox Is Winding Down in Chrome. Time to Clean Up Your Wrapper

For several years, publishers were told to prepare for a Chrome without third-party cookies, and many did: they turned on Protected Audience testing, added Topics support to their wrappers and updated permissions headers. That future is now officially cancelled, and the code written for it is becoming dead weight. With Chrome 150 reaching the stable channel at the end of June, it is a good moment to clean house.

What Google decided

In April 2025, Google said it would keep its existing approach to third-party cookie choice in Chrome and would not roll out a new standalone cookie prompt. On October 17, 2025, it went further. In an update on the Privacy Sandbox, Google said it would retire the Attribution Reporting API, IP Protection, On-Device Personalization, Private Aggregation, Shared Storage, Protected Audience, Protected App Signals, Related Website Sets, SelectURL, SDK Runtime and Topics. It said it would continue work on CHIPS, FedCM and Private State Tokens, and on an interoperable attribution standard.

In short: third-party cookies stay in Chrome, and the replacement APIs built to succeed them are going away.

The Chrome timeline

Retirement follows Chrome's normal deprecation process. The intent to deprecate and remove Protected Audience, posted in November 2025, planned deprecation in Chrome 144 and removal in Chrome 150. A June 2026 update to that thread refined the plan: in Chrome 150, the API's settings entries are removed and invocations are rejected via a field trial, and the implementation code is slated to be replaced with a lightweight stub starting in Chrome 152, with the rollout monitored for regressions. Topics followed a similar deprecate-in-144, remove-in-150 plan.

The practical effect for publishers is simple. If your pages still call these APIs, those calls increasingly do nothing useful.

Why the leftovers matter

Plenty of ad stacks still carry configuration from the 2024 testing period. Leftover code is not harmless:

• It costs bytes and CPU. Modules and config that no longer do anything still load and execute on every page view, competing with content and with the auction itself.
• It confuses reporting. Test line items, custom dimensions and dashboards built for on-device auctions invite questions nobody needs to answer anymore.
• It hides real changes. The more dead configuration a wrapper carries, the harder it is to spot what actually changed when revenue moves.

A cleanup checklist

• Prebid build. Review the modules in your Prebid.js build. Remove the Protected Audience (PAAPI) related modules and the Topics first-party-data module if you added them, then rebuild and retest.
• GPT configuration. Remove any component-auction or PAAPI settings passed to Google Publisher Tag.
• Permissions-Policy headers and iframe attributes. If you added directives such as join-ad-interest-group, run-ad-auction or browsing-topics, remove them rather than leaving policy for features that no longer exist.
• Ad server. Archive test line items, key-values and saved reports created for Sandbox experiments.
• Demand partners. Ask your SSPs whether their adapters or scripts still attempt interest-group joins or Topics calls on your pages, and whether they plan to remove that code.
• Consent and disclosures. Check that your CMP and privacy policy no longer describe Topics or on-device ad auctions as active processing.

Make one change at a time and measure it. Removing code should never move revenue; if it does, that is a signal something else was wired to it.

If you also run apps

The retirement list is not limited to the web. Protected App Signals, On-Device Personalization and SDK Runtime were Android-side pieces of the same program, and they are on the same list. App publishers who experimented with them through a mediation platform or an SSP SDK should ask those partners for their removal plans and SDK versions, and schedule the update with the next regular app release rather than as an emergency change. As on the web, the durable levers in app are the ones you control: accurate app-ads.txt files, complete and truthful app metadata in bid requests, and consent signals that reach every demand partner.

Questions worth asking your partners

• Which of your scripts or SDKs still reference retired Privacy Sandbox APIs, and when will that code be removed?
• Did any of your reporting or optimization depend on Sandbox signals, and what replaces it?
• Which identity or contextual signals do you actually use when pricing our impressions today?

What does not change

Chrome's decision does not solve addressability. Safari and Firefox already restrict third-party cookies, and Chrome users can still choose to block them. The gap between cookie-rich and cookie-poor traffic remains, and it now has no browser-provided bridge.

The work that pays off is the same work that paid off before the Sandbox detour:

• First-party relationships. Logins, newsletters and subscriptions create durable, consented audiences.
• Contextual signals. Clean page categorization and content metadata in the bid request help buyers price impressions without user-level data.
• Accurate consent strings. Buyers discount or ignore requests with missing or malformed consent signals.
• Evidence-based identity choices. Evaluate ID modules on measured lift in your own A/B tests, and remove the ones that do not earn their page weight.

Measure the cleanup

Before you start, capture baseline numbers: total ad-related JavaScript weight, wrapper execution time, time to first bid request and auction duration. Capture them again after cleanup. Leaner wrappers tend to start auctions sooner, and on mobile that often matters more than any single demand partner.

The Sandbox era asked publishers to build for a future that did not arrive. The sensible response is not regret, just housekeeping: remove what no longer runs, keep what earns its place, and put the saved time into first-party data and a faster page. If you want a second set of eyes on your wrapper build, the HBDR ad ops team reviews these configurations every day.