Intent to Ship: Cross-Origin-Embedder-Policy: credentialless

165 views
Skip to first unread message

Arthur Sonzogni

unread,
Sep 10, 2021, 7:17:34 AMSep 10
to blink-dev, Mike West, Lutz Vahl

Contact emails

arthurs...@chromium.orgcl...@chromium.orgmk...@chromium.org

Explainer

https://github.com/WICG/credentiallessness

Specification

https://wicg.github.io/credentiallessness/

Design docs


https://github.com/WICG/credentiallessness
https://docs.google.com/document/d/1U1pDzS_WJpfkq6QqOeqgmXmba_I4tIbUR-5C1AHzI9o/edit#

Summary

Introduce Cross-Origin-Embedder-Policy: credentialless. This causes cross-origin no-cors requests to omit credentials (cookies, client certificates, etc). Similarly to COEP:require-corp, it can enable cross-origin isolation.



Blink component

Blink>SecurityFeature

Search tags

coepcredentiallesscoopcrossoriginisolationcrossOriginisolated

TAG review

https://github.com/w3ctag/design-reviews/issues/582

TAG review status

Pending

Link to origin trial feedback summary

https://docs.google.com/document/d/1Rcho9z8obW0A7aeM3Zz1QR3fN7KcmTHgjdF_mKEXiRQ

Risks



Interoperability and Compatibility

Compatibility risk: This is an opt-in new feature, so there are no compatibility risks. Interoperability risk: New feature. Risk is failing to become an interoperable part of the web platform.



Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/539#issuecomment-867473836)
Worth prototyping, but concerns are about the timing in between shipping: COEP:credentialless, Private Network Access (PNA), ORB. See https://github.com/mozilla/standards-positions/issues/539#issuecomment-914418485

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html)
No official replies yet. Safari is currently implementing COOP/COEP, but have no plan yet about COEP:credentialless variant: https://twitter.com/mikewest/status/1434878018191826948<

