Chrome 152 removes Private Aggregation, two milestones later than the intent said

Chrome 152 reached the stable channel on August 25, 2026. Its release notes carry a long list of additions — CSS pseudo-element support, a CPU performance tier hint, connection allowlists — and exactly one line under deprecations and removals:

Following Chrome's announcement that the current approach to third-party cookies will be maintained, the Private Aggregation API is deprecated and removed (along with related Privacy Sandbox APIs).

Chrome 152 release notes, Chrome for Developers

That sentence is the end of a four-year measurement project, and it arrived two milestones later than Chrome said it would.

The milestone that slipped

The removal was filed on the Blink developer list on November 7, 2025 by Alex Turner, as an "Intent to Deprecate and Remove: Private Aggregation API." The intent named a schedule: deprecation in M144, full removal in M150, with server-side summary report computation ending in late December 2025.

M150 came and went. The code came out in M152.

Two milestones is roughly eight weeks of Chrome release cadence — not a scandal, but worth noting for anyone who plans migrations off Chrome's stated removal milestones. The intent is a statement of direction, not a contract. Sites that took M150 literally had an extra two releases of grace they could not have relied on.

The usage numbers in the thread explain why the slip cost Chrome nothing. Private Aggregation was running on roughly 3% of page loads when the intent was filed, and 2.4% by the time the removal request was made in June 2026. That is not zero, but it is a number small enough that a two-milestone delay does not change the shape of the decision.

The rationale is a reversal, stated plainly

Chrome's own justification is unusually direct about what changed. From the intent thread: "we expect adoption of the Private Aggregation API to decrease over time as cross-site measurement will remain possible in Chrome using third-party cookies."

The API was, in the thread's framing, originally designed for a future without third-party cookies. Chrome decided not to build that future. The API has no reason to exist in the one that remains.

There is a second reason given, and it is the more durable one for a standards watcher: no other browser engine signaled interest in launching the API. Private Aggregation was only ever exposed through Shared Storage and Protected Audience — two other Chrome-only surfaces. A privacy-preserving measurement primitive that exists in one engine is not a measurement standard; it is a vendor feature with a spec attached. Chrome says removing it lets it focus on the proposed interoperable Attribution standard instead.

What the status page shows is queued behind it

The Privacy Sandbox feature status page is the document that puts Chrome 152 in proportion. Of 22 web-platform entries listed, 14 are marked either "Deprecate & Remove" or "Discontinue":

• Deprecate & Remove — Aggregation Service, Attribution Reporting, Fenced Frames, IP Protection, Partitioned Popins, Private Aggregation, Protected Audience, Related Website Sets (including requestStorageAccessFor()), Shared Storage (including Select URL), Topics.
• Discontinue — Fenced Storage Read, Private Proofs, Probabilistic Reveal Tokens, Script Blocking.

Eight entries are marked "Continue Support," and the split between the two lists is the interesting part. What survives is not the ad-tech machinery — it is the storage-boundary work: CHIPS ("Supported by default in Chrome 114 and higher"), the Storage Access API ("Supported by default from Chrome 119"), storage and network partitioning, bounce tracking mitigations, FedCM, Private State Tokens, User-Agent reduction.

That is a coherent line. The APIs designed to replace third-party cookies for advertising are being deleted. The APIs designed to partition state — which are useful whether or not third-party cookies exist, and which other engines have shipped or prototyped — are staying. The six Android Privacy Sandbox features (Attribution Reporting, On-Device Personalization, Protected App Signals, Protected Audience, SDK Runtime, Topics) are all listed as scheduled for phaseout.

What breaks, and how you would know

If you run a site, the practical exposure is narrow and indirect. Private Aggregation was never called directly from a page; it was reachable only from inside a Shared Storage worklet or a Protected Audience auction. Nothing in your own first-party code calls it. What can break is a third-party tag that does.

The failure mode matters here: this is a removal, not a deprecation warning. Code paths that called privateAggregation.contributeToHistogram() inside a worklet will throw rather than silently no-op, and because worklet exceptions do not surface in the page's console by default, the first signal for most operators will be a measurement gap in a vendor dashboard rather than a JavaScript error in their own telemetry. If a vendor reports a step change in aggregate reporting starting late August, Chrome 152 is a plausible cause worth ruling in before hunting elsewhere.

Because Shared Storage and Protected Audience are themselves marked for removal, any remediation that reaches for those two APIs is buying a short reprieve. The status page is explicit that both are going.

The honest read

Chrome shipped a removal it announced nine months earlier, at a usage level low enough that the removal was uncontroversial and the schedule slip went unremarked. The document worth bookmarking is not the Chrome 152 release note — it is the status page, which is currently the clearest public statement of which parts of Privacy Sandbox Google intends to keep. Fourteen entries say "remove." Eight say "continue." The eight are the ones other browsers also ship.

Primary sources: Chrome 152 release notes, Intent to Deprecate and Remove: Private Aggregation API (blink-dev), Privacy Sandbox feature status, Chrome Releases: Stable Channel Update for Desktop, August 25, 2026, read 2026-08-28.