COOP same-origin-allow-popups-plus-coep

[camillelamy]

Ya ya yawm TAG!

I'm requesting a TAG review of COOP same-origin-allow-popups-plus-coep.

To make crossOriginIsolation easier to deploy on sites with OAuth/payment flows relying on popups, we would like Cross-Origin-Opener-Policy: same-origin-allow-popups to also enable crossOriginIsolation when served with an appropriate Cross-Origin-Embedder-Policy header. This would introduce a new COOP mode, with a few restrictions compared to regular COOP same-origin-allow-popups. However, this mode would be crossOriginIsolated, while still having access to any popup it opens through window.postMessage.

• Explainer¹ (minimally containing user needs and example code): explainer
• Security and Privacy self-review²: self-review
• GitHub repo (if you prefer feedback filed there): repo
• Primary contacts (and their relationship to the specification):
  • [Camille Lamy] ([camillelamy]), [Google]
• Organization/project driving the design: [Google]
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Chrome Status

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WHATWG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[annevk]

Reading through whatwg/html#6364 will help provide some context for this.

[torgo]

Hi @camillelamy - just seeking some clarification on this problem statement that starts off the explainer.

Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation

Can you please start off by articulating the user need - what this is all in aid of when it comes to the end-user experience? I understand that some sites wish to continue to use SharedArrayBuffer in these circumstances. Why? How does this meet a user need and/or in what way is the user experience degraded if they are not able to? I'm trying to understand the actual scope of the problem and the actual user need you are trying to address.

[torgo]

Can you also clarify the following: There is a lot of discussion in the Mozilla thread about how WebID addresses these issues. Putting aside the fact that WebID is just a proposal and a community group at this time, how does it theoretically address the user need that is at the heart of this issue? It feels like it might address the OAUTH related cases but would not address the payment related cases?

[camillelamy]

SharedArrayBuffers is a basic building block of WebAssembly that allows shared memory between WASM threads. It allows to build high-performing web applications, in particular when such applications require to do a lot of computations. Without SharedArrayBuffers, the performance of those applications would be quite degraded.

At the same time, SharedArrayBuffers can be used to create high-resolution timer, which allow to exploit a Spectre vulnerability. So we have been forced to restrict their usage (based on the crossOriginIsolation mechanism). Otherwise, a malicious web page could use those to gain access to sensitive user-data from the cross-origin resources they embed.

The current mechanism of SharedArrayBuffer restrictions prevent cross-origin popups from working. This means that flows that rely on it, like OAuth or payments, don't work if the page wants to use SharedArrayBuffers. It seems that users might want to have high-performance web applications that don't leak their data and also support popup-based 3d party OAuth and payment flows. This is the problem this proposal is trying to adress.

WebID would solve the user need for OAuth flows. However, it does not address other kinds of flows, in particular payments.

@mikewest FYI

[arturjanc]

I'm trying to understand the actual scope of the problem and the actual user need you are trying to address.

In addition to what @camillelamy wrote above, I wanted to chime in with some more high-level background.

In the long term, it seems important for the web to move towards better default isolation between websites; see https://speakerdeck.com/mikewest/isolation-by-default (IIRC @mikewest also has a document with some more technical details; I'm not sure if it's public though?). COOP and COEP achieve this by introducing restrictions on cross-origin interactions between the document and the resources it loads and other windows it opens (roughly, by requiring authenticated cross-origin resources or windows to opt into these interactions).

Today, these restrictions are enforced on an opt-in basis: documents don't have to opt into COOP+COEP -- the only situation where we require this is when a document wants access to SharedArrayBuffers or other features that could potentially allow the information about cross-origin resources to leak to their embedder. Applications which need such features can now get access to them, safely. But, as Camille says, the main problem is that the current restrictions are onerous for developers and difficult to adopt in non-trivial applications (such as those using OAuth); this proposal makes it easier for developers to enable COOP+COEP without reducing the security guarantees provided by cross-origin isolation.

