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.
This is an opt-in feature, so there are no compatibility risks. The main risk is that it fails to become an interoperable part of the web platform.
Similarly to the existing COEP:require-corp, it will also be often used in tandem with Cross-Origin-Opener-Policy: same-origin (COOP) to get access to the cross-origin isolated capability.
This is an HTTP header. Developers need to be able to configure their server. This is hard for websites hosted on servers they don't own, like github.io pages.
1. Is it useful on its own, despite the <iframe> continuing to be blocked? Is it worth shipping independently from anonymous iframe? 2. Does this address some of your problems deploying COEP, and cross origin isolation in general? 3. What problems remain, beyond the <iframe> constraint?
N/A
Similar to 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
Consistency of the web platform is important.
--
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/CAH7Q68UT2B1rK8qoDNxhYXqwnnpY1T7Wd%2BmWR5Q9wAOYEGNTHw%40mail.gmail.com.