Add HTTP header to explicitly opt out of FLoC by default

[ClearlyClaire]

Fixes #16034

[Gargron]

The page can restrict itself or subframes from accessing the interest cohort through the "interest-cohort" policy-controlled feature.

Why do we need to restrict ourselves from using a feature we don't use?

[ClearlyClaire]

The page can restrict itself or subframes from accessing the interest cohort through the "interest-cohort" policy-controlled feature.

Why do we need to restrict ourselves from using a feature we don't use?

We ourselves do not use ads or stuff, so it is unlikely our domain would be added. However, Google may change the rules in the future.

Furthermore, we do sometimes include third-party content in iframes, via preview cards. In this case, I believe the preview cards could cause the instance to be added to the cohort computation data.

EDIT: cf. https://github.com/WICG/floc#opting-out-of-computation this change is to not be part of the cohort computation data in any case, more than to prevent our code or included frames from getting the cohort ID

[hugogameiro]

From everything I read on the subject, if I join a Mastodon instance (that doesn't opt-out of FLoC) around a specific topic and I am using Chrome, I can be added to a Cohort that references that topic. At least this explanation presents a very similar situation:

Here is a synthetic but demonstrative example. Say I run a website selling polka music, and I serve a dedicated community of die-hard polka fans. My site is successful because I’ve identified a niche market that is poorly served elsewhere, which allows me to charge higher than, say, Amazon prices. However, FLoC may stick users browsing in Chrome in a “polka music lover” cohort, and begin having my users broadcast their “polka love” to other sites, including Amazon. Amazon could then peel off my polka-record buyers, leaving me worse off.

Also, from other source:

Websites can take steps to protect the privacy of their users by opting out of FLoC, which would be applicable to all their visitors. It's done by simply sending the following Permissions-Policy HTTP response header

Again, my knowledge on this is just from curious reading on the topic.

[ClearlyClaire]

TL;DR: Google's FLoC experiment computes a hash (SimHash) of the websites visited in the last 7 days, that hash defines a cohort, and cohorts are potentially merged with similar cohorts if the individual cohorts are too small (the decision to merge cohorts is opaque and decided by Google).

According to https://web.dev/floc/, only websites in which Chrome detects usage of ads may contribute to cohorts:

For pages that haven't been excluded, a page visit will be included in the FLoC calculation during the FLoC origin trial if document.interestCohort() is used on the page, or if Chrome detects that the page load ads or ads-related resources. (Ad Tagging in Chromium explains how Chrome's ad detection mechanism works.)

This may suggest that Mastodon instances won't contribute to cohort computation as they don't use ads, but as I said above, embedded players from preview cards (e.g., YouTube player) may, and in this case I think the Mastodon instance might be tagged as “loading ads or ads-related resources” and end up contributing to cohort computation.

Furthermore, Google may change those rules in later trials or in the final deployment, but the explicit opt-out mechanism is less likely to change.

Therefore, I think it is safer to explicitly opt out of the whole FLoC thing to ensure Mastodon instances do not end up included in cohort computation.

[Gargron]

I hate that we are forced to add a wasteful header on all requests to disable a Chrome feature nobody asked for that Chrome could choose to ignore anyway.

[nightpool]

(note that the "ad tagging" heuristic is only used as part of the 6 month experiment, for 0.5% of chrome page loads. The current plan is for the final version of FLoC to be opt-in only on the site level)