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

[Arthur Sonzogni]

Contact emails

arthurs...@chromium.org, cl...@chromium.org, mk...@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

coep, credentialless, coop, crossoriginisolation, crossOriginisolated

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 last	95
OriginTrial desktop first	93
DevTrial on desktop	93
OriginTrial android last	95
OriginTrial android first	93
DevTrial on android	93
DevTrial on Webview	93

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]

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.

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.

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.

/cc +Alex Russell +Eric Lawrence 

 

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

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

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]

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 COEP: credentialless 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]

On Fri, Sep 10, 2021 at 7:17 AM 'Arthur Sonzogni' via blink-dev <blin...@chromium.org> wrote:

Contact emails

arthurs...@chromium.org, cl...@chromium.org, mk...@chromium.org

Explainer

https://github.com/WICG/credentiallessness

Specification

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

Note also that Arthur has done the right thing here and submitted PRs to upstream the monkeypatch spec into HTML and Fetch:

• https://github.com/whatwg/html/pull/6638
  
• https://github.com/whatwg/fetch/pull/1229
  

Both have gotten pretty thorough reviews, which increases my confidence we're trying to ship something interoperably implementable. Yay!

--

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8f4jkc_RtVBvjJpuz-0%2BiC7p8KKhBc--PuUQ3zjUbOgg%40mail.gmail.com.

[Alex Russell]

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:

Contact emails

arthurs...@chromium.org, cla...@chromium.org, mkwst@chromium.org

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/CAAzos5GX5UpU_8V5faX0KzvWG9y5FT8BvCDJ5LUQ929LWM3%3DPA%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.

[Arthur Sonzogni]

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