Web developers: Positive (https://github.com/WICG/proposals/issues/31#issuecomment-858822619)
Google Earth, Twitter, Zoom, etc... are positive.

Ergonomics

Similarly to the existing COEP:require-corp, it will also be often used in tandem with Cross-Origin-Opener-Policy: same-origin (COOP)



Activation

This is an HTTP header. Developers need to be able to configure their server. This is hard for them when hosting their page on servers they don't really own, like https://github.io pages.



Debuggability

The same devtool features as for COEP:require-corp: 1. Display COEP policy: Devtool > Application > Frames > top > Security & Isolation > Cross-Origin Embedder Policy. 2. Devtool issues: https://source.chromium.org/search?q=file:devtools-frontend%2Fsrc%2Ffront_end%2Fmodels%2Fissues_manager%2Fdescriptions%2FCoep*&ss=chromium



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

Yes

Flag name

chrome://flags/#cross-origin-embedder-policy-credentialless

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1175099

Launch bug

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

Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/3881

Sample links


http://coep-credentialless.glitch.me/

Estimated milestones

OriginTrial desktop last95
OriginTrial desktop first93
DevTrial on desktop93
OriginTrial android last95
OriginTrial android first93
DevTrial on android93
DevTrial on Webview93


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4918234241302528

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/DOtU6R4TuAY/m/kPbID-LAAQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Sdc0G1bvKr0/m/YHR8RuWyAAAJ


This intent message was generated by Chrome Platform Status.
Arthur @arthursonzogni

Yoav Weiss

unread,
Sep 10, 2021, 8:22:40 AMSep 10
to Arthur Sonzogni, Alex Russell, Eric Lawrence, blink-dev, Mike West, Lutz Vahl
Thanks for working on this! This seems like a great addition to the CrossOriginIsolation story, and will help developers make their users safer in the face of non-cooperative third parties.

Anne's argument is that shipping this before shipping PNA protections would put private resources at extra risk, because the documents including them would be considered COI, and therefore would have access to high precision timers.

Our argument is that the reverse OT for SAB access without COI already enables that in Chrome.

That makes sense, but maybe there's a way for us to combine this and the recent PNA intent and be more bold there only in the case of a COEP: credentialless embedder?
For example, avoid waiting 2 milestones/letting folks opt-out for 4 more milestones if the embedder opted-in to credentialless?

I'm not sure if it makes sense to block on this (or at all), but it could be a middle ground that'd timebox those concerns.

No official replies yet. Safari is currently implementing COOP/COEP, but have no plan yet about COEP:credentialless variant: https://twitter.com/mikewest/status/1434878018191826948<

Web developers: Positive (https://github.com/WICG/proposals/issues/31#issuecomment-858822619)
Google Earth, Twitter, Zoom, etc... are positive.

Ergonomics

Similarly to the existing COEP:require-corp, it will also be often used in tandem with Cross-Origin-Opener-Policy: same-origin (COOP)



Activation

This is an HTTP header. Developers need to be able to configure their server. This is hard for them when hosting their page on servers they don't really own, like https://github.io pages.


Aside, but maybe our friends at Microsoft know people on the GH side that can help fix that? This is a recurrent issue, and it'd be good to solve it at some point.
 
--
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/CAAzos5GX5UpU_8V5faX0KzvWG9y5FT8BvCDJ5LUQ929LWM3%3DPA%40mail.gmail.com.

Arthur Sonzogni

unread,
Sep 10, 2021, 9:28:47 AMSep 10
to Yoav Weiss, Alex Russell, Eric Lawrence, blink-dev, Mike West, Lutz Vahl
> That makes sense, but maybe there's a way for us to combine this and the recent PNA intent and be more bold there only in the case of a COEPcredentialless embedder?

That's an interesting idea! I think it's worth considering when PNA will have an implementation of preflight checks. For now, it doesn't and I would like to avoid tying two features together during a launch.
Moreover, this would still not bring better than the status-co for now, because the SAB OT remains.

However, this is a nice subset to experiment/launch PNA earlier. Maybe we can be more aggressive here. The subset might be COEP:credentialless, COEP:X, COI.
This would require adding some metrics to understand exactly how many pages would be affected by PNA in every subset. I think we will add some metrics for M96 as well and make a decision based on that.

Arthur @arthursonzogni

Yoav Weiss

unread,
Sep 10, 2021, 9:36:43 AMSep 10
to Arthur Sonzogni, Alex Russell, Eric Lawrence, blink-dev, Mike West, Lutz Vahl
LGTM1

On Fri, Sep 10, 2021 at 3:28 PM Arthur Sonzogni <arthurs...@google.com> wrote:
> That makes sense, but maybe there's a way for us to combine this and the recent PNA intent and be more bold there only in the case of a COEPcredentialless embedder?

That's an interesting idea! I think it's worth considering when PNA will have an implementation of preflight checks. For now, it doesn't and I would like to avoid tying two features together during a launch.
Moreover, this would still not bring better than the status-co for now, because the SAB OT remains.

However, this is a nice subset to experiment/launch PNA earlier. Maybe we can be more aggressive here. The subset might be COEP:credentialless, COEP:X, COI.
This would require adding some metrics to understand exactly how many pages would be affected by PNA in every subset. I think we will add some metrics for M96 as well and make a decision based on that.

That sounds perfectly reasonable!

Domenic Denicola

unread,
Sep 10, 2021, 12:57:44 PMSep 10
to Arthur Sonzogni, blink-dev, Mike West, Lutz Vahl
On Fri, Sep 10, 2021 at 7:17 AM 'Arthur Sonzogni' via blink-dev <blin...@chromium.org> wrote:

Note also that Arthur has done the right thing here and submitted PRs to upstream the monkeypatch spec into HTML and Fetch:
Both have gotten pretty thorough reviews, which increases my confidence we're trying to ship something interoperably implementable. Yay!

--

Chris Harrelson

unread,
Sep 16, 2021, 3:13:47 PMSep 16
to Domenic Denicola, Arthur Sonzogni, blink-dev, Mike West, Lutz Vahl

Alex Russell

unread,
Sep 16, 2021, 3:15:33 PMSep 16
to blink-dev, Chris Harrelson, Arthur Sonzogni, blink-dev, Mike West, va...@google.com, Domenic Denicola
LGTM3. This is important work and I'm glad to see it happening.

Is there any word on follow-up work to make this mode available from, e.g., `fetch()`?

Best Regards,

Alex

On Thursday, September 16, 2021 at 12:13:47 PM UTC-7 Chris Harrelson wrote:
LGTM2

On Fri, Sep 10, 2021 at 9:57 AM Domenic Denicola <dom...@chromium.org> wrote:
On Fri, Sep 10, 2021 at 7:17 AM 'Arthur Sonzogni' via blink-dev <blin...@chromium.org> wrote:
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,
Sep 20, 2021, 4:02:05 AMSep 20
to blink-dev, Alex Russell, Chris Harrelson, Arthur Sonzogni, blink-dev, Mike West, va...@google.com, Domenic Denicola
> Is there any word on follow-up work to make this mode available from, e.g., `fetch()`?

Some APIs like fetch(), <img>, <script>, <style>, etc...  allows on a per-request basis to control request.mode or request.credentials.
Some APIs don't integrate with these yet. For instance, every CSS properties like "background-img".

However, COEP:credentialless is a bit orthogonal. It is a global property (per document/workers) affecting every APIs. It guarantees that every cross-origin resources loaded will either get an explicit opt-in being embedded via CORS, or will be requested anonymously.

For cross-origin 'no-cors' requests, this forces the requests to be sent without credentials. This is a saner a behavior saner than the current default COEP:unsafe-none, with regards to Spectre attacks.
Reply all
Reply to author
Forward
0 new messages