totally fair to consider for sriv2. More curious about implementor interest.

You guys tricked me into this again:) I'll take it.

Apple wants it (see https://www.w3.org/2016/05/16-webappsec-minutes.html#item02 (+@johnwilander to confirm)). I wouldn't mind implementing in Chrome (though @metromoxie is the right person to ask).

Oh I thought @devd meant feature implementor in the spec.

@mikewest does Chrome support this in some way? Asking because of validator/validator#764 (comment).

UA: YaBrowser 19.1.1.907 (64-bit)

All other inline scripts will run, but if, and only if, they contain integrity attribute with a valid SRI.

@JHabdas could you create a minimal test? (I.e., a document with everything that isn't necessary to show the problem removed.)

@annevk https://jhabdas.keybase.pub/after-dark-w3c-sri-44.htm reduced test case

@JHabdas that still contains an awful lot of noise. Surely all the style elements, SVG, etc. isn't needed? Seems to me you'd only need some CSP and a script element.

Feel free to ad lib. I don't like looking at stark white pages.

@annevk: I missed this earlier, sorry I'm only seeing it now.

Chrome's behavior is strange and buggy:

In the absence of CSP: <script integrity="[any string at all]">...</script> will execute, as will <script integrity="[correct integrity metadata]">...</script>.

In the presence of CSP: <script integrity="[correct integrity metadata]">...</script> and <script integrity="[incorrect, but matching the policy, integrity metadata]">...</script> will execute, while <script integrity="[correct, but doesn't match the policy]">...</script> won't.

I think we screwed up our implementation of https://w3c.github.io/webappsec-csp/#external-hash. The right way to fix it, IMO, is to do the work to define the integration of SRI with inline script, and to fix the text in CSP to match. Since I probably screwed up Chrome's implementation, I'll take responsibility for the spec work and find someone to fix Chrome accordingly. :/