In 2021 a great many sites added one line to their web server config to opt out of Google's FLoC tracking experiment:
Permissions-Policy: interest-cohort=()FLoC was abandoned. The header was not. It now names a control for a different system entirely, and nobody who deployed it was told.
What it was for
The instruction came from the FLoC explainer itself:
"For example, a site can opt out of all FLoC cohort calculation by sending the HTTP response header:
Permissions-Policy: interest-cohort=()"
It spread fast, because it was one line, cost nothing, and let a site say it had done something. It was never implemented by any browser except Chrome — Firefox and Safari never shipped FLoC, so for their users the header did nothing from the start.
What it names now
FLoC was replaced by the Topics API, and rather than retire the old token Chromium repointed it. From the browser's own feature definitions:
// "browsing-topics" permissions policy that controls the use of Topics API.
kBrowsingTopics = 97,
// "interest-cohort" permissions policy that controls the use of Topics API.
kBrowsingTopicsBackwardCompatible = 98,
⚠️ The name and syntax are the same, and the server config is untouched, but the thing it governs is a different API from the one it was added for. The internal name says it plainly: backward compatible. That is a decision to keep old deployments working, which is a courtesy, and it also means the header quietly changed subject.
Which is fortunate, because the thing it guards is going away too
Chrome's own deprecation notice states that "the browsing-topics and interest-cohort permissions policy features will be removed", and the API's main entry point now rejects calls outright with a message saying it has been removed.
A site that deployed the line in 2021 has seen it guard FLoC, which was cancelled, then get repointed at Topics, which was not what anyone opted out of, and now Topics itself is being withdrawn, taking the token with it. At no point did the config file change.
How many sites are still sending it
We checked fifteen well-known sites. Six send a Permissions-Policy header at all. Of those six, four include interest-cohort — and for every one of the four it is the entire header:
| Site | Permissions-Policy |
|---|---|
| gov.uk | interest-cohort=() |
| php.net | interest-cohort=() |
| ubuntu.com | interest-cohort=() |
| duckduckgo.com | interest-cohort=() |
These are not careless operations. They are a government service, two major open-source projects and a company whose entire proposition is privacy. This is the point. The header is the kind of thing a careful team adds once, correctly, and never revisits. Nothing ever prompts them to.
What this does not mean
It does not mean these sites are tracking anyone, or that the header is harmful. Sending it costs a few bytes and, while the alias exists, it does still disable the Topics API in Chrome. Nobody is worse off for having it.
It does not mean Chromium did something underhand either. Keeping an old token working is the considerate choice; the alternative was to break every deployment that had followed the official advice. Both the mapping and the removal plan are published in the open.
The point is narrower and worth sitting with. A security or privacy control can change what it governs without a single byte of your configuration changing, and your deployment pipeline will not notice. The line still parses. The linter is happy. The audit sees a privacy header. The subject changed underneath all three.
What to do about it
If you send it, decide deliberately rather than by inheritance. The honest options are to send browsing-topics=() — the current name, which will outlive the alias — or to send both while the alias lasts, or to accept that the API it guards is being withdrawn and drop the line at the next config change.
⚠️ What is not defensible is treating this header's presence as evidence of a current privacy choice. It documents a decision about a system that no longer exists.
More generally, if a header, a policy name or a feature token appears in your configuration and you cannot say what it currently governs, look it up rather than assuming it still means what it meant when it was added. We check our own headers the same way — reading the live response, not the template that is supposed to produce it.
Where this comes from, and what will date it
The original instruction is quoted from the FLoC explainer as still published. The feature mapping is quoted from Chromium's own permissions-policy feature definitions, fetched here and searched directly, with "permissions policy" appearing nine times as a positive control so the single interest-cohort hit is a real match rather than a failed download.
The header census is ours: fifteen sites queried live, six carrying a Permissions-Policy header, four of those carrying interest-cohort as their whole policy.
⚠️ Three limits. Fifteen sites is an illustration, not a survey — it supports "this is still widespread among careful operators" and not any percentage of the web. Header responses vary by user agent and region, so another observer may see a different set. And the removal timing and the thrown error are as Chrome has announced and shipped them; we have quoted the deprecation intent and the feature mapping, which are the durable parts, rather than pinning a release date we did not verify ourselves.
This dates when the alias is removed, at which point the header becomes inert rather than misdirected, and the config lines will still be there. That is the part of the story worth remembering. The line in the config file has outlived every system it was ever meant to control.
View author profile → · Editorial policy
