4 ms·
> 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-gue
by Seirdy 6y ago
> 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?
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/ 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.
- xg15 6y ago> you have a bigger problem on your hands. 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?