|
|
|
|
|
|
by IX-103
1836 days ago
|
|
|
The point of FLOC is that you are only ever part of one. There's no combining the different cohorts that a user is in to be done, because there is only ever one for each user. Now, there is some legitimate discussion on his to handle changes to cohorts, since simply changing the users cohort ID in response to a user changing their browsing interests leaves the user open to such a set intersection attack. Some people have suggested options such as freezing the ID for the lifetime of the site's state to prevent it. FLEDGE/Turtle*/etc. is a different issue. I'm not sure it will be more private than 3rd party cookies since the spec is not very clear and it has so many moving parts. I have heard from some Chrome devs that if it doesn't end up better for privacy than 3rd party cookies, it won't get past the origin trial stage. |
|
|
The docs/images they use make it look like an array but I just read the origin trial info page and it says ocument.interestCohort() only returns cluster id and algo version id.
still though the point stands i think. even say 1 million people in one cohort id # (they use 'thousands' to describe) + ip + UA and it's pretty unique, until apple and others proxying everything as recent posts suggest. Add whatever 8 bits or however many privacy allowance entropy and it's probably very unique and trackable over time if you have say TTD scale.
totally! it's very very confusing and I don't understand some (ok maybe a lot lol) of the RTB/context/retarget proposals and multiple RTB stakeholders have submitted their own too and they all have really stupid confusing names. But that's what I gather that it's basically the same result. It feels like the only way to do similar retargeting, conversion tracking is to have one 'trusted' source who gets all the data