Re: SRI fail open behaviour

This goes back to some of the early design suggestions where we had things
like src="safe_url" alt-src="CDN_url" alt-src-integrity="...".  We decided
to cut those features for Level 1.  I'm not sure how requiring at least one
valid hash recognized by an SRI-aware browser helps with the case where a
website wants to send a different link for browsers that don't do SRI at
all, or which don't recognize the algorithms chosen.

On Wed, Aug 5, 2015 at 9:48 AM Brian Smith <brian@briansmith.org> wrote:

> Francois Marier <francois@mozilla.com> wrote:
>
>> If we wanted to enforce integrity protection, we would have done
>> something like:
>>
>> <script integritysrc="safe.js" integrity="sha256-....">
>>
>> which would mean that only a browser with SRI support will load the
>> script.
>>
>
> I think that's only considering the case where SRI is "nice to have" vs
> the case where SRI is critical. For older browsers, you just can't safely
> send <script src=https://untrusted-cdn.example.com/foo.js>. My goal is to
> make it as safe as possible to send <script src=
> https://untrusted-cdn.example.com/foo.js integrity=sha256-ABC...> when
> you know the browser supports SRI when the distinction really significantly
> matters.
>
>
>> We didn't do that however, we made integrity a "bonus" for SRI-enabled
>> browsers while still loading the script in older browsers.
>>
>
> That's only one use case for SRI, and it's the least interesting one. The
> more interesting case is where the website feels it has to send a
> completely different link to non-SRI-supporting browsers.
>
>
>> > Consequently, I still think the best thing to do is to just make SRI
>> > fail closed if there is any problem (parsing or otherwise) with
>> > enforcing SRI.
>>
>> If we block loads on parsing errors, then we are essentially locking
>> ourselves into a specific syntax for the attribute, which would limit
>> what future versions of this spec can do.
>>
>> I agree there are UX benefits to failing closed, but there is a cost in
>> terms of future extensibility as well.
>
>
> That's easy to deal with. The SRI attribute is already defined to have a
> syntax of space-separated expressions. My suggestion is to require at least
> one of those expressions to be a syntactically-valid hash-with-options that
> identifies a digest that has been verified to match the content. If there
> is other stuff (junk or other unsupported algorithms), then that's not an
> issue, as long as there's one valid hash-with-options.
>
> Cheers,
> Brian
>
> --
> https://briansmith.org/
>
>