Cross-Origin-Isolate Header

[Ryosuke Niwa]

Here’s a proposal for new header as I promised.

Proposal

Add HTTP header called Cross-Origin-Isolate, which takes a value of 0 and 1. When the HTTP response of a document contains Cross-Origin-Isolate header with its value set to 1, the document is said to be "isolated".

Let document A and document B be cross-origin documents.

If document B is “isolated”, then document B's window acts as if its browsing context has been discarded (i.e. as if window has been closed) to document A. Similarly, document A's window acts if its browsing context has been discarded to document B.

That is, each document appears to one another if is the other document's frame/window to be closed. On same origin access, the header has no effect.

Let's say document B opened document A via `window.open`. Then window proxy of document B in document A's global object looks as if document B has been closed. i.e. `window.closed` is true. Similarly, document B's `window.opener` is NOT null but looks closed as well (i.e. `window.opener.closed` is true).

Let's say document A opened document A via `window.open`. In this case, window proxies in both documents behave exactly like in the previous case.

Let's say document A has an iframe of a document B. Then iframe's `contentWindow` in document A looks like closed; i.e. `iframe.contentWindow.closed` is true. Because it's cross-origin, `iframe.contentDocument` is null. Similarly, `window.parent` in document B looks as if "closed" with `window.closed` set to true. Note that `parent != self` is still true.

Spectre Protection Plan

For the purpose of protecting a website a.com from Spectre in browsers which support process swap for top-level navigations without cross-process window proxy support, a.com can set this header on all of its documents (not setting on some would result in leaks; more on this later).

If this header is set on a.com, we can swap process on cross-origin navigation from or to a.com's documents because this guarantees that a.com doesn't have access to any other document outside of its origin, and vice versa.

Let's say we're on some page B1 in b.com, and it window.open'ed (isolated) a.com. Then b.com doesn't have access to a.com, and b.com doesn't have access to a.com so we can put them into different processes. Obviously, a.com's iframes don't have access to b.com's frame tree either so if Facebook is currently relying on being able to do this, they won't be able to use this header.

Let's say now a.com is navigated to some other page B2 in b.com. In this case, the browser finds the process which loaded B1 and load B2 in the same process so that they can talk to one another via window proxies.

Navigation Prevention?

One possible addition to this feature might be to prevent all types of navigations. With what we proposed above, it's already the case that an isolated document's location object itself is inaccessible but documents with a window proxy to an isolated document can still navigate it via `iframe.src` or `window.open`. In particular, named frame navigation triggered by anchor element with a named target and/or `window.open` would still navigate the "isolated" document. We can prevent these navigations as well if we wanted. e.g. excluding "isolated" document's frame when choosing a browing context for the target (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name)

- R. Niwa

[Charlie Reis]

On Tue, May 1, 2018 at 2:59 PM Ryosuke Niwa <rn...@apple.com> wrote:

Here’s a proposal for new header as I promised.

Proposal

Add HTTP header called Cross-Origin-Isolate, which takes a value of 0 and 1. When the HTTP response of a document contains Cross-Origin-Isolate header with its value set to 1, the document is said to be "isolated".

Let document A and document B be cross-origin documents.

If document B is “isolated”, then document B's window acts as if its browsing context has been discarded (i.e. as if window has been closed) to document A. Similarly, document A's window acts if its browsing context has been discarded to document B.

That is, each document appears to one another if is the other document's frame/window to be closed. On same origin access, the header has no effect.

Let's say document B opened document A via `window.open`. Then window proxy of document B in document A's global object looks as if document B has been closed. i.e. `window.closed` is true. Similarly, document B's `window.opener` is NOT null but looks closed as well (i.e. `window.opener.closed` is true).

Let's say document A opened document A via `window.open`. In this case, window proxies in both documents behave exactly like in the previous case.

Let's say document A has an iframe of a document B. Then iframe's `contentWindow` in document A looks like closed; i.e. `iframe.contentWindow.closed` is true. Because it's cross-origin, `iframe.contentDocument` is null. Similarly, `window.parent` in document B looks as if "closed" with `window.closed` set to true. Note that `parent != self` is still true.

Spectre Protection Plan

For the purpose of protecting a website a.com from Spectre in browsers which support process swap for top-level navigations without cross-process window proxy support, a.com can set this header on all of its documents (not setting on some would result in leaks; more on this later).

If this header is set on a.com, we can swap process on cross-origin navigation from or to a.com's documents because this guarantees that a.com doesn't have access to any other document outside of its origin, and vice versa.

Let's say we're on some page B1 in b.com, and it window.open'ed (isolated) a.com. Then b.com doesn't have access to a.com, and b.com doesn't have access to a.com so we can put them into different processes. Obviously, a.com's iframes don't have access to b.com's frame tree either so if Facebook is currently relying on being able to do this, they won't be able to use this header.

What about the case where B iframes A and A opens a popup (e.g., the OAuth case)?  More specifically, document B1 in b.com iframes document A1 on (isolated) a.com.  As described, B1 and A1 act like they're not in the same frame tree.  However, when the user clicks on the login button in A1, A1 opens a top-level popup to document A2 on a.com.  Would A2 go into a new process for a.com based on the rules above?

In that case, A1 and A2 couldn't script each other, even though the window.closed rules don't seem to apply in the same-origin case.

This is one of the trickier scenarios to support, so I'm curious what your thoughts are.

 

