- From: Mike West <mkwst@google.com>
- Date: Fri, 24 Oct 2014 12:00:24 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CAKXHy=f=fhKjKx8UX=ck7RXqhfWstX3x=W+5KJn4MLTDiZ=4Dg@mail.gmail.com>
The security improvement we get from integrity checks comes from the fact that the digest is delivered out-of-band with the resource. If jQuery's server is compromised, it's only the sloppiest of attackers who would update the resource, but not the headers. It's not clear to me what benefit we'd obtain from a response header that contained information that could be easily calculated from the resource itself. Could you explain the use-case a little bit? -mike -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Fri, Oct 24, 2014 at 5:47 AM, Mark Nottingham <mnot@mnot.net> wrote: > Has there been any discussion of how the integrity information is > associated with a resource? > > I think using the integrity attribute on the link makes sense for the most > current use case -- assuring that off-site content (e.g., on a CDN) is what > you think it's going to be. That's because in these cases, the URL is most > likely to be a version-specific one (<e.g., > https://cdn.com/foolib.1.2.3.js>), so if the author wants to update the > library version used, they'll need to update the link, and the integrity > information is right next to it. > > However, in the cache reuse case -- which seems to be getting *some* > traction (or at least consideration) -- next to the link is about the worst > place the integrity information can go; if the author updates the library, > they'll need to update each and every instance of a link to it, which can > be quite onerous. > > In that use case, it makes more sense to put integrity information into > HTTP headers or even a separate resource, so that it can more easily be > updated (e.g., by a separate process, or automatically by the server at > response time). > > So, I'm wondering if the WG would consider allowing integrity information > to be carried in HTTP response headers (e.g., Link), at least for the cache > reuse case. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > >
Received on Friday, 24 October 2014 10:01:13 UTC