Imported ES modules can't currently have their integrity checked, and hence cannot run in environments that require Subresource Integrity or with `require-sri-for` CSP directives. This feature adds an `integrity` section to import maps, enabling developers to map ES module URLs to their integrity metadata, and ensure they only load when they match their expected hashes.
On the interoperability front, this got a positive position from WebKit, and I'm implementing the feature there. Mozilla didn't object to the feature, but asked for a couple more weeks to evaluate it and provide a position, as they might be planning broader-scope work on the front of application integrity, and want to make sure this doesn't collide with it.
On the compatibility front, the feature is polyfilled, but it's turned off for browsers that support import maps.
Adding Guy Bedford, the polyfill author to this thread. Guy, can you confirm this is the case?
As long as support is not ubiquitous, the `integrity` part of import maps will be ignored in non-supporting browsers, resulting in scripts loading in those browsers even if they're supposed to fail their integrity checks.
There's also a polyfill that would enable sites to get integrity support for ES modules in browsers that don't support import maps at all. That's an increasingly slim part of the browser population.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
No issues in particular. The feature does emit a few console errors in cases where parsing fails, to help developers debug this.
https://chromium-review.googlesource.com/c/chromium/src/+/5441822
Shipping on desktop | 127 |
Shipping on Android | 127 |
Shipping on WebView | 127 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
Contact emailsyoav...@chromium.org
Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
Specificationhttps://github.com/whatwg/html/pull/10269
The PR is ready to land, but we're holding off on that for 2 weeks at Mozilla's request. See below.
SummaryImported ES modules can't currently have their integrity checked, and hence cannot run in environments that require Subresource Integrity or with `require-sri-for` CSP directives. This feature adds an `integrity` section to import maps, enabling developers to map ES module URLs to their integrity metadata, and ensure they only load when they match their expected hashes.
Blink componentBlink>Loader
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
TAG review statusIssues addressed
Risks
Interoperability and CompatibilityOn the interoperability front, this got a positive position from WebKit, and I'm implementing the feature there. Mozilla didn't object to the feature, but asked for a couple more weeks to evaluate it and provide a position, as they might be planning broader-scope work on the front of application integrity, and want to make sure this doesn't collide with it.
On the compatibility front, the feature is polyfilled, but it's turned off for browsers that support import maps.
Adding Guy Bedford, the polyfill author to this thread. Guy, can you confirm this is the case?
This is based on a proposal from a developer (Guy Bedford).Multiple Shopify properties are interested in this, to enable using ES modules as bundler output in security sensitive environments. Asking about this on twitter and mastodon showed that some developers are interested in this, while others discount SRI in general.
Other signals:
ActivationAs long as support is not ubiquitous, the `integrity` part of import maps will be ignored in non-supporting browsers, resulting in scripts loading in those browsers even if they're supposed to fail their integrity checks.
There's also a polyfill that would enable sites to get integrity support for ES modules in browsers that don't support import maps at all. That's an increasingly slim part of the browser population.
WebView application risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
DebuggabilityNo issues in particular. The feature does emit a few console errors in cases where parsing fails, to help developers debug this.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes
Is this feature fully tested by web-platform-tests?Yeshttps://chromium-review.googlesource.com/c/chromium/src/+/5441822
Flag name on chrome://flagsNone
Finch feature nameImportMapIntegrity
Requires code in //chrome?False
Tracking bughttps://issues.chromium.org/issues/334251999
MeasurementNo use-counter was added so far. If one is needed, I can add it when flipping on the flag.
Availability expectationFeature is available in WebKit within a few months of launch in Chromium, if not before. Still waiting on Mozilla's position and plans.
Adoption expectation
I expect web developers that want to rely on SRI for ES modules to use the feature directly without requiring the polyfill.
Anticipated spec changesOpen questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No open questions.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5157245026566144?gate=5203447331946496
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaYce5MGsXBzw6K_py5yEj_Vx6o_%3DA4CecJm_gaAyU7H6wfPQ%40mail.gmail.com
On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:Contact emailsyoav...@chromium.org
Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
Specificationhttps://github.com/whatwg/html/pull/10269The PR is ready to land, but we're holding off on that for 2 weeks at Mozilla's request. See below.
SummaryImported ES modules can't currently have their integrity checked, and hence cannot run in environments that require Subresource Integrity or with `require-sri-for` CSP directives. This feature adds an `integrity` section to import maps, enabling developers to map ES module URLs to their integrity metadata, and ensure they only load when they match their expected hashes.
Blink componentBlink>Loader
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
TAG review statusIssues addressed
Risks
Interoperability and CompatibilityOn the interoperability front, this got a positive position from WebKit, and I'm implementing the feature there. Mozilla didn't object to the feature, but asked
I'm inclined to LGTM this now - but don't see a lot of harm
waiting for 1 additional week (per Mozilla's request in the
not-public minutes). Happy to do so before, so long as the HTML PR
lands.
--
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/CAOmohSK%3D6VEeSaicP7b1m47btcd7q3dBTR9AoL241bgSPZD7Gw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/59075b03-0a21-47da-9f03-36a249a12894%40chromium.org.
On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:Contact emailsyoav...@chromium.org
Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
Specificationhttps://github.com/whatwg/html/pull/10269The PR is ready to land, but we're holding off on that for 2 weeks at Mozilla's request. See below.
SummaryImported ES modules can't currently have their integrity checked, and hence cannot run in environments that require Subresource Integrity or with `require-sri-for` CSP directives. This feature adds an `integrity` section to import maps, enabling developers to map ES module URLs to their integrity metadata, and ensure they only load when they match their expected hashes.
Blink componentBlink>Loader
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
TAG review statusIssues addressed
Risks
Interoperability and CompatibilityOn the interoperability front, this got a positive position from WebKit, and I'm implementing the feature there. Mozilla didn't object to the feature, but asked
I just realized that the meeting notes are not publicly viewable.+Panos Astithas - would you be able to open them up to the public somehow? (e.g. as a Chromium.org doc)
I'm also not sure why we would wait.
That said, if we're expanding SRI, it would be great to see media resources included. Won't block this intent on it, but for architectural consistency want to flag that we aren't "done".
On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:Contact emailsyoav...@chromium.org
Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
Specificationhttps://github.com/whatwg/html/pull/10269The PR is ready to land, but we're holding off on that for 2 weeks at Mozilla's request. See below.
SummaryImported ES modules can't currently have their integrity checked, and hence cannot run in environments that require Subresource Integrity or with `require-sri-for` CSP directives. This feature adds an `integrity` section to import maps, enabling developers to map ES module URLs to their integrity metadata, and ensure they only load when they match their expected hashes.
Blink componentBlink>Loader
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
TAG review statusIssues addressed
Risks
Interoperability and CompatibilityOn the interoperability front, this got a positive position from WebKit, and I'm implementing the feature there. Mozilla didn't object to the feature, but asked
I just realized that the meeting notes are not publicly viewable.+Panos Astithas - would you be able to open them up to the public somehow? (e.g. as a Chromium.org doc)They were published that same day, we try to post the minutes publicly in less than 24 hours.
LGTM1
--
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/CAOmohSKEJ3THh0priUxMe2qg17Z%2BGjo4ecedvnDwpwPQkNiuYg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3f90fdca-8e32-4c01-9273-7247eddb7c52%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OHuOptmMSzUvYRsLdHsEDuxGYV2nAAyAiPzhuz9Gkj9Q%40mail.gmail.com.
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OHuOptmMSzUvYRsLdHsEDuxGYV2nAAyAiPzhuz9Gkj9Q%40mail.gmail.com.
Doh, make that a bonus LGTM4. Sorry for the confusion.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/21b53524-971f-4e5d-8122-662c51617b3c%40sarasas.se.