Life after third-party cookies: Topics API, FedCM, and tracking in 2026
The death of the third-party cookie was sold as a privacy win. What actually happened is that tracking moved from a leaky old mechanism the browser merely tolerated into a set of new APIs the browser actively runs on the advertiser's behalf. This article explains the four pillars of the post-cookie web as they stand in 2026, Topics API, FedCM, CHIPS and Attribution Reporting, exactly what information each one exposes and withholds, the criticisms that matter, and a clear list of what to disable.
What "deprecation" really meant
By 2026 third-party cookies are blocked by default in Safari (since 2020) and Firefox's Total Cookie Protection, and in Chromium they are either off or partitioned depending on configuration and region. But the browser that ships to most of the world is built by an advertising company, and removing cross-site cookies without a replacement would have broken ad measurement and federated login. So Google's Privacy Sandbox introduced purpose-built APIs to cover the same use cases with, in theory, weaker tracking. Whether they are actually private is the whole debate.
Topics API: interest tracking, moved in-browser
The Topics API replaces third-party cookies for interest-based advertising. Instead of an ad network watching every site you visit, your own browser watches your browsing, classifies the sites you visit into topics from a public taxonomy of a few hundred categories (such as "Travel" or "Fitness"), and stores them locally per week.
How it works
Each week the browser computes your top topics from the sites you visited that called the API. When you land on a participating site, that site can call document.browsingTopics() and receive up to three topics, one from each of the previous three weeks. To limit precision, the browser returns a topic a given caller would have observed anyway, and 5% of the time it returns a random topic as noise so a single observation is deniable.
What it does and does not leak
It does not reveal your full history or a stable per-user identifier; it reveals coarse interest labels. The criticisms are real, though. A caller that sees you across many weeks accumulates topics that, combined with an IP address or a fingerprint, narrows you down. Sensitive inferences can leak through proxy topics. And because the browser is doing the labelling, the user is now an active participant in being profiled. Mozilla and Apple both declined to implement Topics, calling it a tracking feature rather than a privacy one.
FedCM: federated login without the login cookie
"Sign in with Google/Facebook/etc." historically relied on third-party cookies and top-level redirects, which also leaked to the identity provider exactly which sites you logged into. The Federated Credential Management API (FedCM) replaces that flow with a browser-mediated one.
How it works
Instead of the site embedding the identity provider's cookie-bearing iframe, the site calls navigator.credentials.get() with a FedCM configuration. The browser itself contacts the identity provider, fetches the list of available accounts, renders a native account chooser the site cannot script or read, and only after you click does it pass a token to the site. The identity provider no longer needs a third-party cookie to make this work.
What it does and does not leak
FedCM removes the unrestricted third-party cookie from login, and the account-chooser UI is controlled by the browser, not the site. But the identity provider still learns which relying party you are signing into, because it has to mint the token for that site. FedCM narrows the tracking surface, it does not eliminate the provider's view of your login graph. It is a genuine improvement over the cookie-based flow, but it is not anonymity.
CHIPS: partitioned cookies that cannot follow you
CHIPS (Cookies Having Independent Partitioned State) keeps third-party cookies working for legitimate embedded use cases, such as a support-chat widget or an embedded map, without enabling cross-site tracking.
How it works
A cookie set with the Partitioned attribute is stored in a jar keyed by the top-level site you are visiting. A chat widget embedded on shopA.example and on shopB.example gets two entirely separate cookies; the widget cannot use one cookie to recognise you across both sites. The cookie still functions for its single-site purpose but loses its cross-site memory.
What it does and does not leak
CHIPS is the most straightforwardly positive of the four. A partitioned cookie cannot build a cross-site profile by design. The only caveat is that it relies on developers actually adding the Partitioned attribute, and on the browser enforcing partitioning, which is exactly the kind of thing a privacy test should verify rather than assume.
Attribution Reporting: measuring conversions without identifiers
Advertisers want to know that an ad led to a purchase. They used to do this by matching cookies across the ad impression and the conversion. The Attribution Reporting API replaces that with browser-generated reports.
How it works
The browser records ad clicks/views (sources) and conversions (triggers) locally, then later sends aggregated or heavily delayed, noised reports. Event-level reports tie a click to a coarse conversion value with limited bits and random delay; aggregate reports go through a privacy budget and added noise so individual users are not distinguishable. No cross-site identifier is shared in the process.
What it does and does not leak
By design it avoids a per-user join key, and the noise plus delay limit re-identification. The criticism is that the noise and bit limits are tunable and that combining attribution data with other signals (IP, fingerprint) can erode the guarantees, so the privacy depends on the parameters and on the browser's honest enforcement.
The common thread, and the catch
All four APIs share a design philosophy: move the sensitive computation into the browser, return only coarse or noised outputs, and avoid a shared cross-site identifier. That is a real structural improvement over third-party cookies. The catch is threefold. First, these APIs run by default in the dominant browser, so most users are opted in to a new tracking mechanism without noticing. Second, they coexist with fingerprinting, which gives advertisers a stable identifier the Sandbox never addressed, and combining a fingerprint with Topics or attribution data undoes much of the protection. Third, two major browser vendors refused to ship Topics at all, so the "standard" is contested.
What a privacy-conscious user should disable
- Turn off the Privacy Sandbox / Ad privacy settings. In Chromium, open Settings, find Ad privacy, and disable Ad topics, Site-suggested ads (Protected Audience), and Ad measurement. This stops your browser from computing and sharing Topics and from generating attribution reports.
- Block third-party cookies entirely rather than relying on partitioning, if you do not need any embedded cross-site functionality. This is the default in Firefox and Safari.
- Use a browser that never implemented Topics if interest tracking is your main concern: Firefox, Safari, and the Chromium forks (Brave, others) that strip the Sandbox APIs do not run Topics.
- Treat FedCM as convenience, not privacy. If you do not want an identity provider to know which sites you join, use email-based or passkey login per site instead of federated sign-in.
- Address fingerprinting separately, because none of the Sandbox controls touch it. This is where a browser-level test earns its keep.
How privacyscore.dev reflects 2026 tracking
Because the tracking surface has shifted, a useful privacy test can no longer just count cookies. Our checks on privacyscore.dev probe whether the Topics API responds in your browser, whether attribution and Protected Audience interfaces are exposed, and whether third-party cookies are blocked or merely partitioned, then weigh that alongside your fingerprint entropy. A browser can show zero third-party cookies and still hand back a Topics value and a high-entropy fingerprint, which is exactly the false sense of safety the post-cookie era creates. Seeing both halves in one score is the point.
Conclusion
Third-party cookies are leaving, but tracking did not. It was re-engineered into APIs that are more private in the narrow sense, no shared identifier, coarse outputs, that still run by default and still coexist with the unsolved problem of fingerprinting. The practical response in 2026 is to disable the Privacy Sandbox features you did not ask for, block third-party cookies outright, treat federated login as a tracking decision, and measure your fingerprint separately. Understanding what each API genuinely protects, and what it quietly does not, is the difference between a real privacy posture and a comforting label.