I can’t believe I’m having to write this code in a fucking web server. What a mockery of the web, human rights, and the GDPR.

Fuck you, Google!

Screenshot of code:

    // Opt out of Google Chrome tracking everything you do.
    // Note: if you’re reading this, stop using Google Chrome.
    // It is ridiculous for web servers to essentially have to ask
    // “please do not violate the privacy of the people who are viewing
    // this site” with every request.
    // For more info, see:, response, next) => {
      response.set('Permissions-Policy', 'interest-cohort=()')

@aral I think we've stumbled upon the second valid use-case for a man-in-the-middle server. I wonder if a Pi-Hole can be configured to do this task as well.

For more details on Google’s latest affront to humanity, see this write-up by the lovely @PlausibleHQ folks:

(Yeah, and don’t worry, I’m also calling next() at the end of that piece of middleware now.) ;)

So, ball’s in your court, web server developers.

Are you going to add a one-line header, by default, to your server responses to protect people from being tracked by Google or not?

Adding it to Site.js took 5 minutes or work:

Do you care?


@vertigo @aral Reading, it appears to me that FLoC is only supposed to take pages into account that use FLoC themselves ("By default, a page is eligible for the interest cohort computation if the interestCohort() API is used in the page."), so that header mostly serves the purpose of "if you insert third party javascript, it can't do cohort analysis on your page", to which I say, maybe don't insert third party javascript?

@vertigo @aral To expand on this a bit: FLoC is only supposed to update the cohort data when the API is used by the page (with some exceptions for a transition period "when ads are on the page", huh...)

If you dislike FLoC enough to disable it in HTTP headers, you probably won't use the API either. Which means that the only way for the header to even matter is if you include external assets that can execute Javascript on your page.

But if you do that, said Javascript (that would use the FLoC API) could implement FLoC in pure Javascript (I have a rough sketch on how this could work), so I'm not sure that header is actually helpful.

In any case, if you distrust third party Javascript you insert on your site enough that you think you need to blanket-add that header, maybe the problem is your inclusion of untrustworthy Javascript? (even without a FLoC reimplementation it could mess thing up considerably, privacy or otherwise)

(All that isn't an endorsement for FLoC, I just don't know that adding that header is very helpful. See how the DoNotTrack flag was shot down: by Internet Explorer enabling it by default.)

that was exactly my first thought. It seems like one mitm proxy per household, that fixes all of these modern atrocities is the only realistic way forward