Intent to Ship: COEP for shared worker

Yifan Luo

unread,

Sep 7, 2021, 9:00:48 AM9/7/21

to gle...@chromium.org, Lutz Vahl, Arthur Sonzogni, Camille Lamy, mkwst-org

Summary

Enforce Cross-Origin-Embedder-Policy in SharedWorker. Cross-Origin-Embedder-Policy HTTP header prevents documents and workers from loading cross-origin resources without an explicit opt-in, either with CORS or CORP. This was previously shipped for: Document, DedicatedWorker, and ServiceWorker. Now we want to bring support for SharedWorker.

Blink component

Blink>SecurityFeature>COEP

Search tags

coep, sharedworker, coop

TAG review

The previous COEP launch did not have a TAG review. This intent just implements what was postponed in the previous intent. However this was discussed more broadly with COOP/COEP and crossOriginIsolation here: https://github.com/w3ctag/design-reviews/issues/471

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This implements an existing part of the HTML specification. It was written by Mozilla and Chrome. Mozilla is also working on supporting it for SharedWorker. Webkit is implementing COEP and will support workers. However, SharedWorker isn't supported by webkit.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1613912) Mozilla and Chrome wrote the specification a year ago. Mozilla is implementing it above too.

WebKit: N/A Webkit is implementing COEP and will support workers: https://github.com/WebKit/WebKit/commit/e6c7e17d32fa0dd802337c7f0d2c63b0703b782a However SharedWorker do not exist in Webkit.

Web developers: No signals

Ergonomics

This will often be used together with documents using COOP+COEP. This isn't implemented, but supporting COEP allows Chrome to put the SharedWorker in the COOP+COEP process. This can potentially improve performance.

Activation

This doesn't affect existing websites, since it requires using the COEP header. It can be hard for some developers to add an HTTP header when they don't own their server. For instance with https://github.io It is not polyfillable. Site owners can use the "report-only" feature to test what would break before actually enabling this feature.

Security

When a COEP header is used, it restricts the set of resources the SharedWorker can fetch. In detail, it requires the resources an explicit opt-in: CORS or CORP to be embedded cross-origin. In the future, this will gate the crossOriginIsolated capability, but this isn't implemented here. Since this mostly new restrictions, without new extra capabilities. The security risk should be low.

Debuggability

Contrary to Document where devtool reflects the current COEP state in the application > frame panel, there isn't such a thing for workers. We should think about it in the future. Otherwise existing COEP/Devtools mechanisms are still available. Resources blocked by COEP display a Devtools issue in the console and in the network panel.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

COEPForSharedWorker

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1245550

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1247200

Estimated milestones

DevTrial on desktop	94
DevTrial on iOS	94
DevTrial on Webview	94

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5698074912489472

This intent message was generated by Chrome Platform Status.

--

Yifan

Yoav Weiss

unread,

Sep 9, 2021, 7:30:20 AM9/9/21

to blink-dev, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org, Eiji Kitamura

On Tuesday, September 7, 2021 at 3:00:48 PM UTC+2 Yifan Luo wrote:

Contact emails
l...@chromium.org, arthursonzogn...@chromium.org

Explainer
https://docs.google.com/document/d/1mpIKhBhsx4deZXu3C2bnie5LSbzumjD1m6uhJx-hPQA/edit?usp=sharing

Specification
https://wicg.github.io/cross-origin-embedder-policy/

Summary
Enforce Cross-Origin-Embedder-Policy in SharedWorker. Cross-Origin-Embedder-Policy HTTP header prevents documents and workers from loading cross-origin resources without an explicit opt-in, either with CORS or CORP. This was previously shipped for: Document, DedicatedWorker, and ServiceWorker. Now we want to bring support for SharedWorker.

Blink component
Blink>SecurityFeature>COEP

Search tags
coep, sharedworker, coop

TAG review
The previous COEP launch did not have a TAG review. This intent just implements what was postponed in the previous intent. However this was discussed more broadly with COOP/COEP and crossOriginIsolation here: https://github.com/w3ctag/design-reviews/issues/471

I agree that discussion seems sufficient to cover the same mechanisms in Shared Workers.

TAG review status
Not applicable

Risks

Interoperability and Compatibility
This implements an existing part of the HTML specification. It was written by Mozilla and Chrome. Mozilla is also working on supporting it for SharedWorker. Webkit is implementing COEP and will support workers. However, SharedWorker isn't supported by webkit.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1613912) Mozilla and Chrome wrote the specification a year ago. Mozilla is implementing it above too.

I'm cautious about using that as evidence for a positive position. Can you ask for signals? https://bit.ly/blink-signals

