Repository navigation
COEP: credentialless #539
Description
Request for Mozilla Position on an Emerging Web Specification
- Specification Title: Cross-Origin-Embedder-Policy: credentialless
- Specification or proposal URL: Cross-Origin-Embedder-Policy: credentialless WICG/proposals#31
- Caniuse.com URL (optional):
- Bugzilla URL (optional):
- Mozillians who can provide input (optional): @annevk (?)
Other information
- explainer
- specification
- w3ctag: "credentialless" embedder policy. w3ctag/design-reviews#582
- Basic test website: http://coep-credentialless.glitch.me/
Activity
annevk commentedon Jun 21, 2021
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?
ArthurSonzogni commentedon Jun 24, 2021
Zoom let a comment on the WICG thread
Many large websites have registered to the reverse origin trial about gating SharedArrayBuffer behind cross-origin isolation. We are trying to provide them solutions to migrate. I can ask additional websites to put their feedback on the thread above.
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.
COEP:credentiallessis by far the easiest one to specify and implement. It also helps in the<iframe>case indirectly. It removes frictions for the embedee to deploy COEP, which allow their embedder to deploy COEP on their turn.If
COEP:credentiallesswas the default behavior for every website, then deploying COEP would only require all the 3P <iframe> to set a CORP header, which isn't a huge difficulty.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.
annevk commentedon Jun 24, 2021
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.
ArthurSonzogni commentedon Jun 25, 2021
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
COEP:credentiallesson Chrome doesn't make the current state worse, and it will accelerate the removal of SAB. Without Private Network Request,COEP:credentiallesswon't have achieved the final vision, I agree. We want both, butCOEP:credentiallesscan be experimented in parallel on Chrome even if Private Network Request hasn't launched yet. Private Network Request is critical and I have no doubt it will manage to launch.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.
annevk commentedon Jul 21, 2021
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.
ArthurSonzogni commentedon Sep 7, 2021
Hi @annevk,
At the moment, we are evaluating shipping it in Chrome M96 based on the feedback we've got so far.
Please let me know, if you think we should reconsider this.
annevk commentedon Sep 7, 2021
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.
ArthurSonzogni commentedon Sep 7, 2021
Yes, in the long run, PNA is required to protect those vulnerable resources. However, today, they are already vulnerable in Chrome without
COEP:credentialless.That's because we still maintain the reverse OriginTrial for SharedArrayBuffer. We have to extend it as long as most large websites have difficulties deploying cross-origin isolation.COEP:credentiallessis helping to migrate some of them.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.
Also, we're actively working on launching PNA. See deprecation trial.
About ORB, I think I would give the same argument.
Moreover, Chrome has CORB. Yes ORB is better, but we are not in a terrible position given CORB.
annevk commentedon Sep 13, 2021
I thought a reverse OT was limited to a select number of "trusted" parties.
credentiallessisn't that. I might be missing something though.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.
ArthurSonzogni commentedon Sep 13, 2021
About PNA. We just discussed shipping it earlier on the
COEP:credentialless,COEP:XorCOIsubset of websites. As long as the OT remains, this wouldn't improve the status-co , however it may allow PNA to be a little more aggressive with its schedule.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).
Code is here.
A reverse OT is a normal OT.
I don't know any OT where creating new token was restricted to a particular party. That would feel wrong to me, because this would give some website some kind of temporary advantages over others. It's a little less important for a deprecation, but still. Maybe you know some examples where it happened, but I don't myself.
domenic commentedon Sep 13, 2021
(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.
SamVerschueren commentedon Sep 29, 2021
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
credentiallessmode because when testingrequire-corp, we noticed that it breaks a lot of the user-generated content. The only solution we could come up with is by running all external requests through our own proxy. But that is definitely not something we want to do in terms of privacy.Rebase
annevk commentedon Nov 9, 2021
Given that nobody challenged this should be worth prototyping without dashboard entry, I'll consider this closed.
bholley commentedon Aug 23, 2022
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.
Yery commentedon Sep 10, 2022
This change broke chess analysis in the lichess online chess server , please see https://lichess.org/forum/lichess-feedback/nnue--firefox-10402
[-]Request for position: COEP: credentialless[/-][+]COEP: credentialless[/+]