Let's say now a.com is navigated to some other page B2 in b.com. In this case, the browser finds the process which loaded B1 and load B2 in the same process so that they can talk to one another via window proxies.

Yes.  Quick note on Chrome's approach-- we would put B1 and B2 in the same b.com process, but only if they were part of the same "unit of related browsing contexts" (which we call BrowsingInstance).  That way, all b.com tabs don't end up in the same process, which gets unusable with a large number of b.com tabs.  (Incidentally, this is why we call our policy "one site per process" instead of "process per site."  There can be more than one process for a given site.)

Charlie

 

Navigation Prevention?

One possible addition to this feature might be to prevent all types of navigations. With what we proposed above, it's already the case that an isolated document's location object itself is inaccessible but documents with a window proxy to an isolated document can still navigate it via `iframe.src` or `window.open`. In particular, named frame navigation triggered by anchor element with a named target and/or `window.open` would still navigate the "isolated" document. We can prevent these navigations as well if we wanted. e.g. excluding "isolated" document's frame when choosing a browing context for the target (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name)

- R. Niwa

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/B2816693-3AD6-4E4A-B1EC-469B0BB1355A%40apple.com.

[Ryosuke Niwa]

> On May 1, 2018, at 4:20 PM, Charlie Reis <cr...@chromium.org> wrote:
>
>
>
> On Tue, May 1, 2018 at 2:59 PM Ryosuke Niwa <rn...@apple.com> wrote:
>> Here’s a proposal for new header as I promised.
>>
>> Proposal
>>
>> Add HTTP header called Cross-Origin-Isolate, which takes a value of 0 and 1. When the HTTP response of a document contains Cross-Origin-Isolate header with its value set to 1, the document is said to be "isolated".
>>
>> Let document A and document B be cross-origin documents.
>>
>> If document B is “isolated”, then document B's window acts as if its browsing context has been discarded (i.e. as if window has been closed) to document A. Similarly, document A's window acts if its browsing context has been discarded to document B.
>>
>> That is, each document appears to one another if is the other document's frame/window to be closed. On same origin access, the header has no effect.
>>
>> Let's say document B opened document A via `window.open`. Then window proxy of document B in document A's global object looks as if document B has been closed. i.e. `window.closed` is true. Similarly, document B's `window.opener` is NOT null but looks closed as well (i.e. `window.opener.closed` is true).
>>
>> Let's say document A opened document A via `window.open`. In this case, window proxies in both documents behave exactly like in the previous case.
>>
>> Let's say document A has an iframe of a document B. Then iframe's `contentWindow` in document A looks like closed; i.e. `iframe.contentWindow.closed` is true. Because it's cross-origin, `iframe.contentDocument` is null. Similarly, `window.parent` in document B looks as if "closed" with `window.closed` set to true. Note that `parent != self` is still true.
>>
>> Spectre Protection Plan
>>
>> For the purpose of protecting a website a.com from Spectre in browsers which support process swap for top-level navigations without cross-process window proxy support, a.com can set this header on all of its documents (not setting on some would result in leaks; more on this later).
>>
>> If this header is set on a.com, we can swap process on cross-origin navigation from or to a.com's documents because this guarantees that a.com doesn't have access to any other document outside of its origin, and vice versa.
>>
>> Let's say we're on some page B1 in b.com, and it window.open'ed (isolated) a.com. Then b.com doesn't have access to a.com, and b.com doesn't have access to a.com so we can put them into different processes. Obviously, a.com's iframes don't have access to b.com's frame tree either so if Facebook is currently relying on being able to do this, they won't be able to use this header.
>
> What about the case where B iframes A and A opens a popup (e.g., the OAuth case)? More specifically, document B1 in b.com iframes document A1 on (isolated) a.com. As described, B1 and A1 act like they're not in the same frame tree. However, when the user clicks on the login button in A1, A1 opens a top-level popup to document A2 on a.com. Would A2 go into a new process for a.com based on the rules above?

No. In this case, the process which loaded B1 and A1 would also load A2 (in a new window).

> In that case, A1 and A2 couldn't script each other, even though the window.closed rules don't seem to apply in the same-origin case.

Right. This is why we think it’s necessary to keep A2 in the same process which loaded A1.

For this reason, in order to get Spectre protection for your website in a browser which doesn’t support process isolation at frame / window proxy level, websites MUST not have any document which gets loaded inside a cross-origin iframe and MUST set Cross-Origin-Isolate: 1 on every document in the origin which has a secret to protect.

> Let's say now a.com is navigated to some other page B2 in b.com. In this case, the browser finds the process which loaded B1 and load B2 in the same process so that they can talk to one another via window proxies.
>
> Yes. Quick note on Chrome's approach-- we would put B1 and B2 in the same b.com process, but only if they were part of the same "unit of related browsing contexts" (which we call BrowsingInstance). That way, all b.com tabs don't end up in the same process, which gets unusable with a large number of b.com tabs. (Incidentally, this is why we call our policy "one site per process" instead of "process per site." There can be more than one process for a given site.)

Sure, we have a slightly different idea on how to decide when & when not to start a new process but that’s totally possible with the proposed API.

- R. Niwa

[Mike West]

Hi, Ryosuke!

WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable

 I'm curious about some of the mechanics you've chosen, though:

1.  Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.

2.  Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.

3.  Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.

Thanks for poking at this!

-mike

[Ryosuke Niwa]

On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:

WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable

 I'm curious about some of the mechanics you've chosen, though:

1.  Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.

We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.

2.  Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.

