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) < yoavwe...@chromium.org> wrote: > > > On Mon, Apr 15, 2024 at 8:17 PM Jeffrey Yasskin <jyass...@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. > > >> >> Jeffrey >> >> On Mon, Apr 15, 2024 at 7:46 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> Contact emailsyoavwe...@chromium.org >>> >>> 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 blink-dev+unsubscr...@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 >>> <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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKGWRW8z2EaLu_9qiv_DtyWgfq2T8VrhfBg16f%3DbfHFuw%40mail.gmail.com.
