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

Thanks for the comments, everyone!

@annevk We certainly need to be careful when introducing a non-origin boundary, but, FPS, eTLD+1, or something else, I think it’s sadly necessary.

The same-origin policy roughly ensures two origin will not interact *unless they want to*. https://a.example's data is safe from https://evil.example. but, if https://a.example and https://b.example *want* to share information, there are many opt-in cross-origin channels.

Those channels allow cross-site tracking. Mitigating this means limiting communications between two "sites" (however we define them) *even when they want to communicate*. This stricter isolation needs a coarser boundary. Consider subdomains like https://accounts.google.com and https://calendar.google.com. Separate origins isolate bugs, but the origins still interact, just as browsers use multiple processes but have IPC. If tracking mitigations worked on the origin boundary, those pages would need to be https://google.com/accounts and https://google.com/calendar to still work. User activity is as linked as before, and we've lost privilege separation.

Thus we need some larger boundary: a collection of origins treated as one “site" for anti-tracking purposes, whether eTLD+1 or first-party sets. Like you say, this comes with needing clear guidance on which to use, probably based on the above distinction.

@hober and @plinss We probably need to do a better job describing the use cases. Let me try clarifying things here and we'll see about updating the explainer. I don't think they'd all be covered by the Storage Access API.

One could imagine recasting the browser's knowledge of related domains into, say, a Storage Access API prompt suppression, but we don't think that would meet the compatibility or privacy needs here. Additionally, if this relatedness is to involve any site opt-in (in addition to the UA policy, of course), we need a standard way to manage that opt-in.

First, the Storage Access API assumes a particular flow (gesture into a 3p iframe), which makes sense for truly 3p scenarios. Multi-domain sites may need to interact more tightly. For instance, seamless single-sign-on across multiple first-party domains kicks in once the page loads.

Second, the platform should be aware of these sets. A pair of sites that always get storage access (prompt suppression or users just granting access on name recognition) are really one site w.r.t. linkability. Privacy-related platform limits must then cover the *entire* set, or each domain in the set will inflate the limit. Examples where this may make sense: [Privacy Budget](https://github.com/bslassey/privacy-budget), [Trust Tokens limits](https://github.com/WICG/trust-token-api#mitigation-per-site-issuer-limits), [Conversion Measurement limits](https://github.com/csharrison/conversion-measurement-api#limits-on-the-number-of-conversion-pixels), or limits on 3p [isLoggedIn](https://github.com/WebKit/explainers/tree/master/IsLoggedIn) queries to avoid fingerprinting.

We're also envisioning this feeding into other tracking mitigations that wouldn't fit the Storage Access API. Navigations within a first-party set could be exempt from potential mitigations for navigational tracking (link decoration, referrers, POSTs, etc.), which would reduce unnecessary compatibility impact.

This browser awareness can also translate into UI: clearing site data could offer to clear state across the entire set if the user wants to reset first-party linkability, or the browser could display the owning origin to the user somewhere.

Finally, some of these uses (limits, UI integration) are not just exception grants, so sites won’t want to be associated with unrelated domains. Even if the UA's list approves, it may be incorrect or out-of-date. We can fix this by requiring site opt-in in *addition* to UA policy, but that needs a standard mechanism. First-party sets provides that mechanism, as well as a story for handling changes (key state on owner domain and clear when it changes).

-- 
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-601427057