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/CAOMQ%2Bw-as7QkF-TkZeWawW0b-867rbG_DVPYa8u9We8heBL%3DcQ%40mail.gmail.com.
