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/CAOmohSJQFBJEASLqrzh37F%2BrOdSEW2rr5fVEgQhRU2a3QHssOA%40mail.gmail.com.
