Recently, people have been telling webmasters to add a Permissions-Policy header to their sites to opt out of FLoC; these people don't seem to understand how the Permissions-Policy header works.

Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites to opt-out of Google’s FLoC, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default. When discussions got heated to the point of accusing webmasters who don’t implement these headers of being “complicit” in Google’s surveillance, I felt I had to write this.

Everybody: please calm down, take a deep breath, and read the spec before you make such prescriptive advice about it.

FLoC is terrible, but telling everyone to add a magic “opt-out header” in every situation conveys a misunderstanding of everything you need to know about the opt-in/out process.

  • ufra@lemmy.ml
    0·
    4 years ago

    The fingerprinting implications are not good no matter whether a site opts out or not. Theoretical protection against fingerprinting relies on a fairly ridiculous notion of Privacy Sandbox which seems easily skirted. Things like Trade Desk Unified ID combined with cohort ID actually makes FLoC privacy negative as it gives another data point to add to your already known identity.

    The point is that the only way for a site to opt out of participating is by using this W3C ordained way. It basically useless for end users but necessary for sites who don’t want to participate in the program.

    Google’s point is that all this and more is already going on with 3rd party system so why don’t we make this other crappy system which consolidates control further in their hands.

    It’s not misinformation however to provide to site operators information about how to opt-out of participation.