That's certainly a consideration. We can always add those options later though.

3.  Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.

We don't want to support postMessage since it would be odd to support postMessage to a closed window.

On May 2, 2018, at 7:24 AM, Andy Paicu <andy...@google.com> wrote:

Apart from Mike's questions above I would also like to bring out one particular point:

4. What happens if a.com uses the b.com window handle, before b.com has loaded, to (for example) create a function in the b.com window that will execute after b.com loads? Something similar happens when b.com in sandboxed using the CSP header but since there was no way to tell immediately that the opened windows is sandboxed (or in this case that Cross-Origin-Isolate is '1') the opener could still do stuff with the handle before it becomes isolated/sandboxed. Here is a more detailed example of what I mean: 377995

I do not have the permission to see that bug. It would be helpful if you can send us a copy offline.

- R. Niwa

[Mike West]

Hey Ryosuke, thanks for the response!

On Thu, May 3, 2018 at 11:14 AM Ryosuke Niwa <rn...@apple.com> wrote:

On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:

WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable

 I'm curious about some of the mechanics you've chosen, though:

1.  Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.

We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.

General compatibility with the status-quo seems like less of a concern if this is an opt-in mechanism, doesn't it?

2.  Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.

That's certainly a consideration. We can always add those options later though.

3.  Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.

We don't want to support postMessage since it would be odd to support postMessage to a closed window.

Understood. If you have a few minutes to skim through the thread I linked above, it might help clarify the kinds of use cases that folks were interested in. As an example, it's not clear to me how OAuth flows which require tokens to be passed around would be possible in the model where neither `postMessage()` nor `window.location` on `window.opener` were functional.

-mike

[Chris Dumez]

On May 3, 2018, at 5:58 AM, Mike West <mk...@chromium.org> wrote:

On Thu, May 3, 2018 at 11:14 AM Ryosuke Niwa <rn...@apple.com> wrote:

On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:

WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable

 I'm curious about some of the mechanics you've chosen, though:

1.  Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.

We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.

General compatibility with the status-quo seems like less of a concern if this is an opt-in mechanism, doesn't it?

In this case though, the one adopting the header is the openee. The opener did not adopt the header and yet its handle to the opened window would start behaving in a new way.

[Nasko Oskov]

On Tue, May 1, 2018 at 7:22 PM Ryosuke Niwa <rn...@apple.com> wrote:

> On May 1, 2018, at 4:20 PM, Charlie Reis <cr...@chromium.org> wrote:
>
>
>
> On Tue, May 1, 2018 at 2:59 PM Ryosuke Niwa <rn...@apple.com> wrote:
>> Here’s a proposal for new header as I promised.
>>
>> Proposal
>>
>> Add HTTP header called Cross-Origin-Isolate, which takes a value of 0 and 1. When the HTTP response of a document contains Cross-Origin-Isolate header with its value set to 1, the document is said to be "isolated".
>>
>> Let document A and document B be cross-origin documents.
>>
>> If document B is “isolated”, then document B's window acts as if its browsing context has been discarded (i.e. as if window has been closed) to document A. Similarly, document A's window acts if its browsing context has been discarded to document B.
>>
>> That is, each document appears to one another if is the other document's frame/window to be closed. On same origin access, the header has no effect.
>>
>> Let's say document B opened document A via `window.open`. Then window proxy of document B in document A's global object looks as if document B has been closed. i.e. `window.closed` is true. Similarly, document B's `window.opener` is NOT null but looks closed as well (i.e. `window.opener.closed` is true).
>>
>> Let's say document A opened document A via `window.open`. In this case, window proxies in both documents behave exactly like in the previous case.
>>
>> Let's say document A has an iframe of a document B. Then iframe's `contentWindow` in document A looks like closed; i.e. `iframe.contentWindow.closed` is true. Because it's cross-origin, `iframe.contentDocument` is null. Similarly, `window.parent` in document B looks as if "closed" with `window.closed` set to true. Note that `parent != self` is still true.
>>
>> Spectre Protection Plan
>>
>> For the purpose of protecting a website a.com from Spectre in browsers which support process swap for top-level navigations without cross-process window proxy support, a.com can set this header on all of its documents (not setting on some would result in leaks; more on this later).
>>
>> If this header is set on a.com, we can swap process on cross-origin navigation from or to a.com's documents because this guarantees that a.com doesn't have access to any other document outside of its origin, and vice versa.
>>
>> Let's say we're on some page B1 in b.com, and it window.open'ed (isolated) a.com. Then b.com doesn't have access to a.com, and b.com doesn't have access to a.com so we can put them into different processes. Obviously, a.com's iframes don't have access to b.com's frame tree either so if Facebook is currently relying on being able to do this, they won't be able to use this header.
>
> What about the case where B iframes A and A opens a popup (e.g., the OAuth case)?  More specifically, document B1 in b.com iframes document A1 on (isolated) a.com.  As described, B1 and A1 act like they're not in the same frame tree.  However, when the user clicks on the login button in A1, A1 opens a top-level popup to document A2 on a.com.  Would A2 go into a new process for a.com based on the rules above?

No. In this case, the process which loaded B1 and A1 would also load A2 (in a new window).

> In that case, A1 and A2 couldn't script each other, even though the window.closed rules don't seem to apply in the same-origin case.

Right. This is why we think it’s necessary to keep A2 in the same process which loaded A1.

