Blocking FLoC is as easy as adding this header to the HTTP response:
Permissions-Policy: interest-cohort=()
Source: https://www.drupal.org/project/drupal/issues/3209628
Permissions-Policy: interest-cohort=()
Source: https://www.drupal.org/project/drupal/issues/3209628
That's "easy"?! How does my mom do that for her WordPress site?
Proposal: Treat FLoC like a security concern - https://make.wordpress.org/core/2021/04/18/proposal-treat-fl...
Consider implications of FLoC and any actions to be taken on the provider (WordPress) front - https://core.trac.wordpress.org/ticket/53069
Chrome has promised to listen if websites say they don't want to be included in the browser history they calculate that statistic on, but it's all client side, there is nothing the website can actually do but request that they aren't included.
It doesn't work that way at all.
I think the problem here is just one of language, a summary statistic is a number calculated from a set of data that gives you some idea of the contents of the data, but condenses it in a way that you can't reproduce the original data. Common examples for numeric data sets are things like mean, mode, median, standard deviation. Common examples for data sets consisting of a finite list of strings (such as browser history) would be things like average length, character frequency, count, etc. The cohort id generated is unambiguously such a summary statistic.
The website or ad network is able to read those numbers and build profiles on them, but it's still divorced from the user and their specific data.
I think a better comparison is that of a hash. It sums up the data, but is just a unique identifier for it. Of course with a cohort ID it's non-unique (by design).
Because the browser is only sending a number, it retains the ability to change, randomize, or obscure that number. That's an important privacy consideration of the system.
For what it's worth, I do think more work is needed. One of Mozilla's suggestions which I liked was to automatically send a missing ID on occasion, just to keep things a little hazy and reduce fingerprinting viability.
Fingerprinting is inherently less-necessary as a result of FloC, and you need to balance it to not become necessary again, but it's a way to protect users that fully opt-out without themselves become fingerprintable.
Almost certainly your browser history is summarized into a vector, and then the closest class number is chosen and sent.
You might not know which vector the number represents, but it does represent a vector for the centroid, and has relationships with other cohorts.
I'd say it's guaranteed that that interface is leaky
So instead of building a profile on specific users, the website (or ad network) builds profiles on cohort IDs. Users can change IDs, or mask theirs altogether if they wish.
DNT was DOA. You can blame Microsoft for that one.
Hilariously, I even opposed removing the code later because I wanted us to be a good citizen but it was practically dead code because people were still calling us evil. They could literally set their UA to play along (or use one that set it by default).
I think we always kept the code in but it only incurred cost and we got blamed anyway. I think, looking back, I should have just removed that piece of middleware since no user ever really cared. It wasn't worth it for the org to pay for code so I could have a clean conscience.
Saying you did something doesn't help the user know that DNT was followed
Maybe we tried some other codes but anything but 200 was unsafe to many UAs (you could 3xx but UAs would break on 304 too because the tracking pixel wasn't actually cached). Anything that led to UA breakage was verboten anyway on our side since we didn't want anyone to have a broken experience because they set DNT. That would have been bullshit.
We were dumb-enough to handle P3P headers too (which AFAIK no one really used in the end). Lots of dead code. Ugh.
There is a non-exhaustive list of features/APIs here: https://github.com/w3c/webappsec-feature-policy/blob/master/...
Each feature takes an allowlist, specifying which, if any, origins can use the feature.
https://github.com/w3c/webappsec-permissions-policy/issues/1...
What is happening in w3c?!
edit: ahhh i see it's in the http headers, not the head of the html. nvm.