Thanks for reviewing!! In discussions with Mozilla folk, we eventually landed on a very different API shape <https://github.com/w3c/webappsec-subresource-integrity/pull/129#issuecomment-2757716392>, to enable them to expand the concept of "integrity policy", rather than doing this as a one-off CSP directive. As a result, I'd need to revamp the implementation and spec. I'll let y'all know when it's time to reapprove (I can do that as a separate intent, if that would be more convenient)
On Wed, Mar 26, 2025 at 11:02 AM Chris Harrelson <chris...@chromium.org> wrote: > LGTM3 > > On Tue, Mar 25, 2025 at 6:48 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> >> On 3/24/25 10:24 PM, Domenic Denicola wrote: >> >> >> >> On Mon, Mar 24, 2025 at 4:37 PM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> >>> >>> On Mon, Mar 24, 2025 at 6:45 AM Domenic Denicola <dome...@chromium.org> >>> wrote: >>> >>>> Great to hear! >>>> >>>> I see you've already updated the spec PR. My instinct is that we should >>>> give folks a week-ish to react to the new name, finish the spec review, >>>> etc. What do you think? >>>> >>> >>> Normally I would think this makes perfect sense. But given the 136 >>> branch point a week from now, I prefer one of the two options: >>> * Enable the flag in 136 before it branches and revert in the unlikely >>> case there's some disagreement on the spelling. >>> >> >> This option sounds good to me. LGTM1. >> >> Me too, LGTM2 >> >> >> >>> * Get help from Google folks to Finch enable it in 136 after branch >>> point. >>> >>> Does that make sense? >>> >>> >>>> (Also, I can't quite understand what's blocking the spec PR from >>>> landing... I guess there's still some discussion about whether the bar is >>>> "2 interested implementers" or "2 actively implementing implementers"? >>>> Maybe it's worth poking to see if you can get more clarity on that?) >>>> >>> >>> I believe it's held back on getting SRI L2 to FPWD >>> <https://lists.w3.org/Archives/Public/public-webappsec/2025Mar/0011.html> >>> (as a future Living Standard), and then potentially on getting a working >>> mode agreed on, and for the PR to meet it. So it may take a while to land >>> the PR. >>> >>> +Mike West <mk...@chromium.org> - Is my understanding correct? >>> >>> >>>> On Mon, Mar 24, 2025 at 2:28 PM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> Following discussions >>>>> <https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-03-19-minutes.md#require-sri-for-compatibility-and-spelling> >>>>> at WebAppSec and the WAICT >>>>> <https://docs.google.com/document/d/16-cvBkWYrKlZHXkWRFvKGEifdcMthUfv-LxIbg6bx2o/edit?tab=t.0> >>>>> proposal, I'm renaming the directive to `integrity-required`. (CL >>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/6382018>) >>>>> >>>>> That would also reduce the compatibility risk to zero AFAICT. >>>>> >>>>> On Monday, March 10, 2025 at 10:55:02 AM UTC+1 Yoav Weiss wrote: >>>>> >>>>>> FWIW, I'm planning to discuss >>>>>> <https://github.com/w3c/webappsec/issues/668#issuecomment-2709995028> >>>>>> a syntax change at next week's WebAppSec meeting, that can help us avoid >>>>>> these compat issues. >>>>>> >>>>>> On Tue, Feb 25, 2025 at 7:54 PM Yoav Weiss (@Shopify) < >>>>>> yoavwe...@chromium.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 25, 2025 at 6:08 PM Mike Taylor <miketa...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 2/24/25 4:24 PM, Yoav Weiss (@Shopify) wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 24, 2025 at 7:18 PM Mike Taylor <miketa...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 2/21/25 8:33 AM, Yoav Weiss (@Shopify) wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, February 20, 2025 at 1:56:59 PM UTC+1 Yoav Weiss >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, February 20, 2025 at 11:47:00 AM UTC+1 Yoav Weiss >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Contact emailsyoavwe...@chromium.org >>>>>>>>> >>>>>>>>> Explainerhttps://github.com/w3c/webappsec-subresource-inte >>>>>>>>> grity/pull/129#:~:text=for%20some%20assets.-,require%2Dsr >>>>>>>>> i%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20 >>>>>>>>> >>>>>>>>> Specificationhttps://github.com/w3c/webappsec-subresource- >>>>>>>>> integrity/pull/129 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The feature and PR were discussed >>>>>>>>> <https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-02-19-minutes.md#reviving-require-sri-for> >>>>>>>>> at the WebAppSec WG call. >>>>>>>>> >>>>>>>>> No objection beyond questions on whether we'd need to expand this >>>>>>>>> to cover stylesheets as well. We'd be able to do that in the future >>>>>>>>> (as a >>>>>>>>> separate intent) if needed. >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The `require-sri-for` directive 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 CSP violation report. >>>>>>>>> This >>>>>>>>> intent covers the "script" value of this directive. >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink componentBlink>SecurityFeature>ContentSecurityPolicy >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EContentSecurityPolicy%22> >>>>>>>>> >>>>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1048 >>>>>>>>> >>>>>>>>> TAG review statusPending - No response just yet >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> On the compatibility front: >>>>>>>>> >>>>>>>>> This directive was already implemented in the past, and there are >>>>>>>>> some developer docs >>>>>>>>> <https://udn.realityripple.com/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for> >>>>>>>>> that still describe it. The current PR and implementation did not >>>>>>>>> diverge >>>>>>>>> from the past implementation. >>>>>>>>> >>>>>>>>> >>>>>>>>> If developers deployed the feature in the past and are now relying >>>>>>>>> on it *not really working*, that may result in surprising >>>>>>>>> breakage. The HTTPArchive shows *0.0011% of page responses* (178 >>>>>>>>> out of 15760519) have an existing `require-sri-for` directive. >>>>>>>>> That's an upper bound - only those that enforce scripts, and have no >>>>>>>>> integrity attributes on some scripts may get broken. >>>>>>>>> >>>>>>>>> >>>>>>>>> Doing some more HA digging I found that it's 153 sites, which is >>>>>>>>> not significantly different. >>>>>>>>> I downloaded their URLs >>>>>>>>> <https://docs.google.com/spreadsheets/d/1NlFHLytc8lQcdP5FXXDltKEPQVE0e8oyjw9k1S-9KPI/edit?usp=sharing> >>>>>>>>> and >>>>>>>>> started going to these sites with the feature enabled. >>>>>>>>> Of those 153, 22 had any blocked assets, 9 had broken >>>>>>>>> functionality or layout and 1 had missing ads. >>>>>>>>> Non-visiblity broken but blocked sites mostly had their analytics >>>>>>>>> blocked. >>>>>>>>> >>>>>>>>> Extrapolating that data brings us to 0.000158% for any blocked >>>>>>>>> assets, and 0.000065% for broken functionality. >>>>>>>>> >>>>>>>>> I'm planning to reach out to the broken sites and make them aware >>>>>>>>> of this change. Many of them seem to be coming from a single provider >>>>>>>>> (similar site and breakage). >>>>>>>>> >>>>>>>>> >>>>>>>>> I also found ~3500 sites that have the `require-sri-for` string in >>>>>>>>> their response bodies (and hence may have it applied). >>>>>>>>> I put together a script that so far scanned ~1800 of them and >>>>>>>>> found no blocked assets. So, it seems like the risk is very low on >>>>>>>>> that >>>>>>>>> front. >>>>>>>>> >>>>>>>>> Thanks, I appreciate you digging in to understand the possible >>>>>>>>> risks. My understanding of the compat risk goes something like >>>>>>>>> (please let >>>>>>>>> me know if I'm missing something): >>>>>>>>> >>>>>>>>> 1. This feature never really shipped, but was implemented behind a >>>>>>>>> flag. >>>>>>>>> >>>>>>>>> 2. Early adopter developers (or menu framework authors?) added >>>>>>>>> require-sri-for for some scripts that they wanted to lock down >>>>>>>>> >>>>>>>> Tiny correction: they added it to the document's CSP, not specific >>>>>>>> scripts. >>>>>>>> >>>>>>>>> (to prevent 3rd-party attackers from modifying them, etc). >>>>>>>>> >>>>>>>>> 3. Now, you actually ship the feature. >>>>>>>>> >>>>>>>>> That means the risks are: >>>>>>>>> >>>>>>>>> a) Some CDN was compromised at some point, and now some sketchy >>>>>>>>> scripts will fail to load. Seems like that's security positive, even >>>>>>>>> if it >>>>>>>>> surprises users or developers. >>>>>>>>> >>>>>>>>> b) Perhaps more likely, a page was redesigned and they updated >>>>>>>>> their analytics provider but didn't remember to add hashes. Now some >>>>>>>>> things >>>>>>>>> don't work. >>>>>>>>> >>>>>>>> I suspect it's >>>>>>>> c) they added the header but never actually tested with the feature >>>>>>>> enabled, as it never shipped. >>>>>>>> >>>>>>>> It seems like they added the CSP header, but never added an >>>>>>>> "integrity" attribute to many/most of their scripts. >>>>>>>> >>>>>>>> >>>>>>>>> From your sheet (which is great, thanks), it seems like largest >>>>>>>>> impact is busted menus. Is this a single library? Or common pattern? >>>>>>>>> >>>>>>>>> It seems like a common provider. 6 out of the 9 sites with issues >>>>>>>> are Canadian health/edu related sites. >>>>>>>> >>>>>>>> Breaking health/edu-releated sites is not good... >>>>>>>> >>>>>>> Indeed, although I'm not sure how load-bearing they are.. >>>>>>> >>>>>>>> When broken, is it cosmetic, or are the links in the menu still >>>>>>>> accessible? (I see you're gathering contact info - let me know if you >>>>>>>> need >>>>>>>> help with that.) >>>>>>>> >>>>>>> It seems like the desktop view is functional, but the mobile view's >>>>>>> hamburger menu is not working (at least in some cases). >>>>>>> >>>>>>>> Assuming we can sort out the menu breakage somehow, I think for the >>>>>>>> rest - the best we can do is roll it out and be ready to killswitch if >>>>>>>> needed. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Gecko*: No signal (https://github.com/mozilla/st >>>>>>>>> andards-positions/issues/1173) >>>>>>>>> >>>>>>>>> *WebKit*: No signal (https://github.com/WebKit/sta >>>>>>>>> ndards-positions/issues/458) >>>>>>>>> >>>>>>>>> *Web developers*: Shopify is interested in this. I suspect PCIv4 >>>>>>>>> <https://docs.google.com/document/d/1RcUpbpWPxXTyW0Qwczs9GCTLPD3-LcbbhL4ooBUevTM/edit?tab=t.0> >>>>>>>>> would >>>>>>>>> make some developers interested in making sure their documents' >>>>>>>>> scripts >>>>>>>>> have complete integrity checks. >>>>>>>>> >>>>>>>>> *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://wpt.fyi/results/content-security-policy/tentative/ >>>>>>>>> require-sri-for?label=experimental&label=master&aligned >>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5877633> >>>>>>>>> >>>>>>>>> >>>>>>>>> Flag name on about://flagsNone >>>>>>>>> >>>>>>>>> Finch feature nameCSPRequireSRIFor >>>>>>>>> >>>>>>>>> Requires code in //chrome?False >>>>>>>>> >>>>>>>>> Estimated milestonesShipping on desktop135DevTrial on >>>>>>>>> desktop134Shipping >>>>>>>>> on Android135DevTrial on Android134Shipping on WebView135 >>>>>>>>> >>>>>>>>> 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 Statushttps://chromestatus. >>>>>>>>> com/feature/5090023365672960?gate=5186570942152704 >>>>>>>>> >>>>>>>>> Links to previous Intent discussionsIntent to Prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ >>>>>>>>> CAOmohSJUygAmobR9dRkDr%3DBWQ1h5hv2Lj3WUFN31QZF360A47A >>>>>>>>> %40mail.gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d3107ca-61cc-47f6-badd-8bc6a1f30145n%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d3107ca-61cc-47f6-badd-8bc6a1f30145n%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/49037f78-2795-4d2e-9645-361e632c61f7n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/49037f78-2795-4d2e-9645-361e632c61f7n%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/0b112bbd-5132-4d64-a85f-78afb6ba3005%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b112bbd-5132-4d64-a85f-78afb6ba3005%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/CAOmohSJq3AEVDmW%2BnOzZm12%2BoOYq0ap%2B0vV_s0k6znXA8sk8sg%40mail.gmail.com.
