Misinformation about Permissions Policy and FLoC
seirdy.one
seirdy.one
That's exactly the point, so where's the misinformation?
Edit: The information from Google seems to be contradictory. From https://web.dev/floc/
> For pages that haven't been excluded, a page visit will be included in the browser's FLoC calculation if document.interestCohort() is used on the page.
This seems to imply that not calling document.interestCohort() (or not having ads on the page during the trial) is the same as opting out. But then on https://github.com/WICG/floc#opting-out-of-computation
> 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. This policy will be default allow.
This makes a lot more sense. Why would Google want to exclude sites from calculations just because they don't make use of the FLoc cohort themselves?
I think it would make sense as a measure to mimic the old behaviour of 3rd-party cookies and avoid the whole "my site is being used for tracking even though I didn't include any trackers" problem: Sites that use FLoC would effectively behave as if they had all joined the same single ad network. Calling document.interestCohort() would be equivalent to including a tracking script. (Site owner gets infos from the script, at the same time the ad network gets infos about the user and about your site)
If course the tiny difference is that with cookies that was an actual hard technical limitation, while with FLoC it's just Google doing this out of the infinite goodness of their hearts. As such, I don't really trust them on this and they already seem to muddy the waters with the origin trial exception.
> Here’s how not to opt-in to Google’s FLoC:
- Don’t load untrusted third-party content that might get classified as an ad (only applies during the origin trial)
- Don’t call document.interestCohort(), and don’t load third-party scripts that might call it either.
This reads like the web dev equivalent of "don't dress inappropriately". What's easier? Reworking half your front-end to meet some vague criteria and half-guessed heuristics of Google's as tagger and praying none of your transitive dependencies is calling a particular method - or adding one well-defined HTTP header?
> Given that non-standard header usage has failed in the client-side fight against surveillance capitalism before, I’m not too optimistic about trying this again from the server side.
That paragraph has it backwards. DNT was a header that browsers* were sending to sites* and that ad-networks were expected to comply to on their own - without any consequences for not doing so and even though this went exactly against all economic incentives.
This new header is sent from sites to the browser, and only a single party needs to implement compliance - Google. And they have already signalled compliance.
It's absolutely possible they will start to ignore or undermine the setting if too many sites are using it, but how about we cross that bridge when we get there?
I addressed this in the following paragraph:
> If you have to resort to adding a Permissions-Policy header to opt your site out of FLoC, it means that you’ve accidentally opted yourself in by including a tracking script (malware) on your page. I’d wager that opting into FLoC wasn’t the only nefarious thing those scripts do; chances are they bundle a host of other fingerprinting measures.
This xkcd sums it up a bit crudely: https://xkcd.com/463/. The fact that you even have to add this header means that your page is probably loading tracking scripts full of other antifeatures already; you have a bigger problem on your hands.
> This new header is sent from sites to the browser, and only a single party needs to implement compliance - Google. And they have already signalled compliance.
Given that other giants signaled compliance with DNT before backpedaling when their shareholders gave them a call and that it's in Google's best interests to do the same this time, I'm not optimistic that asking everyone to patch their software to include this header as a default (something I've seen several people advocating for on upstream software such as Mastodon) is a great idea.
By that logic, no o e should be running tracking scripts. And while that's certainly true in a moral sense, it doesn't match our reality.
Sometimes, the bigger problems are not the best problems to solve. No one adds tracking scripts by accident - so if a site adds those scripts, there is likely a reason why it has to do so and why it can't get rid of them in an instant. Maybe they have contractual obligations, maybe they don't have a better way to make money, etc etc. None of that is great, but in those cases, it might be pragmatic to close this one hole than to require them to redo all their architecture and business relationships.
By the same logic you could argue that no one should use sandboxes because, you shouldn't have RCE vulnerabilities in the first place.
> I'm not optimistic that asking everyone to patch their software to include this header as a default (something I've seen several people advocating for on upstream software such as Mastodon) is a great idea.
Why is it not a great idea? Yes, at some point in the future, the header might stop working, but we're not there yet. Even then, it will not cause any harm. So why not make it a default?