Google is rolling out an early-stage experiment with a new behavioural targeting technology: Federated Learning of Chorts (FLoC). As privacy activists globally campaign against this highly problematic “cookie replacement”, the suggestion by some to even add opt-out headers to all CMS by default might do more harm than good.
Google claims to have found a possible solution (actually it’s just one of many ongoing explorations into this sphere) to replace third-party cookies with a supposedly more “privacy-friendly” alternative, but — while indeed eliminating the pseudonymized tracking of individuals — creates new problems and does nothing to solve the systemic problems with behavioural targeting. This is not really surprising: Google has very high stakes in the surveillance business model.
The EFF and others have started to campaign broadly against this, not least as their trial is run on some Chrome users without asking for consent. (Though, despite EU users currently not included, I wonder whether Google’s move to assign cohort rather than individual IDs might actually tilt the GDPR privacy impact assignment towards using “legitimate interest” rather than “consent” for such a feature — this will likely have to be tried in court if it ever gets rolled out commercially.)
How to not be included
Quite obviously the best and only truly efficient measure for individuals to protect themselves is to either use an alternative browser (“good friends don’t let their friends use Chrome”) or through reviewing the Chrome browser settings: logging out from their Google account, disabling third party cookies, using incognito mode or adjusting their Google ad settings all are remedies against being “FLoCed”.
As part of the trial, Google announced an option for website owners to have their site excluded by sending a Permissions-policy: interest-cohort=() header. Some blogs picked up on this and advocate for people to add this header to their sites — either as a signal of protest or to actually protect their users, though the latter only applies to sites that have already questionable scripts embedded (as otherwise they would not even be subject to the FLoC cohort calculation). For instance, sending the interest-cohort=() header for a website using Google Analytics and embedded YouTube videos is merely privacy-washing, not user protection.
Why this header should not be on by default in a CMS
So far this is all more or less common sense. The problematic part are increasing voices demanding CMS and framework authors to include such header automatically.
By sending out this header by default from a CMS, its maintainers take away the possibility from individual site owners to express their discontent with the FLoC trial, as they can no longer explicitly declare “I object”. CMS authors would essentially incapacitate site owners from making this decision themselves by objecting FLoC wholesale on behalf of all their customers (potentially without their consent, which is kind of ironic).
At the same time, by sending it out in bulk as a pre-set default, the header is rendered meaningless at scale. Once half the web or more return it as a de-facto “standard header” to every request, it may easily be dismissed as “not a meaningful expression of a site-owners intent”; it is evidently no more than an unreflected default for most (we’ve seen this argument with “Do Not Track” in the past). And what started as a broad-scale protest actually damages those few site owners who would actually really need this opt-out.
So we are actually looking at two aspects here:
- the advocacy part where sending this header is intended as a signal to Google “We don’t approve”, and
- the aspect of protecting website users.
For both, having the CMS set the header by default is problematic.
CMS maintainers can’t advocate on behalf of all their users
It is of course fine for CMS maintainers to include this header on their own website to express their discontent and use this act in their marketing to create visibility for the issue and their product. It is also a good idea to provide simple means or some form of documentation how site owners may turn it on for their instance. Sharing such information, e.g. with references to the EFF’s brilliant amifloced.org tool, can also greatly contribute to create awareness and fuel the protest.
The decision to turn it on for an individual website should however stay with website owners, as they otherwise have no way to signal their disapproval for the FLoC trial through activating this header. If the header is indeed seen as a means of protest, this is not unlike signing a petition: somebody else may not sign a petition on my behalf, just because they think I should (and don’t get me wrong, I very much believe FLoC needs to be protested against; I however remain sceptical whether a HTTP header is the right tool for that job).
This header is a last resort for protecting website users
In terms of using it to “ensure the privacy of your website users”, sending this header should be the very last resort. Rohan Kumar thoroughly elaborates on this in detail on the Seirdy blog.
As a matter of fact, promoting “we turned this on by default to protect your users” might even mislead people to believe the CMS is taking care of privacy on their site. And, just to point out the insufficiency of this argumentation: how many CMS send default Referrer-policy: noreferrer headers to protect website users from referrer tracking? (Not that I am saying they should, as this too is at the discretion of every site owner and not even always practical, but wouldn’t this be the logical consequence of adding the Permissions-policy: interest-cohort=() header if it were genuinely for end user protection?).
When looking at the available documentation, site owners have very straightforward means to not have their website participate in the FLoC cohort calculation, without even touching HTTP headers:
- not embedding third-party JS code that might call the cohort API (probably safe to assume anything even remotely related to ads and/or Google’s own services)
- not calling the cohort API (
document.interestCohort()) in their own scripts
If a site owner truly needs this header to protect users from FLoC at this point, their inclusion in this limited-scale trial with currently minimal (if any) true consequences is likely the smallest privcy concern on that website. And still, the site owner should at that point have the authority to do so.
What to do?
From my point of view, this is what CMS maintainers should do:
- add the header to your product’s own website if you consider it a reasonable form of protest (or, if for some reason you are using scripts that trigger the cohort API)
- ensure that site owners know how to activate this header if desired
- if applicable, include according options in the product or its documentation
- do not activate the header by default, to maintain the site owner’s authority over their headers
- inform users broadly about the issue, your position and promote organisations like the EFF who have the lobby power to actually fight against this
For website owners, the list looks similiar:
- activate this header if you consider it a reasonable form of protest
- remove all third-party scripts that may trigger the cohort API
- ensure your own scripts do not call
document.interestCohort() - if calling the API cannot be avoided, consider activating the header and hope that Google actually respects it and excludes your users (and do a thorough privacy review of your stack asap)
Last but not least, for end users:
- deactivate third-party cookies (not just in Chrome, this is generally good practice)
- switch from Chrome to a privacy-friendly browser alternative
- ensure all your friends and family do the same
