W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

Re: SRI fail open behaviour

From: Francois Marier <francois@mozilla.com>
Date: Tue, 04 Aug 2015 19:20:32 -0700
Message-ID: <55C172F0.9090805@mozilla.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 28/07/15 11:53 AM, Brian Smith wrote:
> The whole point of SRI is to break pages when expectations are not met.
> The same with TLS and other security features. It isn't reasonable for
> anybody to expect their pages to work in older browsers without testing
> them in older browsers, *especially* when they are using the security
> features like SRI and CSP that this working group creates or even TLS.
> So the whole concern of protecting against breaking pages in older
> browsers is invalid, IMO.

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.

We didn't do that however, we made integrity a "bonus" for SRI-enabled
browsers while still loading the script in older 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.

Francois
Received on Wednesday, 5 August 2015 02:21:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:14 UTC