Re: SRI fail open behaviour

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/