Re: [w3ctag/design-reviews] "credentialless" embedder policy. (#582)

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](https://wicg.github.io/cors-rfc1918/) 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](https://html.spec.whatwg.org/dev/origin.html#the-headers); COEP [may as well](https://github.com/whatwg/html/issues/6328)). 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](https://www.chromium.org/Home/chromium-security/corb-for-developers) and [ORB](https://github.com/annevk/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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/582#issuecomment-770253632