WebKit: N/A Webkit is implementing COEP and will support workers: https://github.com/WebKit/WebKit/commit/e6c7e17d32fa0dd802337c7f0d2c63b0703b782a However SharedWorker do not exist in Webkit.

Web developers: No signals

Do we have signals about COEP in general that could be applied here? Adding Eiji who may have something

Eiji Kitamura

unread,

Sep 9, 2021, 11:19:59 AM9/9/21

to Yoav Weiss, blink-dev, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org

It's positive. For example, emscripten uses SharedArrayBuffer to use pthread by enabling cross-origin isolation by sending COEP and COOP. I consider this is a signal that developers accept this restriction.

https://emscripten.org/docs/porting/pthreads.html

2021年9月9日(木) 20:30 Yoav Weiss <yoav...@chromium.org>:

On Tuesday, September 7, 2021 at 3:00:48 PM UTC+2 Yifan Luo wrote:

Contact emails
l...@chromium.org, arthurs...@chromium.org

Arthur Sonzogni

unread,

Sep 9, 2021, 11:35:40 AM9/9/21

to blink-dev, Eiji Kitamura, blink-dev, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org, Yoav Weiss

> I'm cautious about using that as evidence for a positive position. Can you ask for signals? https://bit.ly/blink-signals

This intent is about completing the implementation of a previously shipped mechanism to a context where it should have existed in the first place.

There was agreement with Mozilla when the PR(s) landed. Yes, it doesn't hurt asking Mozilla a reconfirmation. Here it is:

https://github.com/mozilla/standards-positions/issues/577

=> "This is worth prototyping as per agreement on the spec PR [...] Will leave it open for a bit in case anyone else has thoughts."

On Thursday, September 9, 2021 at 5:19:59 PM UTC+2 Eiji Kitamura wrote:

It's positive. For example, emscripten uses SharedArrayBuffer to use pthread by enabling cross-origin isolation by sending COEP and COOP. I consider this is a signal that developers accept this restriction.
https://emscripten.org/docs/porting/pthreads.html

2021年9月9日(木) 20:30 Yoav Weiss <yoav...@chromium.org>:

On Tuesday, September 7, 2021 at 3:00:48 PM UTC+2 Yifan Luo wrote:

Contact emails
l...@chromium.org, arthursonzogn...@chromium.org

Yoav Weiss

unread,

Sep 9, 2021, 11:54:27 AM9/9/21

to Arthur Sonzogni, blink-dev, Eiji Kitamura, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org

That's great!

LGTM1

On Thu, Sep 9, 2021 at 5:35 PM Arthur Sonzogni <arthurs...@chromium.org> wrote:

> I'm cautious about using that as evidence for a positive position. Can you ask for signals? https://bit.ly/blink-signals

This intent is about completing the implementation of a previously shipped mechanism to a context where it should have existed in the first place.
There was agreement with Mozilla when the PR(s) landed. Yes, it doesn't hurt asking Mozilla a reconfirmation. Here it is:
https://github.com/mozilla/standards-positions/issues/577
=> "This is worth prototyping as per agreement on the spec PR [...] Will leave it open for a bit in case anyone else has thoughts."

On Thursday, September 9, 2021 at 5:19:59 PM UTC+2 Eiji Kitamura wrote:

It's positive. For example, emscripten uses SharedArrayBuffer to use pthread by enabling cross-origin isolation by sending COEP and COOP. I consider this is a signal that developers accept this restriction.
https://emscripten.org/docs/porting/pthreads.html

2021年9月9日(木) 20:30 Yoav Weiss <yoav...@chromium.org>:

On Tuesday, September 7, 2021 at 3:00:48 PM UTC+2 Yifan Luo wrote:

Contact emails
l...@chromium.org, arthurs...@chromium.org

Mike West

unread,

Sep 9, 2021, 2:51:48 PM9/9/21

to Yoav Weiss, Arthur Sonzogni, blink-dev, Eiji Kitamura, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org

LGTM2.

-mike

--
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/CAL5BFfVBBjM%2BVOZVo7EryM80r4uD4xo2x%3DPTj%2Ba735LGjGiEJg%40mail.gmail.com.

Daniel Bratell

unread,

Sep 9, 2021, 3:18:19 PM9/9/21

to Mike West, Yoav Weiss, Arthur Sonzogni, blink-dev, Eiji Kitamura, Yifan Luo, va...@google.com, Arthur Sonzogni, Camille Lamy, mkwst-org

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcU%2BERoTY2BEk0zXRK8OSQQ3h-YiWy1%3DwmBUnW7ufAt-Q%40mail.gmail.com.

Reply all

Reply to author

Forward