Intent to Ship Cross-Origin-Opener-Policy
Camille Lamy
Contact emails
cl...@chromium.org, pmeu...@chromium.org, ahe...@chromium.org
Explainer
Spec
Link to spec draft (by Mozilla).
Summary
At least two types of attacks are possible when a document shares a browsing context group and process with cross-origin documents:
1) Cross-window attacks. For example, a malicious document may open a victim document in a new window and later navigate the window to a look-alike document to trick the user.
2) Process-wide attacks. Transient execution attacks like Spectre allow a malicious document to leak data from a victim document, if they share an OS process.
In browsers with full Site Isolation and out-of-process iframes, it is possible to mitigate process-wide attacks by putting documents from different sites in different processes. Cross-window attacks are less severe than process-wide attacks, but still remain possible in such browsers.
In browsers without out-of-process iframes, it is difficult to put cross-origin documents in a different process if they are in the same browsing context group, without breaking script interactions between same-origin popups and iframes.
We want to give sites the ability to sever all references to other browsing contexts to mitigate cross-window attacks, and to make it easier for browsers without out-of-process iframes to load the victim document in a new OS process to mitigate process-wide attacks like Spectre.
Intent to implement
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
We support Windows, Mac, Linux, Chrome OS and Android.
On Android WebView, we could ship the feature but we would not allow additional APIs to be enabled unless we make significant changes to the process model. So at the beginning, we will not ship on Android WebView.
Debuggability
We have been working with the DevTools team to add support to DevTools for debugging COOP (and COEP).
Risks
Interoperability and Compatibility
In browsers that do not support the header, documents will not get the level of isolation they expect.
Firefox: Shipping in Firefox 67 (https://bugzilla.mozilla.org/show_bug.cgi?id=1521808)
Edge: No public signals
Safari: Public support (https://github.com/whatwg/html/issues/3740#issuecomment-443008140)
Safari 12 shipped an earlier version ("cross-origin-window-policy"), per https://developer.apple.com/safari/whats-new/.
Web developers: No signals
Ergonomics
This header will often be used in tandem with Cross-Origin-Resource-Policy (https://www.chromestatus.com/features/4647328103268352) to prevent subresources from entering other renderer processes, as well as Cross-Origin-Embedder-Policy (https://github.com/whatwg/html/issues/4175) to enable precise timers and memory measurements.
When deploying this header, web developers may need to be careful not to break their existing uses of cross-window scripting after window.open calls. We plan to follow-up with a reporting API, including report-only mode, to help developers deploy this policy.
Activation
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
The feature is fully tested by the web-platform tests html/cross-origin-opener-policy test suite. The test suite results can be found here. Note that we're still waiting on two CLs (1, 2) to land to fully pass the tests (except for blob URLs which are to be implemented later).
Entry on the feature dashboard
https://www.chromestatus.com/features/5432089535053824
Yoav Weiss
Contact emails
cl...@chromium.org, pmeu...@chromium.org, ahe...@chromium.org
Explainer
Spec
Link to spec draft (by Mozilla).
Summary
At least two types of attacks are possible when a document shares a browsing context group and process with cross-origin documents:
1) Cross-window attacks. For example, a malicious document may open a victim document in a new window and later navigate the window to a look-alike document to trick the user.
2) Process-wide attacks. Transient execution attacks like Spectre allow a malicious document to leak data from a victim document, if they share an OS process.
In browsers with full Site Isolation and out-of-process iframes, it is possible to mitigate process-wide attacks by putting documents from different sites in different processes. Cross-window attacks are less severe than process-wide attacks, but still remain possible in such browsers.
In browsers without out-of-process iframes, it is difficult to put cross-origin documents in a different process if they are in the same browsing context group, without breaking script interactions between same-origin popups and iframes.
We want to give sites the ability to sever all references to other browsing contexts to mitigate cross-window attacks, and to make it easier for browsers without out-of-process iframes to load the victim document in a new OS process to mitigate process-wide attacks like Spectre.
Intent to implement
Discussed here.Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
We support Windows, Mac, Linux, Chrome OS and Android.
On Android WebView, we could ship the feature but we would not allow additional APIs to be enabled unless we make significant changes to the process model. So at the beginning, we will not ship on Android WebView.
Debuggability
We have been working with the DevTools team to add support to DevTools for debugging COOP (and COEP).
Risks
Interoperability and Compatibility
In browsers that do not support the header, documents will not get the level of isolation they expect.
Edge: No public signals
Safari: Public support (https://github.com/whatwg/html/issues/3740#issuecomment-443008140)
Safari 12 shipped an earlier version ("cross-origin-window-policy"), per https://developer.apple.com/safari/whats-new/.
Web developers: No signals
Ergonomics
This header will often be used in tandem with Cross-Origin-Resource-Policy (https://www.chromestatus.com/features/4647328103268352) to prevent subresources from entering other renderer processes, as well as Cross-Origin-Embedder-Policy (https://github.com/whatwg/html/issues/4175) to enable precise timers and memory measurements.
When deploying this header, web developers may need to be careful not to break their existing uses of cross-window scripting after window.open calls. We plan to follow-up with a reporting API, including report-only mode, to help developers deploy this policy.
Activation
No polyfill should be needed, since this is a security feature that only restricts page behavior and doesn't add new capabilities on its own.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
The feature is fully tested by the web-platform tests html/cross-origin-opener-policy test suite. The test suite results can be found here. Note that we're still waiting on two CLs (1, 2) to land to fully pass the tests (except for blob URLs which are to be implemented later).
Entry on the feature dashboard
https://www.chromestatus.com/features/5432089535053824
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvpPUZux-6%3D2QzFKjCkOrSSAbyKs%2B9sFO2xbsLEi0annng%40mail.gmail.com.
Boris Zbarsky
> Firefox: Shipping in Firefox 67
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1521808)
not shipped to release yet, as of Firefox 73.
-Boris
Yoav Weiss
-Boris
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bece355a-1378-9deb-b310-451cd98329e4%40mit.edu.
Boris Zbarsky
> Any particular reason why this hasn't shipped in the last 6 releases?
> Any public plans on when it'd ship?
closely recently and he has.
> Otherwise, can we deduce Mozilla support from the fact it's implemented
> and enabled in nightlies?
-Boris
Nicolás Peña
Mike West
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15c80697-ce12-48ae-943d-b01e8db84d93%40chromium.org.
Jochen Eisinger
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dep-dGezE5AA5991YD3AoYUtGi2WBAms4eO46q-Tx5NJQ%40mail.gmail.com.
Yoav Weiss
I've been quite involved in the conversations around both COOP and COEP (in collaboration with folks like Anne at Mozilla). Given my involvement, I'll abstain (but LGTM0, and I'd strongly encourage us to ship both).I agree that there's some specification work to hammer out, but I'd also note that we have a fairly solid test suite that's been built with the support of Google, Mozilla, and Bocoup engineers. I think our interop story is good.To answer some of the questions raised above:1. What does Mozilla think about this?I'll defer to Anne, but I would note that Mozilla's public statements on COOP are wrapped up in their broader statements around SharedArrayBuffer restrictions at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes. IMO, they're clearly positive and express an intent to ship.2. What's the level of risk with regards to naming? Would better names result in header name changes and developer-exposed churn?I've been convinced that we shouldn't rename them at this point. We've invested a bit in beginning to educate developers around COOP requirements for SharedArrayBuffer and other interesting APIs (which, to be clear, this Intent does not yet implement: we want to ship COOP first, then start locking APIs behind it in a future intent/deprecation process).
3. Do you expect compat concerns from split support? Would Safari be willing to align? What should the developer advice be in the meantime? Send both headers?I think the original Intent is incorrect: I don't think Apple actually shipped `Cross-Origin-Window-Policy` to Safari. They implemented it in TP, and we continued iterating on the spec in the looooong conversation in https://github.com/whatwg/html/issues/3740. I don't think COWP is something that either Chromium or Mozilla is going to implement, and I'd hope that WebKit would align on what we ended up with.With regard to that willingness to align, Anne asked Apple explicitly for feedback in early January. I've pinged that thread. I'm hopeful that they'll get on board with the work Anne, et al. have done.4. Where's the TAG review?We didn't file one. I don't believe anyone at Mozilla or Apple did either. That's unfortunate! Still, given the close collaboration between Mozilla and Google, I hope we've covered enough of the bases here from a design perspective.That said, I did file a review request for the very-related Securer Contexts proposal that relies on COOP and COEP as underlying primitives. That's been sitting open for a little under a month at https://github.com/w3ctag/design-reviews/issues/471, currently scheduled for conversation in the TAG's F2F in March.
Yoav Weiss
Do we have plans to specify the feature? (perhaps as a separate document, similarly to https://github.com/mikewest/corpp/)It may not involve much more than throwing Anne's processing model as a separate document, but will enable e.g. keeping track of the document's history, opening issues and PRs on it, etc)Alternatively, maybe we want to turn it into an HTML PR? (if there's a good chance it'll land soonish)On Sun, Mar 1, 2020 at 5:28 PM Mike West <mk...@chromium.org> wrote:I've been quite involved in the conversations around both COOP and COEP (in collaboration with folks like Anne at Mozilla). Given my involvement, I'll abstain (but LGTM0, and I'd strongly encourage us to ship both).I agree that there's some specification work to hammer out, but I'd also note that we have a fairly solid test suite that's been built with the support of Google, Mozilla, and Bocoup engineers. I think our interop story is good.To answer some of the questions raised above:1. What does Mozilla think about this?I'll defer to Anne, but I would note that Mozilla's public statements on COOP are wrapped up in their broader statements around SharedArrayBuffer restrictions at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes. IMO, they're clearly positive and express an intent to ship.2. What's the level of risk with regards to naming? Would better names result in header name changes and developer-exposed churn?I've been convinced that we shouldn't rename them at this point. We've invested a bit in beginning to educate developers around COOP requirements for SharedArrayBuffer and other interesting APIs (which, to be clear, this Intent does not yet implement: we want to ship COOP first, then start locking APIs behind it in a future intent/deprecation process).Fair enough. Maybe a simple rebranding of the concepts (without changing any header names) would be sufficient to stop us from saying "coup" to mean either one of COOP or COEP, depending on the speaker's native language.3. Do you expect compat concerns from split support? Would Safari be willing to align? What should the developer advice be in the meantime? Send both headers?I think the original Intent is incorrect: I don't think Apple actually shipped `Cross-Origin-Window-Policy` to Safari. They implemented it in TP, and we continued iterating on the spec in the looooong conversation in https://github.com/whatwg/html/issues/3740. I don't think COWP is something that either Chromium or Mozilla is going to implement, and I'd hope that WebKit would align on what we ended up with.With regard to that willingness to align, Anne asked Apple explicitly for feedback in early January. I've pinged that thread. I'm hopeful that they'll get on board with the work Anne, et al. have done.4. Where's the TAG review?We didn't file one. I don't believe anyone at Mozilla or Apple did either. That's unfortunate! Still, given the close collaboration between Mozilla and Google, I hope we've covered enough of the bases here from a design perspective.That said, I did file a review request for the very-related Securer Contexts proposal that relies on COOP and COEP as underlying primitives. That's been sitting open for a little under a month at https://github.com/w3ctag/design-reviews/issues/471, currently scheduled for conversation in the TAG's F2F in March.Would still be good to file one. I agree that given the amount of feedback this proposal already got, it shouldn't be blocking, but it would be good to put it on their radar, and respond to feedback if there is any.
Anne van Kesteren
It's not shipping in Firefox yet as
https://bugzilla.mozilla.org/show_bug.cgi?id=1613066 still has
blocking bugs and in general we probably want to ship COOP and COEP
together which have some further dependencies as tracked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1477743. Hopefully these
are resolved soonish. To some extent these are Firefox-specific
concerns and do not affect the specification. There's one issue when
COOP+COEP are combined though that I haven't really seen mentioned
here, which is that they should provide "origin isolation" in a web
observable sense (ignoring Spectre attacks, for now) in that
document.domain ought not to work and agent clusters have a more
limited scope. See https://github.com/whatwg/html/issues/5122 for
details (and a link to a PR).
On Fri, Feb 28, 2020 at 6:04 PM Yoav Weiss <yo...@yoav.ws> wrote:
> Hmm, is that all we have as far as a spec goes?
> Any progress on integrating that into HTML? (I see many open issues, some asking for such spec integration)
groups and such as concepts and refactoring how browsing contexts are
allocated, but the bottom line is that navigation (and history) are
rather borked and any kind of change for the better is still a lot of
work. I have not lost hope however and it seems Camille et al are
interested in helping out, which is great! (Also don't mind if it gets
moved elsewhere by the way, though I would somewhat prefer to not
split issue tracking between wherever it moves and whatwg/html at this
point.)
Kind regards,
Anne
Camille Lamy
Heya,
It's not shipping in Firefox yet as
https://bugzilla.mozilla.org/show_bug.cgi?id=1613066 still has
blocking bugs and in general we probably want to ship COOP and COEP
together which have some further dependencies as tracked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1477743. Hopefully these
are resolved soonish. To some extent these are Firefox-specific
concerns and do not affect the specification. There's one issue when
COOP+COEP are combined though that I haven't really seen mentioned
here, which is that they should provide "origin isolation" in a web
observable sense (ignoring Spectre attacks, for now) in that
document.domain ought not to work and agent clusters have a more
limited scope. See https://github.com/whatwg/html/issues/5122 for
details (and a link to a PR).
Camille Lamy
Yoav Weiss
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhnbdAj_GGRNmMNrMAf27vNdfdib6qSUXk_sYKW8D2ryA%40mail.gmail.com.
Chris Harrelson
Hi,The API owners had a long-ish discussion of this intent. It looks like this is an excellent case of good agreement and collaboration between the vendors, especially between Chromium and Gecko, which is really great.However, in this case the spec is still in the form of a not-quite-spec. I'd like this to be converted into an actual PR against the HTML spec before approving the intent-to-ship. This will be another step to make sure we have agreement and interp on the semantics of this feature.
Artur Janc
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/cJ5dXIcQCsc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_9_PQ5uwyZUhRJdb2%3DrCqwmk_Gqefnr%3Dxhx%2Bv_TpO_WQ%40mail.gmail.com.
Chris Harrelson
Just to clarify, are you looking for something more than Camille's https://github.com/whatwg/html/pull/5334 or will you be comfortable with this ITS once that PR lands?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqroVDcDKQ1T1ZXRbfwT2XcoB9pchSfua8p8se7Bd-EbPA%40mail.gmail.com.
sligh...@chromium.org
Thanks,Chris
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhnbdAj_GGRNmMNrMAf27vNdfdib6qSUXk_sYKW8D2ryA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/cJ5dXIcQCsc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_9_PQ5uwyZUhRJdb2%3DrCqwmk_Gqefnr%3Dxhx%2Bv_TpO_WQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Chris Harrelson
Thanks,Chris
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhnbdAj_GGRNmMNrMAf27vNdfdib6qSUXk_sYKW8D2ryA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/cJ5dXIcQCsc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_9_PQ5uwyZUhRJdb2%3DrCqwmk_Gqefnr%3Dxhx%2Bv_TpO_WQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqroVDcDKQ1T1ZXRbfwT2XcoB9pchSfua8p8se7Bd-EbPA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ba677b8d-0ddf-4872-b662-569db5634b0c%40chromium.org.