For this reason, in order to get Spectre protection for your website in a browser which doesn’t support process isolation at frame / window proxy level, websites MUST not have any document which gets loaded inside a cross-origin iframe and MUST set Cross-Origin-Isolate: 1 on every document in the origin which has a secret to protect.

Can we clarify what is in the set of "secret to protect"? Obviously any data in the document itself, but I assume we include cookies and HTML5 storage in that set, correct? A document served without the header on a site, which serves other documents *with* the header, must only use http-only cookies and must never access HTML5 storage. Otherwise the data is given to the renderer process accessing it and attacker can freely iframe such a document without the header and get the sensitive data into the process to attack it.

 

> Let's say now a.com is navigated to some other page B2 in b.com. In this case, the browser finds the process which loaded B1 and load B2 in the same process so that they can talk to one another via window proxies.
>
> Yes.  Quick note on Chrome's approach-- we would put B1 and B2 in the same b.com process, but only if they were part of the same "unit of related browsing contexts" (which we call BrowsingInstance).  That way, all b.com tabs don't end up in the same process, which gets unusable with a large number of b.com tabs.  (Incidentally, this is why we call our policy "one site per process" instead of "process per site."  There can be more than one process for a given site.)

Sure, we have a slightly different idea on how to decide when & when not to start a new process but that’s totally possible with the proposed API.

- R. Niwa

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/2F75B47A-E329-4851-8CF0-8C83046D14D1%40apple.com.

[Ryosuke Niwa]

> On May 3, 2018, at 1:58 PM, Nasko Oskov <na...@chromium.org> wrote:
>
> On Tue, May 1, 2018 at 7:22 PM Ryosuke Niwa <rn...@apple.com> wrote:
>>
>> > On May 1, 2018, at 4:20 PM, Charlie Reis <cr...@chromium.org> wrote:
>> >
>> >
>> >
>> > On Tue, May 1, 2018 at 2:59 PM Ryosuke Niwa <rn...@apple.com> wrote:
>> >> Here’s a proposal for new header as I promised.
>> >>
>> >> Proposal
>> >>
>> >> Add HTTP header called Cross-Origin-Isolate, which takes a value of 0 and 1. When the HTTP response of a document contains Cross-Origin-Isolate header with its value set to 1, the document is said to be "isolated".
>> >>
>> >> Let document A and document B be cross-origin documents.
>> >>
>> >> If document B is “isolated”, then document B's window acts as if its browsing context has been discarded (i.e. as if window has been closed) to document A. Similarly, document A's window acts if its browsing context has been discarded to document B.
>> >>
>> >> That is, each document appears to one another if is the other document's frame/window to be closed. On same origin access, the header has no effect.
>> >>
>> >> Let's say document B opened document A via `window.open`. Then window proxy of document B in document A's global object looks as if document B has been closed. i.e. `window.closed` is true. Similarly, document B's `window.opener` is NOT null but looks closed as well (i.e. `window.opener.closed` is true).
>> >>
>> >> Let's say document A opened document A via `window.open`. In this case, window proxies in both documents behave exactly like in the previous case.
>> >>
>> >> Let's say document A has an iframe of a document B. Then iframe's `contentWindow` in document A looks like closed; i.e. `iframe.contentWindow.closed` is true. Because it's cross-origin, `iframe.contentDocument` is null. Similarly, `window.parent` in document B looks as if "closed" with `window.closed` set to true. Note that `parent != self` is still true.
>> >>
>> >> Spectre Protection Plan
>> >>
>> >> For the purpose of protecting a website a.com from Spectre in browsers which support process swap for top-level navigations without cross-process window proxy support, a.com can set this header on all of its documents (not setting on some would result in leaks; more on this later).
>> >>
>> >> If this header is set on a.com, we can swap process on cross-origin navigation from or to a.com's documents because this guarantees that a.com doesn't have access to any other document outside of its origin, and vice versa.
>> >>
>> >> Let's say we're on some page B1 in b.com, and it window.open'ed (isolated) a.com. Then b.com doesn't have access to a.com, and b.com doesn't have access to a.com so we can put them into different processes. Obviously, a.com's iframes don't have access to b.com's frame tree either so if Facebook is currently relying on being able to do this, they won't be able to use this header.
>> >
>> > What about the case where B iframes A and A opens a popup (e.g., the OAuth case)? More specifically, document B1 in b.com iframes document A1 on (isolated) a.com. As described, B1 and A1 act like they're not in the same frame tree. However, when the user clicks on the login button in A1, A1 opens a top-level popup to document A2 on a.com. Would A2 go into a new process for a.com based on the rules above?
>>
>> No. In this case, the process which loaded B1 and A1 would also load A2 (in a new window).
>>
>> > In that case, A1 and A2 couldn't script each other, even though the window.closed rules don't seem to apply in the same-origin case.
>>
>> Right. This is why we think it’s necessary to keep A2 in the same process which loaded A1.
>>
>> For this reason, in order to get Spectre protection for your website in a browser which doesn’t support process isolation at frame / window proxy level, websites MUST not have any document which gets loaded inside a cross-origin iframe and MUST set Cross-Origin-Isolate: 1 on every document in the origin which has a secret to protect.
>
> Can we clarify what is in the set of "secret to protect"? Obviously any data in the document itself, but I assume we include cookies and HTML5 storage in that set, correct?

Yes, includes every cookie, session storage, local storage, indexedDB, etc...

> A document served without the header on a site, which serves other documents *with* the header, must only use http-only cookies and must never access HTML5 storage.

