fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-09-19 20:02:10 +00:00
Code Issues Projects Releases Wiki Activity

Clarification on exclusion from cohort calculation

Browse source 
Being excluded from cohort calculation doesn't necessarily make users
less unique.
This commit is contained in:
Rohan Kumar 2021-04-17 13:20:31 -07:00
parent 2ae6abbd82
commit d01bcc1971
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
2 changed files with 10 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
content/posts/permissions-policy-floc-misinfo.gmi
View file

@ -33,7 +33,11 @@ As per a post on Google's web development blog, web.dev, FLoC also will be enabl
## What explicitly opting out actually entails
What adding this header does is exclude your website from being used when calcualting a user's cohort. Cohorts are calculated locally from browsing history; sites that send this header will be excluded from this calculation. This may or may not reduce the entropy gained by a FLoC ID, depending on how well or poorly your site serves as an identifier. Given this marginal improvement, I don't think it's right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn't expect webmasters to add a tag or header every time Google advances the war against its own users.
What adding this header does is exclude your website from being used when calcualting a user's cohort. A cohort is an identifier shared with a few thousand other users, calculated locally from browsing history; sites that send this header will be excluded from this calculation. The EFF estimates that a cohort ID can add up to 8 bits of of entropy to a user's fingerprint.
Being excluded from cohort calculation has a chance to place a user in a different cohort, altering a user's fingerprint. This new fingerprint may or may not have more entropy than the one derived without being excluded.
Given this marginal improvement, I don't think it's right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn't expect webmasters to add a tag or header every time Google advances the war against its own users.
## How Permissions Policy works

6
content/posts/permissions-policy-floc-misinfo.md
View file

@ -32,7 +32,11 @@ As per a [post](https://web.dev/floc/) on Google's web development blog, web.dev
What explicitly opting out actually entails
-------------------------------------------
What adding this header does is exclude your website from being used when calcualting a user's cohort. Cohorts are calculated locally from browsing history; sites that send this header will be excluded from this calculation. This may or may not reduce the entropy gained by a FLoC ID, depending on how well or poorly your site serves as an identifier. Given this marginal improvement, I don't think it's right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn't expect webmasters to add a tag or header every time Google advances the war against its own users.
What adding this header does is exclude your website from being used when calcualting a user's cohort. A cohort is an identifier shared with a few thousand other users, calculated locally from browsing history; sites that send this header will be excluded from this calculation. The EFF estimates that a cohort ID can add up to 8 bits of of entropy to a user's fingerprint.
Being excluded from cohort calculation has a chance to place a user in a different cohort, altering a user's fingerprint. This new fingerprint may or may not have more entropy than the one derived without being excluded.
Given this marginal improvement, I don't think it's right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn't expect webmasters to add a tag or header every time Google advances the war against its own users.
How Permissions Policy works
----------------------------