Thanks for the LGTMs!! The code for this didn't make the 137 branch, so I'm now aiming for M138.
The PR discussions raised one salient question regarding worker support <https://github.com/w3c/webappsec-subresource-integrity/pull/133#discussion_r2063359380>. That ended up convincing me that for consistency, the spec's processing could properly handle `Integrity-Policy` support in Workers, even if that's not a use case I'm currently interested in tackling. The functional impact of that in practice would be that if a Service-Worker receives an `Integrity-Policy: blocked-destinations=(script)` header, it would require integrity metadata on outgoing requests that maintain their "script" destination (e.g. pass through script requests from the document). This is something I'm *not planning to cover *in the current intent. There's a small risk that developers may start relying on `Integrity-Policy` being a noop in workers. I'm thinking that adding a use counter for the presence of `Integrity-Policy` headers in Service Workers can provide us with enough heads-up if developers start sending those headers there, and would enable us to react to that. Does that make sense to y'all? On Wed, Apr 23, 2025 at 5:38 PM 'Dan Clark' via blink-dev < blink-dev@chromium.org> wrote: > LGTM3 > > On Wednesday, April 23, 2025 at 8:34:55 AM UTC-7 Chris Harrelson wrote: > >> LGTM2, assuming the spec lands before the feature ships. >> >> On Wed, Apr 23, 2025 at 4:07 AM Mike Taylor <mike...@chromium.org> wrote: >> >>> LGTM1 >>> On 4/23/25 5:12 AM, Yoav Weiss (@Shopify) wrote: >>> >>> Contact emails yoav...@chromium.org >>> >>> Explainer >>> https://github.com/w3c/webappsec-subresource-integrity/pull/133 >>> >>> Specification >>> https://github.com/w3c/webappsec-subresource-integrity/pull/133 >>> >>> Summary >>> >>> Subresource-Integrity (SRI) enables developers to make sure the assets >>> they intend to load are indeed the assets they are loading. But there's no >>> current way for developers to be sure that all of their scripts are >>> validated using SRI. The Integrity-Policy header gives developers the >>> ability to assert that every resource of a given type needs to be >>> integrity-checked. If a resource of that type is attempted to be loaded >>> without integrity metadata, that attempt will fail and trigger a violation >>> report. >>> >>> >>> Blink component Blink>SecurityFeature>Subresource Integrity >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ESubresource%20Integrity%22> >>> >>> TAG review https://github.com/w3ctag/design-reviews/issues/1048 >>> >>> TAG review status Pending >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> None. This is a new header, so it has no compatibility concerns. In >>> terms of interoperability, despite the lack of official position, this was >>> co-designed with Mozilla folks, and they are planning >>> <https://github.com/w3c/webappsec-subresource-integrity/pull/133#discussion_r2046860967> >>> to follow suite AFAIK. >>> >>> >>> *Gecko*: No signal ( >>> https://github.com/mozilla/standards-positions/issues/1173) The syntax >>> was collaboratively worked on with Mozilla folks and was adapted to be >>> future-compatible with their plans on that front. At the same time, no >>> official signal just yet. >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/458) "reasonable >>> problem to solve" but no official signal yet. >>> >>> *Web developers*: Positive - Shopify is highly interested in this. I >>> suspect other developers who have to deal with PCI compliance would as >>> well. (there's also an ancient signal from Github >>> <https://lists.w3.org/Archives/Public/public-webappsec/2015Dec/0045.html> >>> ) >>> >>> *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 >>> >>> None >>> >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? Yes >>> >>> https://chromium-review.googlesource.com/c/chromium/src/+/6408111 >>> >>> >>> Flag name on about://flags None >>> >>> Finch feature name IntegrityPolicyScripts >>> >>> Rollout plan Will ship enabled for all users >>> >>> Requires code in //chrome? False >>> >>> Estimated milestones >>> Shipping on desktop 137 >>> Shipping on Android 137 >>> Shipping on WebView >>> >>> >>> 137 I'm aware 137 is... ambitious, given the code hasn't landed yet. >>> But I'm trying to reduce the delay the API shape change incurred. >>> >>> Anticipated spec changes >>> >>> 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). >>> None >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5178394056327168?gate=5167118408220672 >>> >>> 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+...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKm8K3oVnNLyLcKJuBGWs6C0kpGY%2Bu6WioOjc-%2BY2-p6Q%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKm8K3oVnNLyLcKJuBGWs6C0kpGY%2Bu6WioOjc-%2BY2-p6Q%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+...@chromium.org. >>> >> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f38962f7-62bc-43aa-a13c-d014c2475afc%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f38962f7-62bc-43aa-a13c-d014c2475afc%40chromium.org?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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ecfdf3a-889a-4734-9b15-ed50bbf853afn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ecfdf3a-889a-4734-9b15-ed50bbf853afn%40chromium.org?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJFE%3DurssEdhGGwiAPyNfqe-krxRT83ovhRiOCu46VOsg%40mail.gmail.com.
