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

[Sorry for the delayed responses, last week got away from me. :) ]

> The browser doesn't need to alert people before a redirect happens _as long as there are strong privacy boundaries between sites_. Users always know that their behavior on instagram.com is isolated from their behavior on facebook.com or instagram.facebook.com, regardless of what redirection is happening. If there is no way that facebook.com gets privileged access to instagram.com storage (or vise versa) w/o user intention; there is nothing to notify anyone about. Whatever the top level site is decides what storage is accessible.

@pes10k - Perhaps I'm not completely understanding the scenario here. Is it that the user has an existing session with `instagram.com` at the time that either (a) a FPS is formed with `facebook.com` and `instagram.com`; or (b) `instagram.com` redirects to `instagram.facebook.com`? So you're recommending a one-time prompt when the FPS is first formed in case (a), the user should be asked if they're okay with resuming their previous session with `instagram.com`? And that if there is a browser where (b) leads to a similar situation where a session created on `instagram.com` is shared with `instagram.facebook.com` via, say, a URL parameter, a similar prompt should be displayed?

> I agree that there is more work to do in figuring out solutions for moving away from heuristics. However, FPS by no means obviates the need for heuristics While FPS could certainly fix some instances of breakage (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1620530), there are many more where it can't be used because the breakage is cross-"entity".

@englehardt : Indeed, FPS will not, and should not, be used to solve these scenarios where cross-entity exchange of user identity is currently performed. We are investing in purpose-built APIs to support these cross-entity use-cases. Since third-party cookies are pretty versatile, it is important to think about what these use-cases need - some may need partitioned cookies, some may need [WebID](https://github.com/WICG/WebID/) (for federated login), some may need to use limited entropy APIs (such as [Trust Tokens](https://github.com/WICG/trust-token-api), or [conversion measurement](https://github.com/WICG/conversion-measurement-api)), etc. 

> The Storage Access API could be (or already has been) used to fix these issues. FPS could not. The benefit of the Storage Access API is that it can **also** be used to fix many of the types of things we might want to fix with FPS. Either way, we are going to have to work through a more generic approach to resolving breakage from reliance on cross-site state and we prefer to focus our efforts on these generic solutions.

I think FPS can be used to whittle down many of the use-cases where users may feel compelled to grant storage access today. If you have any statistics around commonly granted pairs of storage access, it may be an interesting case study to see if there are alternate solutions for them. My primary concern with the Storage Access API is that the prompt is not something that most users can understand, and that it will suffer the same consent fatigue problems as the widespread "cookie notice" prompts. Since browsers that currently support Storage Access API only require it under specific circumstances (heuristics, blocklists, etc.), I suspect we haven't seen it's full-scale impact.

Also, note that developers that have adopted Storage Access API might need to implement extra user friction/notices to ensure that users grant them storage access. As an example, [see how Zendesk](https://support.zendesk.com/hc/en-us/articles/360034788653-Zendesk-support-for-cookie-restricted-browsers-Safari-Chrome-) shows a "Safari cookie requirements" notice and instructs users to click "Allow".

> By focusing on a generic solution to user-controlled cross-site state, we also lessen the chance that we give large conglomerates a competitive advantage when it comes to UX. I don't think it's great if a multi-site company is granted passive storage access between all of their sites, while single-site companies that rely on embedded content from other sites (owned by other companies) are forced into showing a storage access API prompt. Of course one could argue that these multi-site companies will then combine everything under a single site, but we've heard during our calls that companies _want_ to maintain the separate branding and identity between their sites.

I want to correct two assumptions here:

- First-Party Sets is something that is trying to solve a generic need of mult-domain sites. Multi-domain sites are not unique to large conglomerates. 
- I am not suggesting that cross-party usecases should all have be forced to using the Storage Access API. I would like to ask that perhaps we need to understand the requirements better and recommend purpose-built APIs as appropriate for those use-cases. 


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