Skip to content
This repository has been archived by the owner on Mar 16, 2023. It is now read-only.

"Default allow" violates the core tenet of Internet communication protocols #106

Open
tucson-tom opened this issue Apr 20, 2021 · 2 comments

Comments

@tucson-tom
Copy link

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. 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.

@michaelkleber
Copy link
Collaborator

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).

@jamierocks
Copy link

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants