Makes sense! I'll send a new intent. On Mon, Apr 21, 2025 at 6:37 PM Mike Taylor <miketa...@chromium.org> wrote:
> Given that this is described as "very different", I think a new I2S would > be helpful. Or if you decide that's too annoying, at the very least could > you write up a minimal explainer (inline is fine) that describes the diff > from require-sri-for, and create a new chromestatus entry? > On 4/17/25 11:44 PM, Yoav Weiss (@Shopify) wrote: > > 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/CAOmohS%2Bzi-Ode-7KyUXe_xsn2mmS9J0cQM2ZFWhM4AkgiUr-GA%40mail.gmail.com.