Right. In fact, in most websites which uses HTML5 storages or non-HTTP-only cookies must set Cross-Origin-Isolate: 1 on every document. Otherwise, the website is vulnerable to Spectre attacks.

- R. Niwa

[Ryosuke Niwa]

On May 3, 2018, at 05:58, Mike West <mk...@chromium.org> wrote:

> Hey Ryosuke, thanks for the response!
>
> On Thu, May 3, 2018 at 11:14 AM Ryosuke Niwa <rn...@apple.com> wrote:
>>> On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:
>>>
>>> WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable
>>>
>>> I'm curious about some of the mechanics you've chosen, though:
>>>
>>> 1. Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.
>>
>> We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.
>
> General compatibility with the status-quo seems like less of a concern if this is an opt-in mechanism, doesn't it?

Well, the problem here is that the websites affected by window proxy being undefined, etc... are not the one who opted to use set header but rather the one who opened it.

Consider a following scenario. schwab.com page S1 opens a new window W1 to show the details of a stock in page S2. It has a link to morningstar.com's page M1 for a rating. The user opens it, and morningstar.com responds with Cross-Origin-Isolate. W1 loads M1 in W1 after swapping the process.

Now, the user clicks on another stock in schwab.com S1 and S1 tries to navigate W1 to another page S3. If W1's window proxy in S1 had become "undefined", then the script in S1 would fail and the stock detail won't be shown. However, S1's code must be resilient against W1 getting closed since that's already possible today.

>
>>> 2. Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.
>>
>> That's certainly a consideration. We can always add those options later though.
>>
>>> 3. Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.
>>
>> We don't want to support postMessage since it would be odd to support postMessage to a closed window.
>
> Understood. If you have a few minutes to skim through the thread I linked above, it might help clarify the kinds of use cases that folks were interested in. As an example, it's not clear to me how OAuth flows which require tokens to be passed around would be possible in the model where neither `postMessage()` nor `window.location` on `window.opener` were functional.

The way we imagine OAuth providers can support this work flow is as follows:
1. a.com page A1 in a window W1 opens OAuth page O1 in a separate window W2
2. OAuth serves O1 with Cross-Origin-Isolate header set; so browser would load the page in a new process.
3. O1 upon completing the login would navigate W2 back to another page A2 in a.com with authentication token passed to A2 via URL.
4. A2 in W2 communities back to A1 in W1.

- R. Niwa

[Artur Janc]

On Thu, May 3, 2018 at 11:14 AM Ryosuke Niwa <rn...@apple.com> wrote:

On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:

WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable

 I'm curious about some of the mechanics you've chosen, though:

1.  Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.

We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.

2.  Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.

That's certainly a consideration. We can always add those options later though.

3.  Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.

We don't want to support postMessage since it would be odd to support postMessage to a closed window.

First of all, thanks for thinking about this, Ryosuke! Giving applications the ability to break cross-origin window references seems valuable and came up in the past in the disown-opener discussion Mike mentioned, and as part of the Isolation proposal. It would be great to have something to help with this problem!

 

That said, breaking cross-origin postMessage would make this all but unadoptable in almost any realistic application because postMessage is the mechanism of choice to allow safe interactions between cross-origin content. In particular, I believe adopting the proposal in its current shape would break all Google applications, the vast majority of JS APIs (e.g. ReCAPTCHA, Twitter/FB/G+ embeds, A/B testing services such as Optimizely, ads, etc.) and would affect functionality on almost all popular sites. To gather some data, I wrote a small Chrome extension to log cross-origin postMessages and used it on the Alexa top 10 non-Google sites; with the exception of Wikipedia, every one of them resulted in a cross-origin postMessage within one or two clicks from the main page (as a further bit of anecdata, so did all 3 of the bank websites I use). In practice this means that most developers couldn't adopt the header without first significantly rearchitecting their applications.

I see two ways of solving this in your proposal:

1. Disable direct cross-origin DOM access, but have an exception for postMessage. There seems to be little downside of doing so.

2. Instead of a binary isolate / no-isolate flag, allow developers to provide a whitelist of origins which would be allowed to interact with the window. This would make it possible to bless origins hosting the application's JS dependencies to interact with the window, but would likely be more cumbersome to adopt and maintain, similarly to the issues we've seen with script-src in CSP. 

I think that if we find a way to enable postMessage, this will likely be practical to adopt fairly broadly.

Cheers,

-Artur

[Ryosuke Niwa]

