Errata for The Private Citizen 66
Clearing up a misunderstanding about Google’s FLoC from a webmaster’s perspective, that I was operating under while recording the latest Private Citizen episode.
Yesterday, I released an episode of The Private Citizen on Google’s new advertising technology Federated Learning of Cohorts (FLoC):
→ The Private Citizen 66: FLoC of Sheep
In that episode, I said that webmasters need to add a server response header to their sites if they don’t want their visitors to be opted into FLoC-based profiling. It seems this is somewhat wrong. I will, naturally, correct this on the next episode, but I wanted to post some errata here as well.
Thanks to Евгений Кузнецов (Evgeny Kuznetsov) for pointing me to this correction:
→ Misinformation about Permissions Policy and FLoC
A lot of misleading online discussion stems from one not-very-misleading blog post that’s been making rounds, instructing webmasters everywhere to add the following HTTP response headers to all their pages:
Permissions-Policy: interest-cohort=()Strictly speaking, this advice is correct; including this header will prevent your page form using Google’s FLoC. What the advice misses is that the header isn’t always necessary and isn’t even the ideal way to prevent your page from doing nefarious things.
If your website does not include JS that calls
document.interestCohort(), it will not leverage Google’s FLoC. Explicitly opting out will not change this.What adding this header does is exclude your website from being used when calcualting a user’s cohort. A cohort is an identifier shared with a few thousand other users, calculated locally from browsing history; sites that send this header will be excluded from this calculation. The EFF estimates that a cohort ID can add up to 8 bits of of entropy to a user’s fingerprint.
Being excluded from cohort calculation has a chance to place a user in a different cohort, altering a user’s fingerprint. This new fingerprint may or may not have more entropy than the one derived without being excluded.
Given this marginal improvement, I don’t think it’s right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn’t expect webmasters to add a tag or header every time Google advances the war against its own users.
With other words, if your site does not include Javascript to facilitate Google Ads tracking, it will not interact with FLoC at all. What that header does, is preventing the user’s browser from using your site in the cohort calculation (which happens locally in the user’s browser). But that actually doesn’t seem to be that bad for the user. And, as this blog post points out indirectly, it shouldn’t be the responsibility of the server administrator to decide this for the user.
Bottom line: If, as an admin, you don’t want your users to be tracked or profiled by Google, don’t use Google Ads. And if, as a user, you want Google to track and profile you less, stop using Google Chrome.
Got a comment?