WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
241 stars 18 forks source link

Cross-Origin Embedder Policies - "credentialless" #268

Closed adixon-adobe closed 7 months ago

adixon-adobe commented 9 months ago

WebKittens

@annevk

Title of the spec

Cross-Origin-Embedder-Policy: credentialless

URL to the spec

https://html.spec.whatwg.org/multipage/browsers.html#coep-credentialless

URL to the spec's repository

https://github.com/whatwg/html

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

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

Mozilla standards-positions issue URL

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

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=230550

Radar URL

No response

Description

This was previously filed by the Chromium team in June 2021 here: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html. This was subsequently merged into the HTML & Fetch specifications in November 2021. It also looks like Firefox will be adding support in their next release (119).

The Credentialless variant of Cross Origin Embedded Policy simplifies cross origin isolation, as existing third party scripts don't require changes unless they actually need headers that are omitted by the policy. With the require-corp variant, third party scripts must include the Cross-Origin-Resource-Policy: cross-origin header to work. In addition to requiring more coordination and third party changes, it also creates a new potential failure point with third party scripts if they accidentally remove the header.

adixon-adobe commented 9 months ago

Several web sites at Adobe including Lightroom, Adobe Express, and Acrobat are interested in this to support features like SharedArrayBuffer. We've found the additional burden of reaching out to third parties for require-corp support to be prohibitive and limiting, as it can delay integration of new technology, and creates a new failure point with third parties in that if they make changes on their end that remove the header it can break functionality that would otherwise work with the credentialless. We've already seen evidence that this is likely to happen occasionally. The work to ensure scripts that require headers otherwise stripped by credentialless appears minimal in comparison.

The Acrobat team will additionally require COOP:restrict-properties for their site, but Lightroom and Express should be able to adopt SharedArrayBuffer and improve performance in Safari with this change.

annevk commented 8 months ago

I discussed this with colleagues and Cross-Origin-Embedder-Policy: credentialless seems like a reasonable addition to the web platform to us. As such we suggest resolving this as "position: support" one week from now.

Given the security-sensitive nature of this feature I feel like I should point out that the specification notes that Local Network Access (#163) and Opaque Response Blocking (#64) are pre-requisites here and thus if anyone were thinking of undertaking a WebKit implementation they would have to take that into account. (It might be tenable to only have one of those, though not ideal.)