"credentialless" embedder policy.

[mikewest]

Guten TAG!

I'm requesting a TAG review of a "credentialless" cross-origin embedder policy mode.

Today, COEP: require-corp exists, and is used to enable cross-origin isolation (and therefore SharedArrayBuffer, etc). It is functional and solid, but turns out to be difficult to deploy at scale, as it requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc). https://github.com/mikewest/credentiallessness/ suggests an alternative that might have better deployment characteristics: strip credentials from outgoing requests by default, and send them only for CORS-enabled requests. In this model, resources would either explicitly opt-into sharing themselves with the requestor, or would be low-risk, insofar as it's less likely to contain personal information if browser-controlled identifiers like cookies aren't included.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/credentiallessness
• Security and Privacy self-review²: Let me get back to this when we're further along... It should be strictly positive.
• Primary contacts (and their relationship to the specification):
  • Mike West (@mikewest), Camille Lamy (@camillelamy), Ian Clelland (@clelland)
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Nope.

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG, or just WHATWG PRs, as it might not be complicated enough for an entirely separate doc.
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG (this would live in HTML (and maybe bits in Fetch?))
• Existing major pieces of multi-stakeholder review or discussion of this design: This is it. Being my favourite standards review body, y'all are first on my list.
• Major unresolved issues with or opposition to this design: None (yet!).
• This work is being funded by: Google

