Hey folks! I now have a CL <https://chromium-review.googlesource.com/c/chromium/src/+/6408111> for Integrity-Policy (that also removes the require-sri-for implementation), and a PR <https://github.com/w3c/webappsec-subresource-integrity/pull/133> is being reviewed.
Should I send a new intent for this? Or can we assume that this intent is still valid, despite the now inaccurate name? On Thu, Mar 27, 2025 at 10:04 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > 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/CAOmohSK%3DGs4hkSgirwRjkyKiiVveDR_XFb7Xc%2BggY%3DJ4jxqW2g%40mail.gmail.com.
