FLoC network opt-out

Google has invented a technology called FLoC that uses the Chrome browser to profile users, because third party cookies seem to be going away.

This technology is heavily frowned upon and a website or application can send a Permissions-Policy: interest-cohort=() header to opt out of this.

We think that advertising is an important cornerstone of the web in 2021 but of course there are a lot of communities that see this as a large privacy issue.

The fastest way to opt your Discourse installation out of this is to add a meta tag in the /head of a theme component: EDIT as @supermathie pointed out, not sure if this will work.

<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>

But maybe this could be a ‘real’ HTTP header controlled by a checkbox in core.


Thanks - I agree, this should be a standard choice.

You can check your headers here, and this site presently doesn’t send an opt-out:


I have only seen people saying this will not work, I believe this has to be an actual header.


Opt-out from both the website and user side is not a feasible scheme for introducing new web platform features.

In particular, the header needs to be sent on every request, and you need to also account for every unique CDN URL that would be equivalent to a visit to your primary forum domain.

cdn.forum.example.com has exactly as much predictive power as forum.example.com does.

Any changes at this point are essentially randomly motivated. Google forcing the entire web to scramble with little opportunity for research into the mechanism or visibility into changes in policy is not conducive to rational decisions.


Very true. I couldn’t agree more.

And yet…

Are we supposed to just sit by and do nothing while Google does that? Because Google is doing that, whether we like it or not. Whether it’s good or not.

FLoC Discussion in the Wordpress project (which unfortunately seems to revolve more around “how” instead of “if”).

Thanks, I did some searching: relevant discussion here and important argument (emphasis mine)

I’d rather we not do this. This leads to all kinds of race conditions and you’ll also get features you can only disable at the HTTP level. I’d rather not repeat the mess this created with CSP. Let’s just encourage all hosting providers to give adequate header configuration options.

While FLoC is awful, it does not seem like the suggestion on Wordpress is perfect either because lots of things modify headers, how do you account for all of that?

The only reliable solution at the moment is to use any browser other than Chrome. Using directives to ask Google not to crawl or track has a history of not always being respected even when it’s done the way Google says we should do it.


So, in the land of Wordpress, a webmaster has to deal with their hosting provider for their headers. (Edit: oops, see below for correction.)

But here in the land of Discourse, we have a docker image which configures everything about our site’s web presence, including headers.

I know only enough to be dangerous, but I see header settings in
so it feels to me within scope for Discourse to set appropriate headers, according to the webmaster policy.

Some Discourse admins might not care to do anything, some might want to wait and see, and others might like to opt-out of FLoC tracking on behalf of their communities and as a signal to Google.

I’d like to opt-out.

1 Like

I am testing a change based on How to add a custom HTTP header to your Discourse [^1] to add this header, I’ll let you know once I have verification it works.

Personally, I’m a fan of the suggestion someone made to outright reject requests that have the FLOC header sent, breaking Chrome. But I can’t find the article I read advocating that… :smiley:

[^1]: GNU Terry Pratchett, speak his name


No - that quote was from a generic discussion about the Permissions-Policy header. In the land of Wordpress, there is a plugin that adds the header.

1 Like

Thanks - I stand corrected.

This should do you:

## Any custom commands to run after building
  - exec: echo "Beginning of custom commands"
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /location \/ {/
     to: |
       location / {
           add_header X-Clacks-Overhead "GNU Terry Pratchett";
           add_header Permissions-Policy "interest-cohort=()";

adapted from How to add a custom HTTP header to your Discourse
aside: how very topical for today: Terry Pratchett’s debut turns 50: ‘At 17 he showed promise of a brilliant mind’ | Books | The Guardian

result is:

○ → curl -I https://testmachine/srv/status
HTTP/2 200 
server: nginx
date: Tue, 20 Apr 2021 17:48:15 GMT
content-type: text/plain; charset=utf-8
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
x-request-id: ef02ce7c-fabc-49b9-986e-c2c46e50f8e4
x-runtime: 0.004575
x-redis-calls: 1
x-redis-time: 0.000153
x-queue-time: 0.000952
x-clacks-overhead: GNU Terry Pratchett
permissions-policy: interest-cohort=()

Update from lobste.rs: Once the beta is done, there is no opt out for having your site included in the calculations.

All sites with publicly routable IP addresses that the user visits when not in incognito mode will be included in the POC cohort calculation.

This “opt out” will cease functioning as soon as the trial phase is complete, and currently it only functions if you’re serving advertisements.


In other words, let’s quit wasting time thinking about this.

You can opt out as an individual (for now).

From Chrome 90 (Stable release on Tuesday, 13 April) users can opt out of FLoC and other Privacy Sandbox proposals via chrome://settings/privacySandbox. (You can try this out now in Canary with the floc.glitch.me demo.)

From: [Proposal] Federated Learning of Cohorts (FLoC) - #26 by Sam_Dutton - APIs - WICG


This took me some time to understand as well, and I think I do understand now (but please correct me where I am wrong). The confusion is about “the calculations”.

There are two kinds of calculations here, and there are three ways for a site to “participate” in FLoC.

  1. The “global” algorithm that determines the (global) cohorts. Opt-out impossible. Indeed All sites with publicly routable IP addresses that the user visits when not in incognito mode will be included in the POC cohort calculation.

  2. The algorithm that determines the cohort for a specific user, based on their browsing habits. Opt-out based on header. A site should be able to declare that it does not want to be included in the user’s list of sites for cohort calculation. This can be accomplished via a new interest-cohort permissions policy. (taken from the same document as your quote)

  1. A site requesting the user specific cohort in order to get a targeted advertisement (or to misuse that information) using Javascript. The value is made available to websites via a new JavaScript API:
    cohort = await document.interestCohort();
    That API does not work on pages that opted out using the header in #2 and this is where a lot of confusion came from. Any frame that is not allowed interest-cohort permission will have a default value returned when they call document.interestCohort().

I cannot find a good source for this.


Ah - I was conflating #2 and #3 in your list there.

In which case, there is value in the header, though again headers are a bad and error-prone method of delivering this.