You should also know that: the subresource bits of this proposal seem pretty clear to me, and I have some reasonable amount of confidence that they make sense. Frames are harder, and I'd appreciate y'all's thoughts. I'd also appreciate your help weighing the impact of non-cookie based ACLs, and the potential dependency upon CORS-RFC1918 (which y'all are reviewing in #572. It might also be helpful to review conversations like whatwg/html#4175 (comment) where @clelland originally surfaced this suggestion.

We'd prefer the TAG provide feedback as:

💬 a comment in this issue and @-notify the folks above.

[torgo]

Hi @mikewest - thanks for sending us this. We're just reviewing this in our "f2f" this week and on review of the explainer, I was wondering if you could provide a bit of additional context, starting with the user need... As usual for this kind of thing one of my other questions is: how does this change life for web developers (and what kinds of developers would be most impacted) and how (if at all) does it change life for end users?

[dbaron]

Also curious what the interest in this proposal is from other browsers, and also curious whether @annevk has opinions on this.

[mikewest]

I tried to sketch out the need in the introduction, with the specific example of Earth: TL;DR: sites that include content from third-parties cannot deploy COEP: require-corp until those third-parties adopt CORS or CORP. The hope is that we can create similar security properties without being blocked on opt-in.

It might also be helpful to frame this in terms of a broader story: it is clear to me that we need to shift the web's defaults towards isolation, because side-channels are pervasive, and attacks on them only get better. COEP: require-corp cannot be enforced by default. Most web sites would break. I believe we can get to a world in which CORP: whatever-we-call-this-credentiallessness-thing could be enforced by default, with low propensity for user-facing breakage, as substantial numbers of users choose to block third-party cookies today.

So, in the short term, it allows some sites that can't opt-into cross-origin isolation with COEP: require-corp to do so. In the long term, it gives us a path towards opting everyone in.

[annevk]

I think it's good to explore this as it would be a safer default and the document already calls out the problematic areas:

• How to secure nested navigation?
• What about IP-based authentication and "local" networks?

My opinion depends on how those questions are addressed. 😊

[mikewest]

How to secure nested navigation?

This is the big one, and he document proposes two alternatives, but there may well be other, better methods. From Chromium, @camillelamy and @ArthurSonzogni have volunteered to work through it, and I know they'd appreciate both your opinions, @annevk, as well as the TAG's insight. Ideally folks like @othermaciej could help us find WebKittens interested in the problem space as well, as there are similarities between the result of opting into this proposal, and the default behavior Safari ships.

What about IP-based authentication and "local" networks?

Private Network Access (née CORS-RFC1918, which y'all are reviewing in #572) seem like the long term answer. In the short term, the core question is whether this hole in the mechanism is one which blocks us from considering COOP: same-origin + COEP: whatever-this-is-called cross-origin isolated. Given that @letitz is actively working on that long term solution, I think it's a hole we can temporarily accept in Chromium, as it's strictly better than our status quo, and will allow us to keep SharedArrayBuffer deprecation on track by unblocking a few sites we've talked to that are having issues with COEP: require-corp and dependencies.

I'd be quite interested in hearing whether Mozillans (and the TAG!) share that opinion. :)

/cc @othermaciej for all of the above, as I'm still hoping that WebKittens will rejoin this kind of conversation around cross-origin isolation.

[annevk]

Briefly, Private Network Access and https://github.com/annevk/orb seem needed and we need an explicit opt-in for nested navgiations one way or another (either the rather attractive "reverse-XFO" or something else).

[mikewest]

Briefly, Private Network Access and https://github.com/annevk/orb seem needed and we need an explicit opt-in for nested navgiations one way or another (either the rather attractive "reverse-XFO" or something else).

I agree that some ORB variant is necessary. We ship CORB in Chromium, which seems Good Enough to start with. I know there's interest in hardening CORB into something ORB-like if we can get away with it (@anforowicz was looking into it, I believe).

I also agree that embedded contexts should opt-into the embedding. I think there's a good conversation to be had around the ways in which opt-in could work in the credentialless case, and I don't think we need to block that on the broader attempt to invert XFO (which y'all, dear TAG, closed out happily(?) in #578); we could certainly require specific embedding permission in these cases. Alternatively, we do the same thing we do for COEP: require-corp by requiring these resources to CORP themselves, and assert a COEP compatible with the top-level. That's possibly safer, at possibly higher deployment cost.

Private Network Access is, IMO, simply a question of ordering. It seems like a reasonable approach to the problem, but not one that we're going to be able to ship tomorrow (and certainly not cross-vendor). I think it might be reasonable for credentiallessness to enable cross-origin isolation even in its absence, and for us to use that remaining hole as additional pressure to justify backwards incompatibilities. Note also that COI just makes side-channel attacks faster. I think we need to ship private network access generally, COI or not.

[camillelamy]

I think I am more in favor of option of requiring frames to CORP themselves and assert a COEP that is not unsafe-none. The way I see it, an iframe that has the right CORP and a COEP that is not unsafe-none should embeddable in a COEP whatever-we-call-this-credentiallessness-thing. We can start with that, and if we find that it is too hard to deploy, maybe we can think about Mike's option 2 as a fallback.

Looking at the user needs for this, it seems to be mostly around subresources rather than nested iframes. So IMO, option 1 gives something that we can more easily reason about in terms of security and still help quite a bit with the deployment of COEP.

[rniwa]

I don't think credential is the only issue here. Given the pervasiveness of home router and other services like IoT providing security & privacy sensitive (e.g. web cam, photos, geo location, etc...) information over web interface, I don't think we can let cross-origin content be loaded from local network as @annevk pointed out earlier. Do most consumer routers even implement RFC1918?

[othermaciej]

as there are similarities between the result of opting into this proposal, and the default behavior Safari ships.

What are the key differences? If the intent of this proposal is to opt into a mode that blocks all third-party cookies, then I would be skeptical of the value. Safari already does it by default, and Chrome team announced a year ago that they'd do so by default in two years (i.e. a year from now). It seems likely this behavior will be the default in all browsers in not too long. If that's the case, it would be regrettable to add syntax to opt into the likely future default, and also regrettable to add syntax that gives the impression of allowing sites to opt back into third party cookies.

[mikewest]

Thanks for your comments, @rniwa and @othermaciej:

I don't think we can let cross-origin content be loaded from local network as @annevk pointed out earlier.

As noted above, the soon-to-be-renamed CORS-RFC1918 proposal seems like a reasonable solution to this problem, creating an opt-in mechanism similar conceptually to the CORP/CORS mechanism we accept today. If y'all have opinions about that proposal's shape, I'm sure @leitz, et al. would love your feedback in #572.

What are the key differences? If the intent of this proposal is to opt into a mode that blocks all third-party cookies, then I would be skeptical of the value.

Excellent question! There are two distinctions that seem most relevant:

1. Similar to COEP: require-corp, this proposal operates on origins, not sites or "parties". In this mode, www1.example.com would not send credentialed no-cors requests to www2.example.com, meaning that a vulnerability in one application on a site wouldn't create vulnerabilities in another (consider mail.google.com and docs.google.com, which are insufficiently isolated today).
2. Depending on the framing behavior we end up with, this might be a restriction above and beyond the requireStorageAccess mechanisms shipping in Safari, Firefox, and Edge, disallowing credentials for no-cors requests even with storage access has been granted.

I take the point about setting developer expectations, however, and I agree that we shouldn't imply that credentials would be sent in violation of a given vendor's policy. Perhaps that boils down to a question of naming? credentialless-nocors might promise less?

Chrome team announced a year ago that they'd do so by default in two years (i.e. a year from now)

We also announced that we're locking SharedArrayBuffer behind cross-origin isolation in Chrome 91 (i.e. ~May). This proposal is aimed at addressing a category of sites using SharedArrayBuffer today that have difficulty deploying COEP: require-corp due to their dependencies.

[mikewest]

@camillelamy: I think I can be comfortable with either of the embedding options discussed in the doc. The first does seem simpler conceptually, and avoids hard questions around the storage access inside that doc, both today and tomorrow. I do worry a bit about the deployment story, as opt-in seems difficult for some subset of folks, but I think I agree that it's better to try the first option, and shift to the second if and only if we have to. /cc @arturjanc, who will certainly have opinions.

[arturjanc]

I wanted to add a couple of thoughts about the two aspects covered here that I'd consider the most interesting:

Local network resources

While I definitely agree that the CORS-RFC1918 proposal is important to get robust protection for local network resources, I wanted to highlight existing mechanisms that already seem to address a large chunk of the risk here.

First, cross-origin isolation (COI) works only in secure contexts because that's a requirement for the individual mechanisms which enable COI (COOP already requires a secure context; COEP may as well). With the mixed content protections which have shipped in modern browsers, a COI page will not be able to request most types of resources from HTTP endpoints; so in the common case of a legacy home router / IoT device whose UI is generally served over HTTP, its resources will not be fetchable in credentialless mode.

Second, CORB and ORB limit the risk to only resources loaded as no-cors, e.g. images, scripts or stylesheets. This means that even in situation where there is a local-network HTTPS server with non-cookie-based authentication, the only resources that could leak would be the ones mentioned above, which are predominantly static, especially in simple applications.

So while we should definitely work towards CORS-RFC1918, I don't think we should consider it sine qua non for credentiallessness. Since the security benefits of credentiallessness (especially as a possible eventual web default) are considerable, we may want to weigh the perceived risks to local resources against the improvements offered by credentiallessness.

Credentialless iframes

I also agree with the idea that loading no-cors subresources in credentialless mode provides the most value to developers and addresses some of the biggest hurdles to shipping cross-origin isolation by default. However, my guess is that the problem of iframes is still something that is going to hold back the adoption of COI and will be a practical obstacle to shipping restrictions by default.

To that end, I'm wondering if we could clarify what we believe to be the risks to iframes that would require opt-in on part of the iframe. Especially in a world where browsers ship either network state / local storage partitioning or OOPIFs, it seems like the risk to data in iframes could be manageable. If we don't want to rely on these mechanisms, then I think it could be possible to introduce another concept where a browser ensures that a credentialless iframe doesn't have access to its origin's state.

We have a fair amount of precedent in the design of the iframe sandbox, which allows the embedder to take away certain privileges from the embeddee, including removing same-origin state (sandbox without allow-same-origin). It seems reasonable to consider the notion of a credentiallessly loaded frame as a document which has a separate storage container and loads all its resources without credentials.

@mikewest, @camillelamy - since the explainer is a little light on the details about the risks that push us towards an explicit opt-in for credentialless iframes, could you share some of your reasoning here?

[mikewest]

/cc @ArthurSonzogni, who's been thinking hard about this proposal over the last week or three.

since the explainer is a little light on the details about the risks that push us towards an explicit opt-in for credentialless iframes, could you share some of your reasoning here?

If we posit a world in which frames are always either out of process or sufficiently segregated from their top-level state (via partitioning, or storage blocking, or etc), then I agree with you that forcing them to opt-in to embedding would be superfluous. I also agree that there's some precedent for breaking a frame's ability to access storage it might have expected to be able to access, and I don't actually see much risk in doing so. That is, I think the explainer's option 2 isn't unreasonable.

That does create some complexity, though, regarding requests from the framed page to its own origin. If A frames B, it's straightforward enough to not send credentials along with that request, and to deny B the ability to access cookies and other site data via JavaScript. It's also straightforward to shift the no-cors credentials mode default to omit to prevent B from sending credentialed requests to B by default. What about cors requests, though? It doesn't seem like the server would have any expectation of risk around sending data to itself (and, as written, I think CORS requests would automatically pass, given the same-originness?). That seems like a potential for leakage that isn't well-explored, especially in the status quo world without OOPIF. We could resolve it with a partitioning scheme as you've suggested, but that's a good deal of work for third-party storage that we generally assume is on the way out.

I think my general stance here is that once we are solidly in an OOPIF-all-the-time world, we have a lot more flexibility to remove constraints than to add them. We ought to be working towards that world, and construct threat models that allow us to shift into it, but for the time-being, it seems necessary for us to avoid assuming that such a boundary exists.

[arturjanc]

What about cors requests, though? It doesn't seem like the server would have any expectation of risk around sending data to itself (and, as written, I think CORS requests would automatically pass, given the same-originness?). That seems like a potential for leakage that isn't well-explored, especially in the status quo world without OOPIF.

I think this may actually be simpler than you imply: An iframe loaded credentiallessly should load all of its resources credentiallessly. This applies to both same-origin resources (the requests shouldn't include cookies) and to cross-origin requests in cors mode: since they wouldn't carry credentials, they wouldn't leak any data as a result of being loaded by the iframe. (The external origin serving cors resources to the iframe may trust the origin of the iframe and allow these requests to be served even if it denies requests from other origins; but this still doesn't reveal any information because the requests are unauthenticated -- after all, an attacker could just fake the Origin header and send an identical request from their own device.)

In this approach, even without OOPIFs, it's hard for me to see any risk for the iframe because:

1. Resources loaded by the frame won't include authenticated data which could leak to the embedder.
2. Same-origin state available to the iframe (e.g. localStorage) would be limited to what is present in the current storage partition, so it wouldn't contain data set when the embedded origin is in a top-level context.

So, while I completely understand that pursuing credentiallessness only for subresources can be good tactically (it's a simpler problem), it's hard for me to see a compelling security reason to require a separate opt-in from iframes. Am I missing something? :)

[arturjanc]

BTW, if we are concerned about (2) above and want to prevent the iframe from potentially getting access to ambient same-origin state, we could certainly include credentiallessness as part of the storage partition key (for example).

[ArthurSonzogni]

So what are the different options for loading <iframe>?

Option 1: Block <iframe>, similar to COEP:require-corp

Ensure <iframe> have a policy stricter or equal to its parent, in this order:
none < credentialless < require-corp.

Parent \ Child	None	Credentialless	Require-corp
None	Allow	Allow	Allow
Credentialless	Block	Allow	Allow
Require-corp	Block	Block	Allow

Pros:

• Easy to implement.
• Similar to existing COEP:require-corp mechanism.

Cons:

• Hard to deploy. The document must wait for all of its <iframe> to deploy COEP first.

Option 2.a: Force COEP:credentialless into <iframe>

Force at least COEP:credentialless in <iframe>.

pros:

• Easy to deploy

cons:

• (edit) On platforms not supporting OOPIF: same-origin credentialed resources would be loaded by the iframe into the embedder's process. This allow cross-origin read via Spectre/crossOriginIsolated.
• The <iframe> has a small chance of being broken. The main resource was requested with Cookies, but every cross-origin non-cors request made won't have credentials. Maybe a parent might try to abuse this behavior somehow? This doesn't sounds very harmful to me, especially because it influences only cross-origin non-cors requests.

Option 2.b: Force COEP:credentialless + Reverse-XFO.

Same as 2.a, but require the iframe to explicitly opt-in being embedded
cross-origin via XFO or CSP:frame-ancestor.

pros:

• By default, documents that do not wish to be embedded won't have to deal with an embeder breaking them by forcing COEP:credentialless or (edit) using Spectre in non OOPIF browsers.

cons:

• Moderately difficult to deploy. This still require every embedder to opt-in being embedded. Anyway, this will have to happen either now or after Require embedees to opt-in. #578

Option 3. Load the <iframe> without credentials (navigation + subresources)

Load the <iframe> main resource without credentials. In the <iframe>, load every subresources (including CORS and same-origin) without credentials.

pros:

• Easy to deploy.

cons:

• The <iframe> is not able to make credentialled requests at all, even the same-origin or CORS one. It might be broken. This is very impactful compared to touching only cross-origin non-cors requests.
• Harder to implement. A new "credentialless" iframe mode must be introduced, in addition to the policy applied to the parent.

---

My opinion:
(1) is easy to implement. It is the strictest option. It will still be possible in the future to make it laxer. The opposite would be harder.

However, if our motivations is to ease deploying crossOriginIsolated, then I believe the bar is still very high. Option (2.a) seems like a good choice. I don't really believe "forcing" COEP can be used in a very harmful way.

I don't think option 2.b with Reverse-XFO bring much. Especially if we want to bring this behavior globally, as part of:
#578.

Option 3 from @arturjanc is also a good solution that would make deployment very easy. (2.a) is easier to implement however.

[arturjanc]

Thanks a lot for the analysis, @ArthurSonzogni!

I think a problem with Option 2.a is that this would allow you to force same-origin credentialed resources loaded by the iframe into the embedder's process (assuming the lack of OOPIFs). This may be fine in a world with partitioned storage, but then partitioning becomes an important security boundary, and I'm not sure we've treated it as such in the past.

So while I like the simplicity and deployability of that approach, my guess is that we may want "stricter" credentiallessness for iframes, i.e. ensure that they cannot load authenticated resources at all.

[ArthurSonzogni]

I think a problem with Option 2.a is that this would allow you to force same-origin credentialed resources loaded by the iframe into the embedder's process.

Oops. That's totally right! We can exclude 2.a. I assumed OOPIF support, which is not the case yet for every web browser. I was wondering what was the relationship in between COEP and reverse XFO since the beginning. Thanks for this clarification!

By the way, I can totally see website allowing being embedded cross-origin (youtube iframe), but not willing to share a process with a parent able to exploit them with Spectre (crossOriginIsolated). An explicit opt-in with XFO (2.a) might be a signal the website "agreed" about dealing with all the bad consequences of being embedded. However, I am afraid most didn't have cross-origin Spectre attacks in mind when they were created.

We should think a bit more about what option 3 might look like.

[ArthurSonzogni]

Bonjour TAG,

Looking at all the good discussions, option 3 above seems worth investigating as it seems to have properties above, but we let you all discuss and get back to us once you settle on the solution you think is best.

We discussed the <iframe> problem and option 3. What came out of this reflection is that we should split this proposal. COEP:credentialless should really only be about subresources. It shouldn't affect the subresources of other documents.

<iframe> are more complex than simple subresources. They represent risks different in kind, because they have their own context and can access storage APIs. To help developers with embedding cross-origin <iframe> with no explicitly opt-in from the embeddee, anonymous iframe has been proposed. It is orthogonal to COEP:credentialless, which now only affect subresources.

As a result, COEP:credentialless is now thinner. (potential monkey patch)
To comply with the cross-origin-isolation requirement, embedding <iframe> is still subject to the same restrictions as COEP:require-corp. That is to say, having a COEP header different from unsafe-none and sending a CORP header for cross-origin <iframe>.

[ArthurSonzogni]

I am worried my previous message might got unnoticed.
@ylafon or @torgo: Would it be possible to re-open this bug given the previous update: #582 (comment)

[ArthurSonzogni]

Hi @torgo, would it be possible for you to reopen this thread?

[torgo]

Hi @ArthurSonzogni sorry this got buried. I will bring it to the agenda for this week's plenary call.

[ylafon]

Sorry, I indeed didn't see the comment, worth reopening for sure.

[torgo]

Since we are re-opening, can I ask @mikewest @ArthurSonzogni why this is still sitting in a private repo? Is this work happening in a w3c venue - such as WICG or webappsec? If so, maybe the repo should be moved there?

[ArthurSonzogni]

I am trying to move it to WICG. Here was the request: WICG/proposals#31
It shouldn't take too long now.

[ylafon]

As the issue is no longer about iframe, could this be just a CSP? (I'm fine with this being COEP, but wondering where it fits better).
Also, based on the underlying issue driving this, it might be good to segment caches (SW, native) around the "includeCredentials" value, like public and private caches, or use its value as a cache key. (See w3c/ServiceWorker#1592, thanks @annevk for the pointer)

[ArthurSonzogni]

Thanks for this reply!

As the issue is no longer about iframe, could this be just a CSP? (I'm fine with this being COEP, but wondering where it fits better).

I am not totally sure to understand the benefits to define this as a CSP. If you can, could you provide some of them?

What I can see in favor of keeping it inside COEP:

• COOP and COEP are used to define a crossOriginIsolated context. If we move COEP:credentialless toward CSP, I am worried the story will be slightly harder to explain to developers. This will looks a bit less canonical.
• CSP already expanded very far away from its original essence I am a bit reluctant expanding further in another direction.
• COEP is already plumbed toward the CORP check for require-corp. The CORP check also ccheck for both 'require-corp' and 'credentialless'. If we want to convey it with CSP instead, I would have to plumb CSP as well. It's better if we can avoid it.

---

Also, based on the underlying issue driving this, it might be good to segment caches (SW, native) around the "includeCredentials" value, like public and private caches, or use its value as a cache key. (See w3c/ServiceWorker#1592, thanks @annevk for the pointer)

I believe you wanted to refer to: whatwg/fetch#1253 instead?
If yes, then I totally agree! That's already what Firefox implements. I would be happy to make Chrome converge toward Firefox here.

[ylafon]

I was not inferring any benefit of casting it as a CSP, but it made sense to just consider it (and your reasons sounds good enough to drop it).
Glad to hear that includeCredential-based segmentation is going on.
Closing this issue for now.
This looks good.
Thanks!