Isolation part is vague

[shhnjk]

First of all, thanks @mikewest for making a great draft👏 I'm really happy to see this change 🙂

I have question in following part.

3. Obtain references to a victim's window, which provides a postMessage() channel, and insight into the victim's state (via window.frames and friends).

I don't understand really well about attack you are trying to prevent by restricting postMessage(). If it's a fear that postMessage() could trigger XSS bug across origin, then there are window.name and PortalActivateEvent. If it's a fear against possible side channel, then there's ScrollToTextFragment + IntersectionObserver.

It'd be great if you can explain more in detail about what you want to solve with Isolation.

[mikewest]

I don't understand really well about attack you are trying to prevent by restricting postMessage().

postMessage() is an example of a persistent communication channel that's enabled by obtaining a handle to someone else's window. COOP would make that channel more difficult to obtain by breaking the WindowProxy on the opener side, and breaking opener on the openee side.

You're correct that there are still risks to being opened by someone else, but I think COOP would turn them into one-shot fire-and-forget attacks, as opposed to persistent mechanisms of retrying, which should hinder timing attacks' success rates.

It'd be great if you can explain more in detail about what you want to solve with Isolation.

I'm most concerned at the moment with side-channel attacks enabled by pulling cross-origin resources into an attacker's process, which is why the [SecureContext] mechanism of hiding APIs unless certain baseline standards are met is appealing.

I'd appreciate thoughts about how we can frame the threat model in order to make that more clear on the one hand, and how we might extend it to include threats I'm not currently considering on the other.

[shhnjk]

postMessage() is an example of a persistent communication channel that's enabled by obtaining a handle to someone else's window. COOP would make that channel more difficult to obtain by breaking the WindowProxy on the opener side, and breaking opener on the openee side.

I'm not familiar with COEP, but would Cross-Origin-Embedder-Policy: require-corp make sure that there's no cross-site frames or a portal?

I'm most concerned at the moment with side-channel attacks enabled by pulling cross-origin resources into an attacker's process, which is why the [SecureContext] mechanism of hiding APIs unless certain baseline standards are met is appealing.

This part is clear, and I think this is a great step :)

I'd appreciate thoughts about how we can frame the threat model in order to make that more clear on the one hand, and how we might extend it to include threats I'm not currently considering on the other.

I think what clear to me is the threat you are trying to protect against Speculative execution side-channel attacks. But how much we want to protect against XS-Leaks and stuff is unclear :) If require-corp can prevent cross-site frames or a portal, then it seems doable, as only remaining vectors are window.name or location.{search, hash}, which are one-shot fire-and-forget attacks.

[mikewest]

I'm not familiar with COEP, but would Cross-Origin-Embedder-Policy: require-corp make sure that there's no cross-site frames or a portal?

It would require cross-origin frames to opt-into being embedded, by setting a Cross-Origin-Resource-Policy header (see https://mikewest.github.io/corpp/#process-navigation-response). I'd expect we'd want to do the same things for portals, though that isn't specified yet.

That's obviously not complete protection, as opting-into being embeddable makes it possible to poke at you via the frame relationship (and COOP doesn't do anything in particular to break that relationship, unfortunately). But I think it still has substantial impact, as many exciting sites are unlikely to explicitly opt-into being embeddable.

[shhnjk]

It would require cross-origin frames to opt-into being embedded, by setting a Cross-Origin-Resource-Policy header (see https://mikewest.github.io/corpp/#process-navigation-response). I'd expect we'd want to do the same things for portals, though that isn't specified yet.

IIUC, sending Cross-Origin-Resource-Policy: cross-origin would allow cross-site frames to be embedded?

But I think it still has substantial impact, as many exciting sites are unlikely to explicitly opt-into being embeddable.

If cross-site frames can be embedded, then I'm not sure how you are going to maintain the Isolation.

1. Browser without Site Isolation will still be vulnerable to side channel, assuming sensitive site you are trying to protect has a cross-site iframe (e.g. ad). The Ad will still be in the same address space, without Site Isolation.
2. persistent communication channel (i.e. postMessage) will still be there, from malicious iframe to sensitive top frame (via window.parent or window.top).

[mikewest]

IIUC, sending Cross-Origin-Resource-Policy: cross-origin would allow cross-site frames to be embedded?

Yes. The frame can opt-in to being embedded. As I said above, it still has substantial impact, as many exciting sites are unlikely to explicitly opt-into being embeddable.

If cross-site frames can be embedded, then I'm not sure how you are going to maintain the Isolation.

I look forward to tightening Cross-Origin-Opener-Policy, or introducing something similar to it that affects frames. We didn't take that on as part of the COOP threat model at the moment, as most browsers still can't do out-of-process iframes.

TL;DR: Ship "good", don't wait for "perfect". :)

[shhnjk]

I look forward to tightening Cross-Origin-Opener-Policy, or introducing something similar to it that affects frames. We didn't take that on as part of the COOP threat model at the moment, as most browsers still can't do out-of-process iframes. TL;DR: Ship "good", don't wait for "perfect". :)

Got it, just wanted to make sure I understand this correctly :) It's definitely a great step forward :)

[mikewest]

Closing this out, as [CrossOriginIsolated] either deals with this or doesn't, but either way should be dealt with elsewhere. :)