-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
COOP same-origin-allow-popups-plus-coep #649
Comments
Reading through whatwg/html#6364 will help provide some context for this. |
Hi @camillelamy - just seeking some clarification on this problem statement that starts off the explainer.
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. |
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? |
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 |
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 |
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? |
Camille is out of office until Thursday, I'll defer to her on the user-facing framing of the proposal.
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
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. |
Thanks for the feedback, @torgo! I'll reply to the few points that @mikewest didn't cover.
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 The main problem is that websites that want to opt into cross-origin isolation (for example, to be able to use
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?
The issue @annevk linked above has some comments from developers about this; please see |
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. |
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:
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? :) |
Just leaving link to https://arturjanc.com/coi-threat-model.pdf here at this has been helpful for our discussions on this issue. |
@hadleybeeman drafted this closing comment which we agreed to in the week of 08-30:
|
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.
Further details:
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
The text was updated successfully, but these errors were encountered: