Intent to Ship: Cross-Origin-Embedder-Policy (COEP)

213 views
Skip to first unread message

Yutaka Hirano

unread,
Feb 28, 2020, 11:03:36 AM2/28/20
to blink-dev

Contact emails

yhi...@chromium.org, mk...@chromium.org


Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit


Spec

https://github.com/mikewest/corpp/


(https://github.com/mikewest/corpp/pull/9, https://github.com/mikewest/corpp/pull/10 and https://github.com/mikewest/corpp/pull/11 are expected to be merged before shipping.)


Summary


This feature is enabled when a "cross-origin-embedder-policy" HTTP header is attached to a main resource. When enabled, for every subresource which doesn't have "cross-origin-resource-policy" HTTP header, the user agent behaves as if "cross-origin-resource-policy: same-origin" is attached to it.


This means cross-origin subresource requests which are checked by neither CORS (cross-origin-resource-sharing) nor CORP (cross-origin-resource-policy) will be blocked by this feature.


This is a security feature. Together with Cross-Origin-Opener-Policy (COOP) we will be able to allow powerful APIs such as memory measurement API.


Link to “Intent to Prototype” blink-dev discussion

Intent to Implement: Cross-Origin-Resource-Policy-Policy (the name will be changed) The name has changed!


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature is supported on Windows, Mac, Linux, Chrome OS, and Android.


We're still discussing whether we want to support this on Android WebView. We may not be able to isolate a COOP&COEP-enabled renderer process on WebView, which means we may not want to allow web developers to use powerful APIs even when they opt-in to COOP&COEP. 


Demo link

N/A


Debuggability


We're talking with the devtools team, and we plan some support for COEP, but that is not included in M82.


The reporting feature is included (except for ReportingObserver integration), so site owners can test their sites without breaking them before actually enabling the feature.


Risks

Interoperability and Compatibility

This is a new feature. Firefox is keen to develop this feature, and we are working together for speccing and implementing wpts.


The fact that the "full" feature is supported by neither browsers is a (small) risk. Chromium supports

- Document

- Dedicated workers

- Service workers

- The reporting feature except for ReportingObserver integration


while Firefox will support

- Document

- Dedicated workers

.


Edge: No signals

Firefox: In development

Safari: No signals

Web / Framework developers: None


Ergonomics

This is often used with COOP, and we plan to ship these two about the same time.  Intent for COOP will be sent separately.


Activation

This feature itself only blocks loading/navigation, so there is no use of polyfills.

Site owners can use the "report-only" feature to test their sites without breaking them before actually enabling this feature.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/html/cross-origin-embedder-policy


Entry on the feature dashboard

https://www.chromestatus.com/features/5642721685405696


Daniel Bratell

unread,
Feb 28, 2020, 12:14:15 PM2/28/20
to Yutaka Hirano, blink-dev

Ah, good to see the work coming close to shipping!

A few comments/questions:

It looks like both this and COOP are collaborations between browser vendors but I wonder why the spec texts still live in disconnected documents. I would have expected them to live in a standardization environment, be it W3C, IETF or WhatWG.

One of the requirements we put on changes to the web platform is that they should have been shown to the TAG, gotten a review, or if that is overkill for some reason, we want to know why it's overkill. This request does not mention TAG.

Since other vendors have been involved in the development I assume that they are fine with these changes, but it would be good to make it official in some way. Especially Safari seem absent even though Apple was mentioned in the explainer document.

/Daniel

--
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/CABihn6ESCCt6FX7JoWFiB7j0kiakbq98vZ3WASsB0hQyn5dKOA%40mail.gmail.com.

Mike West

unread,
Mar 1, 2020, 11:37:46 AM3/1/20
to Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev
As I noted on the other thread, my name is on bits of this, so I'm abstaining. Still, LGTM0, my full support, etc. :)

On Fri, Feb 28, 2020 at 6:14 PM Daniel Bratell <brat...@gmail.com> wrote:

Ah, good to see the work coming close to shipping!

A few comments/questions:

It looks like both this and COOP are collaborations between browser vendors but I wonder why the spec texts still live in disconnected documents. I would have expected them to live in a standardization environment, be it W3C, IETF or WhatWG.

We defined COEP as a separate document in order to work out its kinks in something a little less incomprehensible than a set of PRs against Fetch and HTML. It's structured explicitly as a set of monkey patches, and I don't intend for it to live as a stand-alone document forever, but to be folded into those documents. If it would be helpful to move that document to WHATWG more explicitly, I'm quite happy to do so, and I'm sure +Anne van Kesteren would oblige.

One of the requirements we put on changes to the web platform is that they should have been shown to the TAG, gotten a review, or if that is overkill for some reason, we want to know why it's overkill. This request does not mention TAG.

As noted on the other thread, this was an oversight. At the same time, we've been working closely with Mozilla on the mechanism, and I do hope we've gotten enough of the design work lined up correctly. I hope the TAG will have some opinions on the underlying primitives in the context of the conversation around https://github.com/w3ctag/design-reviews/issues/471, which relies explicitly upon COOP/COEP. 

Since other vendors have been involved in the development I assume that they are fine with these changes, but it would be good to make it official in some way. Especially Safari seem absent even though Apple was mentioned in the explainer document.

As noted on the other thread, I'll defer to Anne for a final word from Mozilla, but the comments at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes are, IMO, a positive intent to ship.

The story with regard to Apple is similar to the story around COOP. We've quite actively solicited feedback, and I've pinged the most recent private thread to see if opinions appear.

-mike
 

Jochen Eisinger

unread,
Mar 2, 2020, 5:58:13 AM3/2/20
to Mike West, Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev
lgtm1

Yoav Weiss

unread,
Mar 2, 2020, 6:21:13 AM3/2/20
to Mike West, Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev
On Sun, Mar 1, 2020 at 5:37 PM Mike West <mk...@chromium.org> wrote:
As I noted on the other thread, my name is on bits of this, so I'm abstaining. Still, LGTM0, my full support, etc. :)

On Fri, Feb 28, 2020 at 6:14 PM Daniel Bratell <brat...@gmail.com> wrote:

Ah, good to see the work coming close to shipping!

A few comments/questions:

It looks like both this and COOP are collaborations between browser vendors but I wonder why the spec texts still live in disconnected documents. I would have expected them to live in a standardization environment, be it W3C, IETF or WhatWG.

We defined COEP as a separate document in order to work out its kinks in something a little less incomprehensible than a set of PRs against Fetch and HTML. It's structured explicitly as a set of monkey patches, and I don't intend for it to live as a stand-alone document forever, but to be folded into those documents. If it would be helpful to move that document to WHATWG more explicitly, I'm quite happy to do so, and I'm sure +Anne van Kesteren would oblige.

Can we move the spec from a personal repo to e.g. the WICG, in the meantime? Given the evidence of industry support, I suspect the chairs would approve :)
 

