I don't have very strong feelings on FloC. I think the EFF raised a good point that it can be used as a strong piece of data for fingerprinting. But they didn't address that fingerprinting becomes...
I don't have very strong feelings on FloC. I think the EFF raised a good point that it can be used as a strong piece of data for fingerprinting. But they didn't address that fingerprinting becomes less necessary as a result of FloC's existence (particularly when coupled with the privacy budget).
I think the idea is okay in theory. Advertisers really don't give a lick what your name is or what street you grew up on. They want to know what your interests are and what kind of products you buy. By removing the individual, it's clearly a more "privacy-respecting" process than what we have now. Compared to the advertiser ID used by other platforms like iOS and Windows 10, we're giving the advertisers what they need (or at least want) without giving them the user.
I do feel that FloC is over-engineered though. The complexity makes it difficult to educate about, and the "AI magic" makes it a bit of a black box. It's also not exactly clear how it will avoid sensitive topics other than manual curation.
Hopefully native controls are built in to reset or customize your cohort. The biggest advantage of handling this client-side is they we ultimately retain control. If that control isn't exposed to the user though, then the browser isn't really acting as your "user agent" at all.
I was hoping to see more technical criticisms of FloC, but it seems to be the typical kneejerk response from the usual suspects. I don't think many people are recognizing the reality that the web economy is built on ads, and you can't simply burn it all down without destroying many of the businesses which rely on it (which is far more than just Google).
I do of course get why the idealists are opposed, just as they were with Encrypted Media Extensions. I used to fall into that camp too. But I see it as a compromise solution. Advertisers aren't exactly thrilled either as they're losing some of the high-precision accuracy they had before. FloC is an approach that tries to walk the line, solving the biggest issues from both sides while making neither party happy.
It seems like instead of calling that other post “misinformation” you could do the “yes, and” thing by clarifying that if you’ve locked down content security policies against third-party...
It seems like instead of calling that other post “misinformation” you could do the “yes, and” thing by clarifying that if you’ve locked down content security policies against third-party JavaScript, it guards against a lot of other things and you don’t need that header. Maybe the author of that other blog post would be willing to add that if you wrote to them?
Reading it again, I don't think this claim is well-supported: Sure, it's not specifically for that, but the protocol is explicitly extensible by user agents. Here's the list of features supported...
Reading it again, I don't think this claim is well-supported:
Using the Permissions Policy to opt out of cohort calculation isn’t really what the Permissions Policy was intended for.
Sure, it's not specifically for that, but the protocol is explicitly extensible by user agents. Here's the list of features supported by the permissions API. It includes both standard and experimental features, and the list itself is "non-normative." If there were some goal of the authors of this API other than to be a generic place where browsers can put permissions for all sorts of features, it doesn't seem very clear?
Oddly, that web page only includes Chrome support. Hmm... it looks like the Permission Policy header itself is only supported by Chrome? Apparently Feature Policy has much more browser support, but it's been deprecated in favor of Permissions Policy and most browsers haven't moved over yet.
Also, the "do not track" header was proposed by researchers and only Firefox really signed on, while this header flag was proposed and implemented by Chrome. It doesn't make a lot of sense that they would stop honoring it when they were the ones promoting it. Having an easy way for websites to opt out of the FLoC calculation is intentional.
Although the protocol is opt-out, it may make sense for some web servers to default to turning all features off (including other permissions like geolocation) and then have the website admin turn them on if they decide they want it. This might confuse some website admins who won't know why a feature isn't working, though.
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...
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.
I don't have very strong feelings on FloC. I think the EFF raised a good point that it can be used as a strong piece of data for fingerprinting. But they didn't address that fingerprinting becomes less necessary as a result of FloC's existence (particularly when coupled with the privacy budget).
I think the idea is okay in theory. Advertisers really don't give a lick what your name is or what street you grew up on. They want to know what your interests are and what kind of products you buy. By removing the individual, it's clearly a more "privacy-respecting" process than what we have now. Compared to the advertiser ID used by other platforms like iOS and Windows 10, we're giving the advertisers what they need (or at least want) without giving them the user.
I do feel that FloC is over-engineered though. The complexity makes it difficult to educate about, and the "AI magic" makes it a bit of a black box. It's also not exactly clear how it will avoid sensitive topics other than manual curation.
Hopefully native controls are built in to reset or customize your cohort. The biggest advantage of handling this client-side is they we ultimately retain control. If that control isn't exposed to the user though, then the browser isn't really acting as your "user agent" at all.
I was hoping to see more technical criticisms of FloC, but it seems to be the typical kneejerk response from the usual suspects. I don't think many people are recognizing the reality that the web economy is built on ads, and you can't simply burn it all down without destroying many of the businesses which rely on it (which is far more than just Google).
I do of course get why the idealists are opposed, just as they were with Encrypted Media Extensions. I used to fall into that camp too. But I see it as a compromise solution. Advertisers aren't exactly thrilled either as they're losing some of the high-precision accuracy they had before. FloC is an approach that tries to walk the line, solving the biggest issues from both sides while making neither party happy.
It seems like instead of calling that other post “misinformation” you could do the “yes, and” thing by clarifying that if you’ve locked down content security policies against third-party JavaScript, it guards against a lot of other things and you don’t need that header. Maybe the author of that other blog post would be willing to add that if you wrote to them?
Updated the reference to the other post.
Edit: updated again (a few times); it's less finger-pointy now.
I really need to be less quick to publish
Reading it again, I don't think this claim is well-supported:
Sure, it's not specifically for that, but the protocol is explicitly extensible by user agents. Here's the list of features supported by the permissions API. It includes both standard and experimental features, and the list itself is "non-normative." If there were some goal of the authors of this API other than to be a generic place where browsers can put permissions for all sorts of features, it doesn't seem very clear?
Oddly, that web page only includes Chrome support. Hmm... it looks like the Permission Policy header itself is only supported by Chrome? Apparently Feature Policy has much more browser support, but it's been deprecated in favor of Permissions Policy and most browsers haven't moved over yet.
Also, the "do not track" header was proposed by researchers and only Firefox really signed on, while this header flag was proposed and implemented by Chrome. It doesn't make a lot of sense that they would stop honoring it when they were the ones promoting it. Having an easy way for websites to opt out of the FLoC calculation is intentional.
Although the protocol is opt-out, it may make sense for some web servers to default to turning all features off (including other permissions like geolocation) and then have the website admin turn them on if they decide they want it. This might confuse some website admins who won't know why a feature isn't working, though.
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.