Re: [w3ctag/design-reviews] COOP same-origin-allow-popups-plus-coep (#649)

Thanks for the feedback, @torgo! I'll reply to the few points that @mikewest didn't cover.

> The security considerations and privacy considerations sections of the explainer need to spell out some of the abuse scenarios - not from a security-jargon perspective but from a user-needs perspective.

I think part of the difficulty here is that this is a relatively modest incremental proposal built on top of the concept of [cross-origin isolation](https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability). The explainer & questionnaire focus on the impact of this specific change and not on the overall model of cross-origin isolation and the user-needs perspective, which were (at least partly) covered in previous reviews.

Some of the high-level considerations are outlined in the [cross-origin isolation threat model](https://arturjanc.com/coi-threat-model.pdf) (the **Background** section has a fairly concise overview, with links to related docs), and touched on in previous reviews: https://github.com/w3ctag/design-reviews/issues/527, https://github.com/w3ctag/design-reviews/issues/582. [Safely reviving shared memory](https://hacks.mozilla.org/2020/07/safely-reviving-shared-memory/) and [Why you need "cross-origin isolated" for powerful features](https://web.dev/why-coop-coep/) are two posts, from Mozilla and Google respectively, that explain the user benefit of cross-origin isolation. Put plainly, it allows browsers to provide APIs which would otherwise be dangerous to expose to websites because they could reveal cross-origin data; websites in cross-origin isolated mode are prevented from embedding authenticated resources that don't opt in and can be guaranteed to not share a browser renderer process with cross-origin documents. Without this concept, browsers couldn't implement APIs such as `SharedArrayBuffer` for fear of exposing the user's authenticated data (from applications to which the user is logged in) to malicious websites (e.g. via [in-process timing attacks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#implicit-clocks)).

The main problem is that websites that want to opt into cross-origin isolation (for example, to be able to use `SharedArrayBuffer`) have to adhere to a number of restrictions on their behavior which makes achieving cross-origin isolation more onerous than it needs to be. This particular proposal is meant to address one such restriction, commonly cited by developers as a pain point: the inability to communicate with pop-up windows from a cross-origin isolated page. The direct consequence of this problem is that, today, developers can use _either_ OAuth/payment flows or `SharedArrayBuffer` on their website, but not both: this makes developers' lives harder and prevents them from building capable applications. The indirect consequence of this problem is that it makes a large chunk of the web incompatible with cross-origin isolation (because many websites rely on interactions with the pop-ups they open). If we can change this, and make much of the web compatible with cross-origin isolation, it will allow us to shift the web defaults over the long term -- and enabling isolation by default will address a large fraction of cross-origin attacks which can leak user data, improving the security of the web ecosystem for all users.

> If it doesn't solve a user problem but only makes it somewhat easier for developers, and it achieves this by weakening security & privacy guarantees and opening up potential for abuse then maybe it's not a good idea? On the other hand, if it's intended to encourage developers to adopt better security practices then overall it can be a good trade-off. I think that's what you're getting at but can you try to spell it out a bit more from an end-user perspective?

The key point here is that the change proposed here doesn't weaken any of the core guarantees of cross-origin isolation. That is, it allows a cross-origin isolated window to interact with a pop-up it opens, but it continues to guarantee that the pop-up is cross-process from the opener. The [Security considerations](https://github.com/camillelamy/explainers/blob/master/coi-with-popups.md#security-considerations) section in the explainer covers why that's the case.

The outcome for users is the same as mentioned above: it makes it easier for websites to opt into cross-origin isolation (and build capable web applications), and by improving the web compatibility, it gives us a better shot at deploying cross-origin isolation on the web by default in the long term, improving security.

Is this along the lines of the framing that you're looking for to help with the design review?

> Also if developer feedback is the thing driving this then maybe this should be linked to in Chrome Status or in this review?

The issue @annevk linked above has some comments from developers about this; please see 
https://github.com/whatwg/html/issues/6364#issuecomment-872321265 or https://github.com/whatwg/html/issues/6364#issuecomment-866182438 for specific feedback.


-- 
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/649#issuecomment-879963923