> On May 6, 2018, at 8:59 AM, Artur Janc <a...@google.com> wrote:
>
> On Thu, May 3, 2018 at 11:14 AM Ryosuke Niwa <rn...@apple.com> wrote:
>>
>>
>>> On May 2, 2018, at 12:14 AM, Mike West <mk...@chromium.org> wrote:
>>>
>>> WebAppSec has been kicking around something vaguely similar for way too long now, so I'm excited about getting something hammered out together (see https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html for some earlier thoughts). I think the general idea of blocking access to cross-origin properties by modifying the behavior of `WindowProxy` is pretty reasonable
>>>
>>> I'm curious about some of the mechanics you've chosen, though:
>>>
>>> 1. Why pretend that the window is closed, rather than (for example) throwing `SecurityError` or returning `undefined` on cross-origin access to `WindowProxy` properties (e.g. by modifying https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty and/or https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-)). It seems like we'd end up needing to mutate that value back and forth as the browsing context navigated from documents that asked for isolation to documents that didn't, which seems strange.
>>
>> We could consider those options but pretending to be closed seems like the most web compatible option since websites would already have to deal with a closed window.
>>
>>> 2. Is `Cross-Origin` enough? I can imagine cases where applications on `x.example.com` and `y.example.com` need to talk to each other in some way to perform some action. It's certainly the simplest place to start, but I wonder if we need/want a site-based model for folks to opt-into.
>>
>> That's certainly a consideration. We can always add those options later though.
>>
>>> 3. Do you want to carve out an exception for `postMessage()`? We went back and forth on this a bit in the thread linked above, and some folks (like Artur. Hi, Artur!) had strong feelings about the distinction between my opener talking to me, and me talking to my openees.
>>
>> We don't want to support postMessage since it would be odd to support postMessage to a closed window.
>
> First of all, thanks for thinking about this, Ryosuke! Giving applications the ability to break cross-origin window references seems valuable and came up in the past in the disown-opener discussion Mike mentioned, and as part of the Isolation proposal. It would be great to have something to help with this problem!
>
> That said, breaking cross-origin postMessage would make this all but unadoptable in almost any realistic application because postMessage is the mechanism of choice to allow safe interactions between cross-origin content. In particular, I believe adopting the proposal in its current shape would break all Google applications, the vast majority of JS APIs (e.g. ReCAPTCHA, Twitter/FB/G+ embeds, A/B testing services such as Optimizely, ads, etc.) and would affect functionality on almost all popular sites. To gather some data, I wrote a small Chrome extension to log cross-origin postMessages and used it on the Alexa top 10 non-Google sites; with the exception of Wikipedia, every one of them resulted in a cross-origin postMessage within one or two clicks from the main page (as a further bit of anecdata, so did all 3 of the bank websites I use). In practice this means that most developers couldn't adopt the header without first significantly rearchitecting their applications.
>
> I see two ways of solving this in your proposal:
> 1. Disable direct cross-origin DOM access, but have an exception for postMessage. There seems to be little downside of doing so.
> 2. Instead of a binary isolate / no-isolate flag, allow developers to provide a whitelist of origins which would be allowed to interact with the window. This would make it possible to bless origins hosting the application's JS dependencies to interact with the window, but would likely be more cumbersome to adopt and maintain, similarly to the issues we've seen with script-src in CSP.
>
> I think that if we find a way to enable postMessage, this will likely be practical to adopt fairly broadly.

We still see a huge value in the completely isolated model because having to check the source of origin whenever processing a post message is not a great security model (i.e. postMessage has a similar issue as CSRF in HTTP). But given your strong preference (assuming this is Google’s position in general), here’s a compromise we can make:

1. Make "Cross-Origin-Isolate” take one of: yes, no, and yesExceptPostMessage.
2. Make window proxy with "Cross-Origin-Isolate” value of “yes” and “yesExceptPostMessage" throw a SecurityError like other cross-origin checks.

We still think (2) is risker than pretending it to be closed in terms of Web compatibility but it’s probably a behavior we can try implementing it.

Note that supporting postMessage across processes would require a significantly more engineering work in our end but we still think it’s valuable to have this feature before we can have frame level process isolation.

Folks from Mozilla & Microsoft, can you support this modified proposal (with postMessage across processes) before you’d be able to support process boundary at frame granularity?

- R. Niwa

[Geoffrey Garen]

> 1. Make "Cross-Origin-Isolate” take one of: yes, no, and yesExceptPostMessage.

How about calling these

Cross-Origin-Options: ALLOW
Cross-Origin-Options: ALLOW-POST-MESSAGE
Cross-Origin-Options: DENY

This matches the naming of X-Frame-Options, avoids the double negative of “do not allow access, not including postMessage”, and makes the header more scalable to future changes, if we need them.

Thanks,
Geoff

[Artur Janc]

I think this is reasonable (possibly with the spelling suggested by Geoff, which seems cleaner). 

Note that I'm not really attempting to defend the postMessage security model, just observing the fact that applications routinely send messages to cross-origin windows. If we want developers to enable the restrictions you propose -- and hence make it possible to protect their applications from Spectre in browsers without OOPIFs, which seems like a worthy goal -- then we should make provisions for such real-world behaviors. Otherwise we're likely to end up with mechanisms that may be conceptually simpler but will have marginal value due to limited adoption.

Cheers,

-Artur

[Chris Palmer]

Hi all,

Sorry I've been AWOL lately; super busy with other (related and unrelated) stuff. Broadly, here are some thoughts:

* I agree with Artur that we really need to enable postMessage to keep working, at least as an option. I think the extra work will pay off in increased adoption.

* There's Geoff's spelling of the options, which is good. But what about *site* vs. *origin*? It might (?) be helpful to allow a service to tighten itself at either level of granularity, as well.

* Why do we need a "0" or "DENY" setting? Just not setting the response header would have the same effect, right?

* The requirement that a site/origin set the header on every response seems error-prone. Could we use a .well-known URL instead? I guess this re-raises the issue that the Isolation proposal had, of needing to depend on/wait for Origin Policy, which is perhaps undesirable.

[Geoffrey Garen]

> * Why do we need a "0" or "DENY" setting? Just not setting the response header would have the same effect, right?

For web compatibility, the default setting is the status quo, which is ALLOW.

Geoff

[Chris Palmer]

On Mon, May 7, 2018 at 5:22 PM Geoffrey Garen <gga...@apple.com> wrote:

