For more details on Google’s latest affront to humanity, see this write-up by the lovely @PlausibleHQ folks: https://plausible.io/blog/google-floc
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?
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.
@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 Just pushed a Django app to disable this:
@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”
@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 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.
@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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!