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

I want to explicitly comment that the Microsoft Edge team is generally supportive of this proposal. I'm concerned with some of the framing and conclusions of the feedback doc that was shared. At the same time, some of the concerns in the document are shared by us and highlight that there's more work to be done.

My highest-level concern is that the feedback doc talks about the fundamental importance of origins but either doesn't consider or dimisses the likely alternate outcome that will happen without such a proposal: the consolidation of sites onto shared origins, which will carry both security and privacy implications.

The security implications of entities merging sites currently on different origins to be hosted on a shared one is reduced isolation between the sites, with a broader set of developers deploying code on the shared origin. What may have been a security issue on one site might now impact all of them. This could lead to a dramatic increase in attackable surface area. As the news has shown time and time again, security issues often have privacy impacts.

From a pure privacy angle, when running code in iframes from other entities (e.g. an analytics service), in the "put all of my sites on one origin" approach, the iframe would not have partitioned storage across those sites. With the current First-Party Sets proposal, those unrelated origins being iframed would still have partitioned storage (albeit with the ability for the hosting page to choose to provide a shared identifier) which is still a stronger default protection than today's 3p cookies.

The framing around the "redefines 3rd-party cookies" section potentially hints that 3p cookies are substantially blocked today; I don't know if that was the intent. Safari has blocked 3p cookies for some time, but also offers the Storage Access API to allow access that's shared across all sites. Firefox and Edge have a list-based approach to identify trackers and block 3p cookies for those alone, while also providing the Storage Access API to address instances where user-pereceivable brokenness is present; Firefox is also working on fuller "State Partitioning" but currently has compat affordances for SSO. Chrome doesn't currently block 3p cookies by defualt except in Incognito mode which brings compat issues. This proposal introduces a middle point where 3p cookies can be broadly blocked by defaut while allowing, in a much more limited way, some current scenarios to function as they do today. The proposal also doesn't preclude a browser from continuing to offer controls for users that want a more aggressive blocking configuration, even for First-Party Sets-related cookies.

The question of if this proposal puts users first also reaches a different conclusion that I do (I think it does prioritize users first). While this isn't the forum for feedback on the Storage Access API, it's important to consider the current solution space to evaluate the likely net impact on users. The Storage Access API has challenges in terms of how to adequately inform the user of both the reason for a prompt and the impact of approving it and also will potentially lead to prompt fatigue. If we hope to bring storage partitioning to the broader web, having more scoped primitives like First-Party Sets increases the odds that more browser vendors will be willing to ship with 3p cookies partitioned by default since the general user experience would meet their goals for user acceptance.

An area of the feedback that I do agree with is the concern around governance. This could generate significant interop challenges if entities had to choose to register with different browser vendors separately; many might choose to only focus on the largest market share browsers. At the same time, we already have multiple browsers shipping list-based approaches because it's been the only viable path thus far for an acceptable user experience. The TAG feedback argues that we shouldn't attempt to uplift anything that looks like a hand-approved list into a standard, which is a great goal but which current implementation choices shows is hard to avoid. My understanding is that the approval process for creating a set was added to the proposal in part because of concerns from other implementers that, even if the list size is kept small and sites are allowed to join one-and-only-one set that it would be insufficient due to abuses where sites owned by different entities collude to join the same set. 

A non-comprehensive list of areas I'd like to explore to mitigate the potential impact (which are not mutually exclusive) of the governance concern: make the max size of lists small enough to not need any approval (may not be practical due to the past concern about a lack of objective, user-intuitive criteria for when sites can join the same set); an independent entity to approve and/or revoke the ability to use a set, using a common set of criteria that multiple implementers agree to (a bit like CAs and web PKI, which carries its own set of challenges, though perhaps smaller in scope here); or "GREASE"ing of when First-Party Sets are used (e.g. disabling them some small percentage of the time and/or revoking the right to use them at all if the site doesn't function without them) to help sites prove/validate that they will function adequately for browsers and/or users who configure their browsers to limit or disallow the use of First-Party Sets.

Thanks for the healthy discussion!

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