You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 16, 2023. It is now read-only.
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. Any frame that is not allowed interest-cohort permission will have a default value returned when they call document.interestCohort(). If the main frame does not have interest-cohort permission then the page visit will not be included in interest cohort calculation.
For example, a site can opt out of all FLoC cohort calculation by sending the HTTP response header:
Permissions-Policy: interest-cohort=()
After reading the umpteenth story on FloC, I went to figure out how FloC works and ran into the above section and was shocked that no one's pointed out the following on the issue tracker.
That section implicitly violates the core tenet of the design of Internet communication protocols: "Be liberal in what you accept, strict in what you send."
It needs to be default disallow and individual sites enable the cohort policy if they want it enabled. This, as-is, would require all web server operators to modify their websites to send custom headers to opt out of something they shouldn't have to opt out of. It also potentially makes them legally culpable/liable if they didn't send the opt-out header and the automatic cohort computations violate laws in their locality. Maybe not today (except maybe GDPR or CCPA?) but someone might make it actually illegal in the future. Not all websites/webpages/web servers can be modified to send custom headers either. For example, flat, plain static HTML such as generated by modern tools like Jekyll won't be able to modify their own HTTP headers as returned from the server.
Opt-out HTTP headers are always 100% guaranteed to be the wrong approach. Opt-in participation and level of participation for each domain operator should be done upstream in DNS TXT records.
FloC is receiving massive backlash anyway in the public space and will likely get rejected by the W3C WG on various technical merits as well as being aware that they don't live in a bubble. But this specific technical aspect is fundamentally flawed on a protocol level. Don't violate well-established IETF standards and rules surrounding network communications! Violating them is the fastest way to upset network engineers, server operators, and software developers who know what they are doing. Those are the three groups of people you need to keep extremely happy if you want to have success in any endeavor.
The text was updated successfully, but these errors were encountered:
Hi Thomas, I think you misunderstand something about the header. Our best guess for the final state of FLoC is that the calculation will be based on just the domains that actually use the interestCohort API. The header removes that API, so that you can load a 3rd-party script and be sure that they won't use the API and opt you in. (Of course we're still in Origin Trial and very open to suggested changes, so I don't want to make it sound like anything is set in stone! But that's our expected path right now.)
There's also some different behavior during the Origin Trial so that we can simulate what the world would be like if all ad tech companies chose to use FLoC. Since an Origin Trial is supposed to be a way for a small number of early adopters to understand how an API would behave if fully launched, the "only if you use the API" behavior would have been useless in testing.
For a bunch of previous discussion, see #45 (comment).
The header removes that API, so that you can load a 3rd-party script and be sure that they won't use the API and opt you in.
I think that's the wrong way around - FLOC should be explicitly opted-in by websites. The interestCohort API shouldn't be available for use by third-party scripts unless the site has explicitly allowed for such use.
With regards to implementation, I think using DNS TXT records as suggested by @tucson-tom is reasonable - or even something like <meta floc="enable">.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After reading the umpteenth story on FloC, I went to figure out how FloC works and ran into the above section and was shocked that no one's pointed out the following on the issue tracker.
That section implicitly violates the core tenet of the design of Internet communication protocols: "Be liberal in what you accept, strict in what you send."
It needs to be default disallow and individual sites enable the cohort policy if they want it enabled. This, as-is, would require all web server operators to modify their websites to send custom headers to opt out of something they shouldn't have to opt out of. It also potentially makes them legally culpable/liable if they didn't send the opt-out header and the automatic cohort computations violate laws in their locality. Maybe not today (except maybe GDPR or CCPA?) but someone might make it actually illegal in the future. Not all websites/webpages/web servers can be modified to send custom headers either. For example, flat, plain static HTML such as generated by modern tools like Jekyll won't be able to modify their own HTTP headers as returned from the server.
Opt-out HTTP headers are always 100% guaranteed to be the wrong approach. Opt-in participation and level of participation for each domain operator should be done upstream in DNS TXT records.
FloC is receiving massive backlash anyway in the public space and will likely get rejected by the W3C WG on various technical merits as well as being aware that they don't live in a bubble. But this specific technical aspect is fundamentally flawed on a protocol level. Don't violate well-established IETF standards and rules surrounding network communications! Violating them is the fastest way to upset network engineers, server operators, and software developers who know what they are doing. Those are the three groups of people you need to keep extremely happy if you want to have success in any endeavor.
The text was updated successfully, but these errors were encountered: