SRI: Integrity enforcement on downloads

[jfbastien]

Gaming companies often host binaries through a CDN, and these CDNs sometimes also host unwanted software. Browsers rely on technologies such as Safe Browsing and think the binary is unsafe because other binaries on the CDN are unsafe.

If coolgames.com uses SRI and says "get coolgame.exe from randoCDN.com, here's what the checksum is" then the browser should check the credentials of coolgames.com, not randocdn.com. Safe browsing stays the same, but the browser is a bit smarter about the question it asks.

@adrifelt points out that my idea is a bit naive since it's very common for a compromised site (currentlyevil.com) to point to a resource from another site (randoCDN.com). If we only use the reputation of the compromised site, we will end up not flagging the bad content.

Ideally CDNs would follow some form of best-practice on setting up sub-domains for each of their customers, and would also set up CORS properly so what I describe is easy.

@metromoxie said he'd drive this.

[briansmith]

Safe browsing is not a W3C thing so isn't this out of scope?

[jfbastien]

Safe browsing is just an example of where this signal would be useful. I basically want developers to be able to express ownership of binaries, and help CDNs set up their hosting of these binaries properly so it's easier for everyone to figure out what to trust and what not to trust.

[briansmith]

What W3C-standard mechanism would be affected by this, then?

[mozfreddyb]

@jfbastien something like this? ;)

<a href="https://foocdn.example/trustworthy.exe"
   integrity="sha384-filecontenthashed"
   download="trustworthy.exe">download</a>

[jfbastien]

@mozfreddyb that's what I naïvely think would work, but I'll leave it to you experts to suggest something that will actually work.

[joelweinberger]

I see a straightforward path forward for this for files with Content-Disposition: attachment, but the semantics are much more complicated for, say, another HTML page (we can't wait for a page to completely load before executing, for example).

[joelweinberger]

Sorry, I should also add some clarification and context. I think @jfbastien is citing reasons that it would be useful for Safe Browsing to have SRI be enforced. I agree that this is not a reason per se to make changes to SRI, however, I think there's much more general value in enforcing SRI on downloads since, just like a script, a CDN or third-party source could serve a different download from what's expected, leading to compromise.

@briansmith, can you clarify if agree or disagree that there's value in having SRI on downloads?

[mozfreddyb]

Yeah. To clarify, I meant to include a download in this anchor above :)
(Added after the fact by editing the comment).

[briansmith]

@briansmith, can you clarify if agree or disagree that there's value in having SRI on downloads?

I absolutely agree it would useful, and I'm looking forward to seeing it. I also think it is worth considering aspects of the implementation that might affect Safe Browsing. But, I don't think (parts of) Safe Browsing or similar should end up in the spec.

[jfbastien]

Agreed that Safe Browsing shouldn't be in the spec. It just happens to be a good justification. I should have focused on the more obvious uses first :-)

[jayaddison]

Find also w3c/webappsec-subresource-integrity#68 for a separate discussion (Y2017 onwards) of the same feature request.