Intent to Ship: Subresource Integrity

[Joel Weinberger]

Contact emails

Blink implementor and spec editor:

j...@chromium.org

Other spec editors:

fran...@mozilla.com, fbr...@mozilla.com, d...@dropbox.com

Spec

https://w3c.github.io/webappsec/specs/subresourceintegrity/

Tag review info (upcoming):

https://github.com/w3ctag/spec-reviews/issues/43

Summary

Adds support for a new 'integrity' attribute for <link> and <script> elements that allows a developer to specify a hash value (or set of hash values) for the content of the resource. If the response for the resource does not match one of the hashes, it is a network error. Only applies to same origin or CORS enabled fetches.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement conversation: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hTDUpMk_TV8

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

None.

Debuggability

Console messages implemented for mismatching content and hashes.

Compatibility Risk

I believe the compatibility risk for this feature to be low. We have kept the syntax open for extensions to the feature going forward (such as specifying content types), so it is unlikely that we would invalidate usage of V1 syntax features. There is a chance we will deprecate particular hash functions that become insecure in the future, but that's built into the spec and feature.

OWP launch tracking bug?

https://crbug.com/355467

Entry on the feature dashboard

https://www.chromestatus.com/feature/6183089948590080

[Chris Harrelson]

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Is this an intent to ship everything currently behind the
SubresourceIntegrity flag? The spec only defines
HTMLLinkElement.integrity and HTMLScriptElement.integrity, but in our
IDL files the integrity attribute is also on HTMLAnchorElement,
HTMLEmbedElement, HTMLIFrameElement, HTMLImageElement,
HTMLMediaElement, HTMLObjectElement, HTMLSourceElement and
HTMLTrackElement. (These are decorated with FIXME/TODO.)

AFAICT, SRI is only supported on HTMLLinkElement and HTMLScriptElement
(via dom/ScriptLoader.cpp), i.e. what the spec says. Can the integrity
attribute be removed in the other contexts before shipping, so that
their future support can be feature detected?

[Joel Weinberger]

Philip, great call. Yes, this is only meant to be for HTMLLinkElement.integrity and HTMLScriptElement.integrity, so I'll submit a CL later today removing it from the other IDLs.

--Joel

[Philip Jägenstedt]

Thanks Joel, LGTM2!

[Jochen Eisinger]

lgtm3

[Yoav Weiss]

Yay! :)

Any idea where Mozilla are at with regard to their implementation?

[Frederik Braun]

We're waiting for code review. If all goes well it will land in Firefox
Nightly in a few weeks.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=992096

> <chri...@chromium.org <mailto:chri...@chromium.org>>

> >> wrote:
> >> > LGTM
> >> >
> >> > On Fri, May 29, 2015 at 4:15 PM, Joel Weinberger

> <j...@chromium.org <mailto:j...@chromium.org>>

> >> > wrote:
> >> >>
> >> >> Contact emails
> >> >>
> >> >> Blink implementor and spec editor:
> >> >>

> >> >> j...@chromium.org <mailto:j...@chromium.org>
> >> >>
> >> >>
> >> >> Other spec editors:
> >> >>
> >> >> fran...@mozilla.com <mailto:fran...@mozilla.com>,
> fbr...@mozilla.com <mailto:fbr...@mozilla.com>, d...@dropbox.com
> <mailto:d...@dropbox.com>

> <mailto:blink-dev%2Bunsu...@chromium.org>.

> >> >
> >> >
> >> > To unsubscribe from this group and stop receiving emails
> from it, send
> >> > an
> >> > email to blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>.

>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.
>
>

[Yoav Weiss]

On Tue, Jun 2, 2015 at 8:12 AM, Frederik Braun <fbr...@mozilla.com> wrote:

We're waiting for code review. If all goes well it will land in Firefox
Nightly in a few weeks.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=992096

 

Double yay then! :) 

[Mike West]

Non-OWNERS LGTM from me as well, I'm happy to see you folks getting this done!

Do both browsers pass the tests at https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity? It's sometimes complicated to ensure that the same thing is being hashed, so it would be excellent if that test suite could be fleshed out a bit as part of launching this feature cross-browser.

-mike

[Francois Marier]

On 02/06/15 17:39, Mike West wrote:
> Do both browsers pass the tests
> at https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity?

Not yet: https://github.com/w3c/web-platform-tests/pull/1853

Francois

[Mike West]

Ok. Glad you're on top of it!

Are the fixed hashes in your PR enough to make both Chrome and Firefox happy? Or do the browsers disagree on the digesting behavior?

-mike

[Erik Dahlstrom]

Are there any particular reasons for not having this on <svg:script> too?
/ed

On Mon, 01 Jun 2015 14:17:06 +0200, Philip Jägenstedt <phi...@opera.com>
wrote:

--
Using Opera's mail client: http://www.opera.com/mail/

[Joel Weinberger]

No, there are no particular reasons, other than time :-) We are planning on extending SRI in the future with other elements (for example, iframe, a, object, etc: see https://github.com/w3c/webappsec/issues/210 as an example), and if you believe <svg:script> would be a particularly logical next step (it certainly seems so to me), it would be awesome if you could file a feature request on GitHub: https://github.com/w3c/webappsec/labels/SRI

--Joel