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 <mailto: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-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20
<https://github.com/w3c/webappsec-subresource-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20>
Specificationhttps://github.com/w3c/webappsec-subresource-integrity/pull/129
<https://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
<https://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/standards-positions/issues/1173
<https://github.com/mozilla/standards-positions/issues/1173>)
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/458
<https://github.com/WebKit/standards-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
<https://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
<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/b08e17db-d207-4053-9580-0560d7722d9e%40chromium.org.