> * Why do we need a "0" or "DENY" setting? Just not setting the response header would have the same effect, right?

For web compatibility, the default setting is the status quo, which is ALLOW.

Err, wait. Maybe that's what I meant. :) Do we need ALLOW, then? 

[Geoffrey Garen]

> * Why do we need a "0" or "DENY" setting? Just not setting the response header would have the same effect, right?

For web compatibility, the default setting is the status quo, which is ALLOW.

Err, wait. Maybe that's what I meant. :) Do we need ALLOW, then? 

I can’t imagine anyone ever sending the ALLOW value. But the concept of the ALLOW value / state seems useful for specifying the default behavior.

Geoff

[Ryosuke Niwa]

On May 7, 2018, at 5:00 PM, Chris Palmer <pal...@chromium.org> wrote:

Sorry I've been AWOL lately; super busy with other (related and unrelated) stuff. Broadly, here are some thoughts:

* I agree with Artur that we really need to enable postMessage to keep working, at least as an option. I think the extra work will pay off in increased adoption.

Okay, I think this is taken care of by the latest proposal.

* There's Geoff's spelling of the options, which is good. But what about *site* vs. *origin*? It might (?) be helpful to allow a service to tighten itself at either level of granularity, as well.

What are examples of websites that need same-site access beyond postMessage?  Note that browsers don’t currently allow cross-origin same-site accessing of DOM other than things like window.location.  Or are you thinking of restricting postMessage to same-site as opposed to all cross-origin usage?

* Why do we need a "0" or "DENY" setting? Just not setting the response header would have the same effect, right?

Well, the default behavior / what browser currently supports is Cross-Origin-Options: ALLOW.

* The requirement that a site/origin set the header on every response seems error-prone. Could we use a .well-known URL instead? I guess this re-raises the issue that the Isolation proposal had, of needing to depend on/wait for Origin Policy, which is perhaps undesirable.

I thought we had a rough consensus to not block this header on that proposal in the last F2F in Mountain View?

- R. Niwa

[Artur Janc]

Putting my author hat on, I would prefer to have this feature enabled at the response level as currently proposed. An origin-wide switch is more comprehensive, but also much trickier to adopt because it may accidentally affect the behavior of unrelated services hosted in the same origin. A per-response header also allows progressive adoption where each service can set the header on its own responses without blocking on all code in the origin being compatible with isolation.

Long-term, the right model for such features is likely to complement response-level enforcement with an origin-wide switch in the Origin Policy, which would protect responses where the developer forgot to set the header. But my guess is that even when OP is supported by all browsers developers might still want to start with the header-based approach when deploying this in existing applications because it's less likely to lead to surprises (though completely new code could probably rely on OP).

Cheers,

-Artur

[Stephen Röttger]

Navigation Prevention?

One possible addition to this feature might be to prevent all types of navigations. With what we proposed above, it's already the case that an isolated document's location object itself is inaccessible but documents with a window proxy to an isolated document can still navigate it via `iframe.src` or `window.open`. In particular, named frame navigation triggered by anchor element with a named target and/or `window.open` would still navigate the "isolated" document. We can prevent these navigations as well if we wanted. e.g. excluding "isolated" document's frame when choosing a browing context for the target (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name)

I'm currently trying to find a good way to mitigate XS-Search attacks and Artur pointed me to this proposal.

If it's possible then I'd like to ask to add the navigation prevention as it would be very helpful to protect against XS-Search.

There's an open problem with many search handlers that even though the search endpoints themselves require an XSRF token, they can still be triggered through a top-level navigation. This leaks if there was a result or not (via size and/or timing side channels).

Being able to prevent navigation like this would require the attacker to get a click for every request to the search endpoint and thereby make the attack infeasible.

[Chris Dumez]

On May 17, 2018, at 8:42 AM, 'Stephen Röttger' via isolation-policy <isolatio...@chromium.org> wrote:

I'm currently trying to find a good way to mitigate XS-Search attacks and Artur pointed me to this proposal.

If it's possible then I'd like to ask to add the navigation prevention as it would be very helpful to protect against XS-Search.

Agreed, I believe this should the Cross-Origin-Options header should prevent navigations when value is “deny” or “allow-postmessage”.

One way to do this would be to add a check for the Cross-Origin-Options header to HTML’s allowed to navigate [1] (code example / tests in WebKit: [2]).

[1] https://html.spec.whatwg.org/#allowed-to-navigate

[2] https://bugs.webkit.org/show_bug.cgi?id=185681

--

 Chris Dumez

[Geoffrey Garen]

I'm currently trying to find a good way to mitigate XS-Search attacks and Artur pointed me to this proposal.

If it's possible then I'd like to ask to add the navigation prevention as it would be very helpful to protect against XS-Search.

Agreed, I believe this should the Cross-Origin-Options header should prevent navigations when value is “deny” or “allow-postmessage”.

I agree too.

Preventing navigation by window.location while allowing navigation by target would be inconsistent, and a clear hole in the integrity of the targeted page.

Geoff

[Chris Dumez]

After some internal discussion, we’d like to propose the name ‘Cross-Origin-Window-Policy’ instead of ‘Cross-Origin-Options’. We think the previous name was too generic for a HTTP header which applies to HTML Windows. We also think ‘policy’ is more specific than ‘options’ as something that is enforced.

Values would remain [allow | allow-postmessage | deny ].

Any thoughts on this?

--

 Chris Dumez

[Chris Dumez]

Hi all,

