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. * 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/CAOmohSJA_vBMWkmdR_fgvSPm7yQ3HjXawkNA5RtaLuXUR9LHyA%40mail.gmail.com.
