Re: SRI fail open behaviour

On 18/07/15 13:44, Brian Smith wrote:
>     - Chrome 80 will load this just fine because it implements "sha3"
>     - IE 9 will load it too because it doesn't have support for SRI at all
>     - Firefox 42 would block it because it supports SRI but not sha3
> 
> 
> All three would be doing the right thing. The web page is saying "I
> don't trust the server. I would rather have the load fail than have you
> load content that doesn't have a SHA-3 hash of 'Gk5l2Bi....'." If the
> page author wanted Firefox 42 to be able to load the page, then they
> would test in in Firefox 42, see that it doesn't work, and then either
> add a SHA-2 hash or decide that SHA-2 is too unsafe to rely on.

That's one way of explaining what the author intended to do. Another is
that the author was keen to move to a better hash algorithm and didn't
think about (or test with) older versions of Firefox. From a web
compatibility point of view, Firefox is broken and Chrome and IE9 are
just fine.

> From a usability standpoint, it is hard to see why a developer would add
> an integrity attribute at all unless they want the fail-closed behavior.
> It's much harder to write a proper test that every integrity attribute
> has the correct syntax. However, it is pretty easy to notice when your
> JS code doesn't run because a typo in the integrity attribute blocked
> the load.

It's not as good, but there is another way to spot the typo: console
warnings.

> Note that [MIX] has fail-closed behavior: if you make a typo "http://"
> instead of "https://" then the resource does not load.

Sure, but the MIX spec would be a no-op if it were to fail open :)

Francois

Received on Sunday, 19 July 2015 21:33:42 UTC