Re: [w3ctag/design-reviews] First-Party Sets (#342)

We do, though we really ought to fix all those to be scheme + registrable domain. That one has the same issues to resolve around when to use it over origins.

There, the problem we're addressing is that the web grew up without these restrictions and sites are often spread across multiple domains. Two browsers have already found they need this: Firefox uses a hardcoded [list of related domains](https://github.com/mozilla-services/shavar-prod-lists#disconnect-entitylistjson) to extend first-party-ness. Edge's blog mentions doing [something similar](https://blogs.windows.com/msedgedev/2019/06/27/tracking-prevention-microsoft-edge-preview/). Moreover, these entity lists are paired with a blocklist anti-tracking strategy, rather than platform-wide changes. That means they only need to cover the subset of multi-domain sites also on the blocklist. The true set is likely much larger. (Anecdotally, I've seen bank sites bounce between domains like `bank.example` and `bank2.example`, likely because each component is hosted by a different provider.)

You're right that all this is ultimately should tie back to who the user thinks they're interacting with. First-party sets, unlike the lists above or some kind of Storage Access API policy tweak, tries to identify each set with an owning origin, so there's room to explore surfacing that information. But folks like @estark37 have done far more research into this sort of thing than me, so I'll defer to her expertise there.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-601804691