Hacker News Reader

Comment by jefftk | Hacker News Reader

you can target an Economist reader a week later on a different website. If FLoC works, you can still do that.

https://github.com/WICG/floc won't really let advertisers do that, this is what https://github.com/WICG/turtledove is for

(Disclosure: I work on ads at Google, speaking only for myself)

View on HN

Not disagreeing - I meant that generally, not specifically. You can still target by knowing something about the user, rather than relying solely on the content itself.

Makes sense!

What about the rest of the browsers? Safari has over 30% market share in the US.

Chrome's FLoC and TURTLEDOVE proposals are nascent web standards under the Web Incubator Community Group (https://wicg.io). My understanding is that Chrome is hoping to come up with something that other browsers also like?

Other browsers are working on this general project ("how do you do ads without cookies") too: Edge has https://github.com/WICG/privacy-preserving-ads/blob/main/Par... and Safari has https://webkit.org/blog/8943/privacy-preserving-ad-click-att...

As someone who helped connect various DMPs and server side systems in the ad industry, I don’t really understand floc. With first party cookies / server side data passing, things are tracked anyway is it not?

You visit a.example. It talks to a central server and says "I saw a user with identity a.example:foo". Then you visit b.example. It talks to a central server and says "I saw a user with identity b.example:bar". Without third-party cookies (or fingerprinting) how does the central server correlate these requests?

Ah, indeed. Appreciate that example. I guess my frame of mind comes from knowing what the large agency conglomerates are working around by using Unified ID or some other identity graph from pieces of data like hashed emails etc. Of course this means that the advertiser themselves are permitting such use.

user visits a.example

a.example doesn't have the user's identifier yet so it redirects to identifier.example

identifier.example sets a new ID as a cookie and redirects back with the ID

This happens so fast the user doesn't notice and location.replace doesn't generate history entries so there's no record of it happening

a.example saves the ID in its storage

Now the user goes to b.example

b.example doesn't have the ID so it redirects to identifier.example

identifier.example sees the ID in the cookie set when a.example redirected through and redirects back with the ID

b.example now has the same ID as a.example

That's all 1st party cookies

That worked in the early days of ITP, but it doesn't work anymore in any browser that blocks third-party cookies.

It still works, I made a PoC and tested it and it works on Chromium, FireFox and MobileSafari. https://xsid-demo.glitch.me/

You're right, sorry, that does work! I definitely thought it didn't...

This seems worth raising with browsers as a bug, since this should be easily detectable as an attempt to work around cross-site tracking restrictions?

OAuth2 or OIDC

I mean, yes, if you explicitly tell two websites who you are then they can agree on who you are. But that's very rare, no? What fraction of sites are you logging into?

"I work on ads at Google"

why?

Jeff answered this here: https://www.jefftk.com/p/why-i-work-on-ads

currency? lots and lots of currency?

In case you happen to know... I keep getting logged out of all websites on Chrome, pretty much every day. That’s a recent development. Is this symptom of how flock FloC works?

FLoC should be unrelated to cookie settings (for now), unless maybe you're using some alpha version.

Check if you've accidentally enabled some auto-delete?

Reply on news.ycombinator.com