If we want to evolve the security model to provide these restrictions by default, the web compatibility story of cross-origin isolation is important; it will be difficult to move towards default isolation unless we make it possible for most sites to function under that model. IMO one of the main benefits of COOP same-origin-allow-popups-plus-coep is that it allows us to move towards isolation by default, improving the security of the ecosystem in the long term (i.e. that's a tangible user benefit in its own right, in addition to allowing developers to build applications that use APIs such as SharedArrayBuffer).

[torgo]

Hi @arturjanc. Just reviewing in this morning's TAG breakout. I think the phrase "...without reducing the security guarantees provided by cross-origin isolation" is really the key and this requires some additional elaboration. 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. "e.g. bad actors will try to do xxx to use this to steal users' infos". Likewise the user needs at the root of the problem need to be better spelled out - again in terms of what user problem this helps to solve. If it doeesn'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?

Also quick question: Referencing our previous review of origin isolation #464 and looking back at the implementation status, it looks like there is not good support across engines for this underlying tech (COEP/COOP) yet. Is it premature to start building stuff on top of it? Are there additional implementer signals for this specifically? Chrome status still shows "no information".

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

Finally, has there been any relevant discussions in WebAppSec that we should know about?

[mikewest]

Camille is out of office until Thursday, I'll defer to her on the user-facing framing of the proposal.

Referencing our previous review of origin isolation #464 and looking back at the implementation status, it looks like there is not good support across engines for this underlying tech (COEP/COOP) yet. Is it premature to start building stuff on top of it? Are there additional implementer signals for this specifically? Chrome status still shows "no information".

I'm not sure if you're asking about cross-origin isolation generally, or this specific proposal. COOP and COEP are integrated into HTML and Fetch, and are shipping in Firefox and Chrome with reasonably good test coverage (see COEP tests and COOP tests on WPT). Safari does not ship these mechanisms today, but has vaguely hinted at eventual COOP/COEP support publicly. Perhaps @hober has more information?

Note that the TAG review you pointed to in #464 is for a different feature entirely: the Origin-Agent-Cluster header, which indeed is only shipping in Chrome today (despite support from Mozilla to integrate it into HTML).

Finally, has there been any relevant discussions in WebAppSec that we should know about?

We discussed this problem briefly in April (https://github.com/w3c/webappsec/blob/main/meetings/2021/2021-04-20-minutes.md#coi-deployment-challenges). Camille has fleshed out the proposal since then, and I'm hoping that we can make it a topic in an upcoming meeting. I'd happily invite y'all if you're interested.

[arturjanc]

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. 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 (the Background section has a fairly concise overview, with links to related docs), and touched on in previous reviews: #527, #582. Safely reviving shared memory and Why you need "cross-origin isolated" for powerful features 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).

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 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
whatwg/html#6364 (comment) or whatwg/html#6364 (comment) for specific feedback.

[torgo]

Hi @arturjanc and @mikewest ok thanks for the responses. We're going to put this in a special breakout on Monday. @arturjanc I think we are looking for an even higher level user need - what are users going to be able to accomplish with improved "security" - what will increased adoption of this approach mean for users? That would both help us with the review and I think it will help you down the line when you're trying to document this - e.g. in an MDN page.

[mikewest]

I feel a little like we're talking past each other, @torgo. I'll take a stab at it? The claims I read above boil down to:

1. Cross-origin isolation is essential for building secure websites. Without process isolation, attackers can access data they shouldn't be able to access. https://w3c.github.io/webappsec-post-spectre-webdev/ attempts to spell that out, in addition to the threat model documents @arturjanc provided above and that y'all have looked into before.

2. Cross-origin isolation is difficult/impossible to deploy for applications that use cross-origin popups in their workflows, as the only mechanism for opting into COI today requires Cross-Origin-Opener-Policy: same-origin (which breaks the opener's window handle in both directions). OAuth and payments are excellent examples of things that users see, and expect to see working.

3. This proposal aims to create a mechanism of opting-into cross-origin isolation while allowing popups. We can do that without compromising on process isolation iff we can ensure that the popped-up window can load in a process distinct from its opener. We can do that if we make the behavior modifications the explainer suggests.

TL;DR: This proposal addresses the needs of developers who can't currently opt-into cross-origin isolation. By doing so, it protects the users of applications that are currently less secure than we'd hope for them to be.

If the above isn't what you're looking for, perhaps you could point to another review where someone's done a good job describing their feature from a user's perspective in a way you found productive and helpful? :)

[torgo]

Just leaving link to https://arturjanc.com/coi-threat-model.pdf here at this has been helpful for our discussions on this issue.

[torgo]

@hadleybeeman drafted this closing comment which we agreed to in the week of 08-30:

Hi all,

We've discussed this in our W3C TAG meeting today. We want to thank you for a thorough and helpful meeting on this and COOP/COEP.

We want to summarise our thoughts here, so that we have the notes in one place, and then we'll close this issue.

Our thoughts:

• We are concerned about anything that adds complexity to the web, confusing developers and making it harder for developers and site owners to produce websites. This proposal is substantially complex, though it does offer big benefits especially to users.
• We are still interested to hear how use cases develop. In our meeting, we asked if there was an assumption that, for example, a bank will never want to surface a PDF of a customers' bank statement on another origin. It sounded like you might discover that that use case does — or doesn't — actually occur in the wild. It will be interesting to hear how the various groups impacted by this respond.
• We started a discussion with you all about how to shift the defaults on existing content to benefit from this proposal. On the one hand, that could be a very substantial shift for the web, which is always challenging. On the other hand, we are still behind our Evergreen Web finding and recognise that everything needs to upgrade. So we are interested to hear, in due course, how you want to explore this.

Thanks again, and we'll be keen to see how this develops. Please do come back to us as you learn more from your work.