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. On Mon, Apr 15, 2024 at 6:49 PM Yoav Weiss (@Shopify) < [email protected]> wrote: > I somehow missed the fact that `require-sri-for` was removed. That doesn't > change the value of this feature from my perspective. > > On Mon, Apr 15, 2024 at 9:39 PM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Mon, Apr 15, 2024 at 8:17 PM Jeffrey Yasskin <[email protected]> >> 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. >> >> >>> >>> Jeffrey >>> >>> On Mon, Apr 15, 2024 at 7:46 AM Yoav Weiss (@Shopify) < >>> [email protected]> wrote: >>> >>>> Contact [email protected] >>>> >>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity >>>> >>>> Specificationhttps://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 componentBlink>Loader >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>> >>>> 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 proposalhttps://github.com/whatwg/html/pull/10269 >>>> >>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944 >>>> >>>> TAG review statusPending >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> None >>>> >>>> >>>> *Gecko*: No signal >>>> <https://github.com/mozilla/standards-positions/issues/1010> >>>> >>>> *WebKit*: No signal >>>> <https://github.com/WebKit/standards-positions/issues/335> >>>> >>>> *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 >>>> <https://twitter.com/yoavweiss/status/1778067431417954803> and >>>> mastodon <https://mastodon.social/@Yoav/112247393918965759> 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 >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5441822> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?It will be >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5441822> >>>> >>>> Flag name on chrome://flagsNone >>>> >>>> Finch feature nameImportMapIntegrity >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5441822/11/third_party/blink/renderer/platform/runtime_enabled_features.json5> >>>> >>>> Non-finch justificationNone >>>> >>>> Requires code in //chrome?False >>>> >>>> Tracking bughttps://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 >>>> <https://chromestatus.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 [email protected]. >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BKT_bhm7t%3DSK1jVkOcS7T%3DV_A8ZPgM6%3DB2%2Bt2vLQtc9Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaYce5MGsXBzw6K_py5yEj_Vx6o_%3DA4CecJm_gaAyU7H6wfPQ%40mail.gmail.com.
