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/CAOmohSJKgLc%3D0WFHqWNCEvc3UwgUBP2DbY4UE%3DMOS3Fkr5t30w%40mail.gmail.com.
