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. *Gecko*: No signal (https://github.com/mozilla/standards-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.goog le.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.
