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!

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?


@aral how do we convince antifa that google hq is alt right so they burn it down :blobcatidea:

@aral how long until a modification breaks this? giving it a month.

I wonder if there's a way to get nginx to send it for every website it serves, w/o editing each config?
I'm sure they'll break this in time anyhow.
@nergal @aral

@gemlog @nergal @aral

It might be something like:

add_header Permissions-Policy interest-cohort=();

I haven't checked yet, but tonight will ben Nginx time.

@gemlog @nergal Don’t know. Will boost for you. I’ve been much happier since I’ve replaced all my nginx installs with Site.js ;)

@aral @nergal
Well, it's a question for apache and any server really, but they'll be all different.
I don't have that many sites and I could hand-bomb each config, I just imagine chrome will subtly change how they deal with the header or 'enhance' it with options that break my edits and it will need to be done all over again. Seems guaranteed really.

@gemlog @nergal @aral In an http, server, or location block, put add_header Permissions-Policy 'interest-cohort=()';

Yes, claro, but I want to put it in a single place and have all websites use it, not just the one I edit.
@nergal @aral

@gemlog @nergal @aral Yup, in that case you’d put it in your http block.

Yes, but my sites-enabled has a dozen config files on a couple of different servers. It's ok, thanks.
@nergal @aral

@gemlog @nergal @aral Assuming you’ve got the fairly standard nginx config file layout, you should have /etc/nginx/nginx.conf looking something like

http { ... include /etc/nginx/sites-enabled/*.conf; }

That’s where you’d want to put it.

Ah, *that* file. thanks! I was trying to avoid editing all the things in sites-enabled :-) I forgot about that file as I've never touched it before. Thanks bud.


I've just made this change across all my self-hosted websites! Google Chrome *should* now be ignoring them for it's FLoC.

@mr64bit @nergal @aral @gemlog

@gemlog @nergal @aral I have one set of headers sent every time with every HTTPS request on all my virtual hosts. I added the header in that config file.

Yes, I restarted nginx/php7 and checked a random site and voila! :-)

@nergal @aral

@nergal They might. But not without (yet again) revealing their true face.

@aral Added

set beresp.http.Permissions-Policy = "interest-cohort=()";

to all my varnish configs.

@aral I bet this is going to end the same way it ended with the DNT header. Anyone remember this argument?
"Since it's the default browser / webserver setting, we do not actually know the users choice, so we chose to believe that the user actually wants to have personalized ads and the pescy devs are preventing them from having it. So we choose to ignore the opt-out setting and track you anyways 🤷 "

@aral Thanks for these links and for the tips 👍

This single line in my Nginx server did the trick:

add_header Permissions-Policy "interest-cohort=()";

@aral I'll look into this! I've recently stripped all js off my website, but I'm happy to add this bit in if it'll stop tracking.

@aral I don't suppose you'd know if adding these header policies to HTML meta tags would work? I have a few websites that use GitHub and GitLab (.com) Pages, and I don't think I can alter the headers coming from the server.

I've at least updated all my other websites with this! Thanks again for the heads-up!

@Alamantus AFAIK, no. (For one thing, Google isn’t trying to make it easier for you, they’re just trying to cover their asses with regulators – “oh, it’s opt out so people have a CHOICE… so it’s ok”

@Alamantus But you can lobby GitHub and GitLab to add them by default to every request.

@aral ~~nitpick but shouldn't you index all that stuff based on some variable and subtraction instead of having to change all of them each time~~

@monarrk I’m ok with not over-engineering the tests at the moment. It’s very rare to change the middleware stack at this stage as Site.js is rather mature. If it becomes a pain at some point, I’ll refactor it, sure.

@aral I really dont think this is the right way to go. Google cant add a privacy violating feature and point at another party (server admins in this case) to fix their violation. That is all on Google, and they cant escape their responsibility by adding a complicated off switch which isnt compliant with the spec for that header. If you want the tracking active in your site, then simply make sure that you dont load any advertising.

@felix I agree but I also don’t see the link between not loading advertising and Google not profiling people on your site. If anything it’s ambiguous as they state in their original proposal that visits to every site are included in a person’s profile. And, knowing their business model, that’s the direction this will go even if it’s not there now (slowly boiling frogs). Agree it’s entirely ridiculous and should be illegal but who’s going to regulate them? The institutionally-corrupt regulators?

@aral Noob question: Isn't adding this just sort of a request to google not to do shady stuff? Aren't they free to ignore such requests?

@aral Looks like this would be

add_header Permissions-Policy "interest-cohort=()"

for Nginx, or to possibly override any Permissions-Policy already present with the headers-more module

more_set_headers "Permissions-Policy: interest-cohort=()"

the latter which I added to my own Nginx config.

@aral Having to opt out this way feels a bit insidious: Permissions-Policy was used to be named Feature-Policy and had a different syntax. So maybe also adding

Feature-Policy: interest-cohort 'none'

would also be a good idea (although hopefully no browser that supports Feature-Policy but not Permissions-Policy does any FLoC). Also, Permissions-Policy is used to opt out of a lot of other browser features, such as geolocation and payments. Opting out of these if you aren’t using the is probably a good idea, for the very least, to limit the impact of any potential XSS vulnerability. So an application that opts out of, say, camera access on every page except a videochat feature now must remember to opt out of FLoC everywhere, even on pages with a lenient Permissions-Policy.

This is a (cynically, I’d say deliberate) mixing of responsibilities: while other permissions are about what code from the website can do, interest-cohort is about what advertisers can do.

@aral thanks I didn't even think about how my sites would be coopted by Google with this. (don't forget that next() call, though).

Even though it's this simple, have you thought about publishing this as an npm package?

@datatitian Thanks (added it right after posting the screenshot) ;)

I’ll see if there is one already and sure, if not.

@aral as far as i understand, the plan is for this abomination to be opt-in per site after the current trial run, though i couldn't find exact details so far

the current trial would only include your website if you use the API yourself or Chrome detects ads, but i'm unsure how this all works, so for now, setting the header indeed seems like the safest way to make sure your website never gets included in the cohorts computations

@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.

@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

@aral just out of spite my server also sends out the header "Google-Sucks: Always" with every response

@aral this is probably just going to be another do-not-track situation, right? If enough sites do this, they'll just ignore the setting and FLoC you anyway.

@aral might I also suggest adding to nginx configs:

add_header Fuck-Google;

@aral @SwooshyCueb hot take: see if you can send patches to make this a default in nginx and apache

Sign in to participate in the conversation
Aral’s Mastodon

This is my personal Mastodon.