Mike West

unread,
Mar 2, 2020, 6:29:36 AM3/2/20
to Yoav Weiss, Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev
On Mon, Mar 2, 2020 at 12:21 PM Yoav Weiss <yo...@yoav.ws> wrote:
On Sun, Mar 1, 2020 at 5:37 PM Mike West <mk...@chromium.org> wrote:
As I noted on the other thread, my name is on bits of this, so I'm abstaining. Still, LGTM0, my full support, etc. :)

On Fri, Feb 28, 2020 at 6:14 PM Daniel Bratell <brat...@gmail.com> wrote:

Ah, good to see the work coming close to shipping!

A few comments/questions:

It looks like both this and COOP are collaborations between browser vendors but I wonder why the spec texts still live in disconnected documents. I would have expected them to live in a standardization environment, be it W3C, IETF or WhatWG.

We defined COEP as a separate document in order to work out its kinks in something a little less incomprehensible than a set of PRs against Fetch and HTML. It's structured explicitly as a set of monkey patches, and I don't intend for it to live as a stand-alone document forever, but to be folded into those documents. If it would be helpful to move that document to WHATWG more explicitly, I'm quite happy to do so, and I'm sure +Anne van Kesteren would oblige.

Can we move the spec from a personal repo to e.g. the WICG, in the meantime? Given the evidence of industry support, I suspect the chairs would approve :)

Sure? I'll go post on the discourse, I suppose.

Mike West

unread,
Mar 2, 2020, 6:46:01 AM3/2/20
to Yoav Weiss, Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev

Yoav Weiss

unread,
Mar 5, 2020, 8:12:40 AM3/5/20
to Mike West, Daniel Bratell, Anne van Kesteren, Yutaka Hirano, blink-dev
LGTM2

This is an important isolation primitive, and was created as a collaborative effort across vendors. While the lack of a dedicated TAG review is unfortunate, the broader scope of that work and what it enables is up for a review.

sligh...@chromium.org

unread,
Mar 5, 2020, 11:48:03 AM3/5/20
to blink-dev, mk...@google.com, brat...@gmail.com, ann...@annevk.nl, yhi...@chromium.org
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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.

--
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.

Arthur Sonzogni

unread,
Oct 14, 2020, 7:18:24 AM10/14/20
to sligh...@chromium.org, blink-dev, Mike West, brat...@gmail.com, Anne van Kesteren, Yutaka Hirano

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature is supported on Windows, Mac, Linux, Chrome OS, and Android.


We're still discussing whether we want to support this on Android WebView. We may not be able to isolate a COOP&COEP-enabled renderer process on WebView, which means we may not want to allow web developers to use powerful APIs even when they opt-in to COOP&COEP. 

 
We discussed support for Android Webview.
Even if COOP+COEP won't give a crossOriginIsolated process (and powerful APIs) on Android WebView, we think it would be great not to exclude android webview from the COEP rules.

Consistency of the web-facing behavior across the platforms is valuable. 
Subresources blocked by COEP should behave the same universally.

Are the API OWNERS fine with expanding the platform coverage?

(Please let me know if this requires a full intent-to-ship, or a simple reply to this thread is enough).

Yoav Weiss

unread,
Oct 14, 2020, 9:20:45 AM10/14/20
to Arthur Sonzogni, Alex Russell, blink-dev, Mike West, Daniel Bratell, Anne van Kesteren, Yutaka Hirano
What would be the impact on WebView?
COOP+COEP would be enforced, but won't provide access to the powerful features they enable in other platforms?

If so, LGTM to expand platform coverage. I don't think that a separate intent is necessary.

--
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/CAAzos5E%2Bgei8ui8MSpmBYOacHkmn7HvVy78oafNWs2F2W2sBCw%40mail.gmail.com.

Arthur Sonzogni

unread,
Oct 14, 2020, 9:51:55 AM10/14/20
to Yoav Weiss, Alex Russell, blink-dev, Mike West, Daniel Bratell, Anne van Kesteren, Yutaka Hirano
What would be the impact on WebView?
COOP+COEP would be enforced, but won't provide access to the powerful features they enable in other platforms?

If so, LGTM to expand platform coverage. I don't think that a separate intent is necessary.

Exactly. This will make resources normally blocked by COEP to be blocked on Android WebView as well.
This doesn't give any new extra capabilities.
Reply all
Reply to author
Forward
0 new messages