LGTM2 On Wednesday, August 13, 2025 at 8:14:58 AM UTC-7 sligh...@chromium.org wrote:
> LGTM1, can we get SRI for images next? ;-) > > Best, > > Alex > > On Wednesday, August 13, 2025 at 3:37:10 AM UTC-7 Chromestatus wrote: > >> Contact emails mk...@chromium.org >> >> Explainer https://github.com/WICG/signature-based-sri >> >> Specification https://wicg.github.io/signature-based-sri >> >> Summary >> >> This feature provides web developers with a mechanism to verify the >> provenance of resources they depend upon, creating a technical foundation >> for trust in a site's dependencies. In short: servers can sign responses >> with a Ed25519 key pair, and web developers can require the user agent to >> verify the signature using a specific public key. This offers a helpful >> addition to URL-based checks offered by Content Security Policy on the one >> hand, and Subresource Integrity's content-based checks on the other. >> >> >> Blink component Blink>SecurityFeature>Subresource Integrity >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ESubresource%20Integrity%22> >> >> >> Search tags sri <http:///features#tags:sri>, signature >> <http:///features#tags:signature>, ed25519 >> <http:///features#tags:ed25519>, integrity >> <http:///features#tags:integrity>, provenance >> <http:///features#tags:provenance> >> >> TAG review https://github.com/w3ctag/design-reviews/issues/1041 >> >> TAG review status Pending >> >> Origin Trial Name Signature-based SRI >> >> Chromium Trial Name SignatureBasedIntegrity >> >> Origin Trial documentation link >> https://github.com/WICG/signature-based-sri >> >> WebFeature UseCounter name kSRIPublicKeyAssertion >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal ( >> https://github.com/mozilla/standards-positions/issues/1139) >> >> *WebKit*: Support ( >> https://github.com/WebKit/standards-positions/issues/434) >> >> *Web developers*: No signals Shopify (@yoavweiss) has expressed positive >> initial impressions, as have folks at Cloudflare and Google. >> >> *Other signals*: >> >> Ergonomics >> >> The hash functions we currently support for SRI generally are not >> conducive to streaming responses. This is arguably fine for scripts and >> stylesheets (as those are executed atomically, requiring the entire body), >> but it cannot work for other resource types (images, video, etc). It's >> likely we'll want to extend the set of hash functions in the future (though >> we'd do that for SRI, CSP, and this mechanism in one fell swoop). >> >> >> Activation >> >> None. >> >> >> Security >> >> The feature aims to plug a security hole in the platform's status quo >> ante: it is impossible to deploy content-based integrity checks for dynamic >> resources, and URL-based checks are too broad to provide meaningful >> security protections. We continue to require CORS-based opt-in for >> integrity checks on responses to ensure that we're not leaking data >> unintentionally between origins. >> >> >> 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 >> >> `Signature` and `Signature-Input` header parsing and validation is >> well-covered with DevTools issues. The same is true for `Unencoded-Digest` >> parsing and enforcement. >> >> >> 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/subresource-integrity/unencoded-digest?label=experimental&label=master&aligned >> >> https://wpt.fyi/results/subresource-integrity/signatures?label=experimental&label=master&aligned >> >> >> Flag name on about://flags signature-based-sri >> >> Finch feature name SignatureBasedIntegrity >> >> Rollout plan Will ship enabled for all users >> >> Requires code in //chrome? False >> >> Tracking bug https://issues.chromium.org/issues/375224898 >> >> Estimated milestones >> Shipping on desktop 141 >> Origin trial desktop first 135 >> Origin trial desktop last 141 >> Shipping on Android 141 >> Origin trial Android first 135 >> Origin trial Android last 141 >> Shipping on WebView 141 >> Origin trial WebView first 135 >> Origin trial WebView last 141 >> >> 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 Status >> https://chromestatus.com/feature/5032324620877824?gate=5079751293927424 >> >> Links to previous Intent discussions Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6753088f.2b0a0220.1432c2.020a.GAE%40google.com >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67b8a89e.2b0a0220.175b17.0a0c.GAE%40google.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/0f48ef05-9d94-4fd1-9009-681bedc9f200n%40chromium.org.