I am still awaiting feedback on the new naming proposal ("Cross-Origin-Window-Policy”).

--

 Chris Dumez

[Mike West]

Hi, folks. (And sorry if you get this twice, I sent from the wrong email account initially...)

I apologize, as I think I conflated this with the other `Cross-Origin-etc-thing` thread on GitHub. Personally, I think the general direction is a good one, and I think there's value in the mechanism above and beyond Spectre mitigation (I know, for instance, that `doubleclick.net` frames are very interested in preventing other `doubleclick.net` frames from poking at them).

It would be helpful to me if someone could summarize the conclusions from this thread into a short document we could skim through together to make sure that I understand where things ended up. I'm not sure about some of the details discussed above (navigation blocking, for instance, might be valuable as a xs-search mitigation, but might also reduce the value for use cases like the ad frame isolation hand-waved at above). Spelling out the details would ensure that we're not accidentally talking past each other.

sroettger@: Would `sec-metadata` (https://github.com/mikewest/sec-metadata) address some of the uses you have for navigation blocking? I wonder if that's a better primitive to rely upon here.

-mike

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/7AB92247-CBA3-4ACC-808A-9C0DAE2B1C88%40apple.com.

[Stephen Röttger]

On Wed, May 30, 2018 at 7:43 AM Mike West <mk...@chromium.org> wrote:

Hi, folks. (And sorry if you get this twice, I sent from the wrong email account initially...)

I apologize, as I think I conflated this with the other `Cross-Origin-etc-thing` thread on GitHub. Personally, I think the general direction is a good one, and I think there's value in the mechanism above and beyond Spectre mitigation (I know, for instance, that `doubleclick.net` frames are very interested in preventing other `doubleclick.net` frames from poking at them).

It would be helpful to me if someone could summarize the conclusions from this thread into a short document we could skim through together to make sure that I understand where things ended up. I'm not sure about some of the details discussed above (navigation blocking, for instance, might be valuable as a xs-search mitigation, but might also reduce the value for use cases like the ad frame isolation hand-waved at above). Spelling out the details would ensure that we're not accidentally talking past each other.

sroettger@: Would `sec-metadata` (https://github.com/mikewest/sec-metadata) address some of the uses you have for navigation blocking? I wonder if that's a better primitive to rely upon here.

The only difference I can think of is the point jannh brought up. sec-metadata would still allow you to change the hash of the window since it will not trigger a page load. If the website is designed to search based on hash changes they would still be vulnerable (gmail is doing this atm).

[Artur Janc]

On Wed, May 30, 2018 at 8:44 AM Stephen Röttger <sroe...@google.com> wrote:

On Wed, May 30, 2018 at 7:43 AM Mike West <mk...@chromium.org> wrote:

Hi, folks. (And sorry if you get this twice, I sent from the wrong email account initially...)

I apologize, as I think I conflated this with the other `Cross-Origin-etc-thing` thread on GitHub. Personally, I think the general direction is a good one, and I think there's value in the mechanism above and beyond Spectre mitigation (I know, for instance, that `doubleclick.net` frames are very interested in preventing other `doubleclick.net` frames from poking at them).

It would be helpful to me if someone could summarize the conclusions from this thread into a short document we could skim through together to make sure that I understand where things ended up. I'm not sure about some of the details discussed above (navigation blocking, for instance, might be valuable as a xs-search mitigation, but might also reduce the value for use cases like the ad frame isolation hand-waved at above). Spelling out the details would ensure that we're not accidentally talking past each other.

sroettger@: Would `sec-metadata` (https://github.com/mikewest/sec-metadata) address some of the uses you have for navigation blocking? I wonder if that's a better primitive to rely upon here.

The only difference I can think of is the point jannh brought up. sec-metadata would still allow you to change the hash of the window since it will not trigger a page load. If the website is designed to search based on hash changes they would still be vulnerable (gmail is doing this atm).

I expect navigation blocking to be more difficult to implement via Sec-Metadata because the developer would need to either completely disable cross-origin navigation requests to a given endpoint, or enumerate the set of origins which can perform such navigations. When it comes to the complexity of policing cross-origin relationships, the order of difficulty is, roughly: [easiest] framing -> CORS -> no-cors resource loads -> navigation [hardest], so I expect navigations would take more work than the base case of allowing only same-origin/same-site subresource requests.

OTOH, with this proposal, many applications could likely just set `Cross-Origin-Window-Policy: allow-postmessage` without requiring extensive changes, other than opting into cross-origin navigations in the rare places where this is needed, which they could do via postMessage. 

What I imagine to work well (against XS-Search, among other attacks) is a combination of Sec-Metadata to protect against timing attacks via loading a given endpoint as a frame or subresource, and via Cross-Origin-Window-Policy against similar attacks using top-level navigations. This could still leak size information to local network attackers if the attack uses top-level navigations, but IIUC it would require opening a new window for each bit of exfiltrated data, which would constrain most attacks; for particularly sensitive endpoints developers could still use Sec-Metadata to police navigations at the cost of needing to do more work. 

A side benefit of the Sec-Metadata + Cross-Origin-Window-Policy combo is that setting the COWP response header could be a signal to the browser to enable process-based isolation, as Ryosuke outlined in his original proposal.

Cheers,

-Artur

[Ryosuke Niwa]

Hi all,

Thanks all for the invaluable feedback.

I’ve posted a revised proposal on https://github.com/whatwg/html/issues/3740 so let’s continue the discussion there.

- R. Niwa