Intent to Prototype: Importmap integrity

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

https://github.com/guybedford/import-maps-extensions#integrity

Specification

https://github.com/whatwg/html/pull/10269

Summary

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.

Blink component

Blink>Loader

Motivation

Since modules initiate requests, there is a need for the ability to specify the integrity of dependencies, and not just the top level <script type="module"> integrity which can be supported via traditional means. For specifiers like import 'pkg' that are controlled by import maps, the problem is that the import map is fully responsible for the resolved module and hence the integrity of the resolved module as well. Without a mechanism to specify integrity, it is not currently possible to use module dependencies with `require-sri-for` Content Security Policy where those module dependencies are loaded lazily so that the integrity cannot be set via the module script tag or link preload tag directly.

Initial public proposal

https://github.com/whatwg/html/pull/10269

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: Slightly positive

• 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:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

The implementation adds a few console warnings in cases where developers made mistakes when authoring their import map's integrity section.

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

It will be

Flag name on chrome://flags

None

Finch feature name

ImportMapIntegrity

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/334251999

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157245026566144

This intent message was generated by Chrome Platform Status.

[Jeffrey Yasskin]

This looks great; thanks for working on it! One question:

My understanding is that there's an alternate design here in which the integrity information is attached to the `import` statements inside modules, which would allow developers to attach integrity information to url-based modules without needing to add import maps. However, IIUC that would cause caching problems since if a leaf dependency changed, all modules on the path to the root would also need to change their embedded integrity information, even if nothing else in those files changed. Am I right that the design you're actually implementing avoids that problem by concentrating integrity information in the import map?

Jeffrey

--
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/CAOmohS%2BKT_bhm7t%3DSK1jVkOcS7T%3DV_A8ZPgM6%3DB2%2Bt2vLQtc9Q%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Mon, Apr 15, 2024 at 8:17 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

This looks great; thanks for working on it! One question:

My understanding is that there's an alternate design here in which the integrity information is attached to the `import` statements inside modules, which would allow developers to attach integrity information to url-based modules without needing to add import maps. However, IIUC that would cause caching problems since if a leaf dependency changed, all modules on the path to the root would also need to change their embedded integrity information, even if nothing else in those files changed.

That would indeed be the issue with such a design. This is a current problem with hash based URL schemes, where any code change in any resource delivered to the browser invalidates all the resources that load it, and that invalidation then bubbles up the module tree. That can get even worse in cases of circular dependency. 

Import maps solve this very problem, and attaching the integrity hashes at the import site would be a regression.

Am I right that the design you're actually implementing avoids that problem by concentrating integrity information in the import map?

Indeed.

[Yoav Weiss (@Shopify)]

I somehow missed the fact that `require-sri-for` was removed. That doesn't change the value of this feature from my perspective.

[Hiroshige Hayashizaki]

my take tl;dr is: please proceed with being explicitly aware of the risk of changing import maps concept.

This will change the concept of import maps. Currently the import maps are contained within specifier resolution (and separated from loading/fetch-spec-exposed behavior), but after introducing integrity, it looks more like loading-related.
For long-term, I'm concerned this might lead to extending import maps into more loading features (other than SRI, other than module loading) which I personally feel not a super good idea as import maps is not the right place for accumulating loading features (i.e. import maps shouldn't be a manifest for general loading) and extending to non-module cases are anyway very hard (e.g. like another form of service workers).

But I don't want to block the proposal, if we really need the submodule SRI capability:

• This feature itself looks fine and makes sense as a module-specific way of SRI given that the missing SRI capability is a module script specific issue and is still contained within small parts of module loading.
  
• We haven't had any promising ideas for a general loading manifest for years, so I don't have good alternatives for the long term anyway.