-
Notifications
You must be signed in to change notification settings - Fork 69
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
Request for position: COEP: credentialless #539
Comments
As stated in w3ctag/design-reviews#582 (comment), in order for this to not increase the attack surface, browsers need an implementation of Private Network Access and ORB. Both are still in progress and somewhat experimental. Then, given the way nested documents are dealt with, there's also an implicit dependency on Anonymous iframes. I think the security properties work out, but it's a significant amount of added complexity. Is there interest in this beyond Google Earth? |
Zoom let a comment on the WICG thread I believe we can summarize the main frictions and the potential solutions by:
About the complexity of Private Network Request and ORB: those are projects we are doing anyway, they have values on their own. They don't seem like dependencies required just for COEP:credentialless.
I like to think of them as independent. If We would like every websites at Google to deploy COOP/COEP. The majority of them trying to roll this out haven't succeeded so far. There are difficulties with Earth, Gmail, Google Docs / Sheets / Slides, and some libraries fetching 3P resources. |
Thanks @ArthurSonzogni! It definitely helps to see the interest in this beyond Google and I tend to agree that making this the default could be attractive. I have a hard time seeing how Private Network Access and ORB are not dependencies, given that this gives access to cross-origin isolation. Even with those this still increases the attack surface, but I think everyone is more-or-less okay with giving up on defending the remaining IP-authenticated resources. With those sorted, I would say COEP: credentialless is worth prototyping. I think the same goes for Anonymous iframes. I have a much harder time with COOP: same-origin-allow-popups-plus-coep as from a privacy perspective (and arguably also from a security perspective) popups (in particular browsing contexts with an opener) are deeply problematic and I'm not convinced they are worthy of further investment. Further entrenching them seems incompatible with our longer term goals. |
Private Network Access is a dependency. However, today, SharedArrayBuffers are still available on Desktop without COOP/COEP. It will be as long as existing websites using them have no possibility to migrate to cross-origin isolation. So today, you can already leak subresources requested from the private network. Adding About ORB, I am no more sure to understand why the resources that will be blocked by ORB will represent an additional risk inside a crossOriginIsolated context with COEP:credentialless. The problem can't be about leaking the data since it was requested without credentials. Could you please explain the risk you were thinking about? I agree this is an important project, but I am no more sure this is a dependency. |
The resources that are vulnerable to Spectre with a credentialless mode are those on networks that the Browser can reach but the Attacker Server cannot. Private Network Access reduces the set of resources, but not completely due to the nature of the internet and the various setups people have created over the years. ORB further reduces the set of resources attackers can get hold of. |
Hi @annevk, |
It would help to get Google's perspective on what I wrote in my previous comment. As I understand it neither PNA nor ORB is done, so shipping this first seems dangerous. |
Yes, in the long run, PNA is required to protect those vulnerable resources. However, today, they are already vulnerable in Chrome without I think you can see @mikewest message here:
So we think it's security-positive in Chrome given the OT, and helps getting rid of it. About ORB, I think I would give the same argument. |
I thought a reverse OT was limited to a select number of "trusted" parties. As far as shipping this goes it seems dangerous to me without PNA/ORB. As far as implementer interest goes I think our position should be worth prototyping, modulo PNA/ORB. This probably doesn't warrant a dashboard entry, but I'll leave this open for a bit in case anyone feels otherwise. |
About PNA. We just discussed shipping it earlier on the As far as I know. The security implications of an Origin Trial are the same as a full launch. That's because everybody can freely sign a token against Chrome's private key on: https://developer.chrome.com/origintrials/ and immediately start using the feature. That's the case for the SAB one. What can be done is disabling remotely an OriginTrial or some individual trial token (due to abuse, or because developers did not respond to the survey). A reverse OT is a normal OT. |
(This is getting more into Chromium policy territory and maybe should be on blink-dev instead, but...) Although restricting signups is not part of OT infrastructure, there are some potentially-relevant differences here. Notably, if we use OT instead of fully shipping, we have a list of all the origins that are breaking COI protections by using credentialless without PNA/CORB, and we can do targeted outreach to them in the future, e.g. to make sure implementing PNA or CORB won't break them. Additionally, there is a cap on OT usage which ensures this unsafe configuration would not go above 0.5% of page views, which might be relevant since we're eventually trying to drive it down to 0% of page views. |
Hi everyone 👋 ! Not sure if this is the right place to put this, but we at StackBlitz are building a product where people can play around with all kinds of front-end frameworks. Not only that, recently we released WebContainers, a technology which allows you to run Node.js locally inside your browser. WebContainers heavily rely on SharedArrayBuffer and Atomics and thus has to implement cross-origin isolation. At the moment, we use Chrome's origin trial to make it work, but we would love to have support for other browsers like Firefox (and hopefully Safari at some day) as well. Cross browser support is much requested by our community. For that, StackBlitz would also benefit from |
Define COEP:credentialless Originally described in: https://github.com/mikewest/credentiallessness `credentialless` and `require-corp` are similar. One or the other is a requirements for the `window.crossOriginIsolated` capability. They differ mostly in the fetch specification. `require-corp` requires a CORP header for cross-origin no-cors responses. `credentialless` doesn't, but omits credentials (Cookies, clients certificates, etc...) in the request. * HTML (whatwg#6638) * Define how to parse the `credentialless` value. * From the HTML spec point of view, `credentialless` and `require-corp` are equivalent. They have been grouped into `compatible with cross-origin isolation` and the HTML spec rewritten to use this concept. * Fetch: (whatwg/fetch#1229) * Define `Cross-Origin-Embedder-Policy allows credentials` algorithm. It omit credentials for no-cors, cross-origin, COEP:credentialless requests. * Define `response's` `request-include-credentials` flag. * In the `Cross-Origin-Resource-Policy check`, if `embedderPolicy` is `credentialless`, require CORP for navigational responses, and opaque responses with `request-include-credentials`. See: whatwg#6637 ---- - [ ] At least two implementers are interested (and none opposed): * Chrome: https://chromestatus.com/feature/4918234241302528#details * Firefox: mozilla/standards-positions#539 (worth prototyping) * Safari: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html (pending) - [X] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at: * https://wpt.fyi/results/html/cross-origin-embedder-policy/credentialless - [X] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed: * Chrome: https://crbug.com/1175099 * Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1731778 * Safari: https://bugs.webkit.org/show_bug.cgi?id=230550 (See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)
Given that nobody challenged this should be worth prototyping without dashboard entry, I'll consider this closed. |
Just a heads-up to folks following this thread that Firefox 104 (which ships today) supports credentialless as an origin trial. We encourage site operators to deploy it and get in touch with any feedback. |
This change broke chess analysis in the lichess online chess server , please see https://lichess.org/forum/lichess-feedback/nnue--firefox-10402 |
Request for Mozilla Position on an Emerging Web Specification
Other information
The text was updated successfully, but these errors were encountered: