- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 15 Mar 2014 05:38:20 +1100
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I think this came up before, and my suggestion was to flag whether or not the hash was computed on the encoded or unencoded representation; e.g., <script src="https://code.jquery.com/jquery-1.10.2.min.js” encoding=“gzip" integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript”> (just a straw syntax) That way, a client that supports gzip will send their request and calculate the hash based upon the gripped content; one that doesn’t support gzip (a rarity) will ignore the hash (i.e., behave as if it weren’t there). This approach has its own problems, of course, but I kinda like it... On 15 Mar 2014, at 1:26 am, Boris Zbarsky <bzbarsky@MIT.EDU> wrote: > On 3/14/14 2:51 AM, Devdatta Akhawe wrote: >> 4. To verify that the hash matches, browser undoes the Content >> encoding and checks the hash. If hash doesn't match, the browser tells >> user and throws away the download. >> 5. If the hash matched, then browser, as usual, saves a foo.tar.gz >> file to the user's harddisk. > > So the browser needs to both be streaming the compressed data to disk and teeing it off to a decompression stream which computes the hash as it goes, right? Or alternately decompressing and then recompressing? > >> I don't deny this is ugly but I can't see a better mechanism than >> this. The .tar.gz case with an integrity attribute really is the >> exception, imho > > It is? I'd think integrity for downloads would be a common desire. People certainly do that now, with posting hashes that recipients of a download should expect... > > On the other hand, if this spec is all about subresource integrity, then maybe it should just be ignored for downloads? > >> and we shouldn't optimize for it. > > I'm not convinced we should overcomplicate the already complicated data flow for saving files to handle integrity, honestly. If we can find a way of avoiding that, it would be nice. It's not a hard requirement, but if we actually want this stuff to get implemented... > > I realize we have a problem here in that Content-Encoding is being used in different ways by different consumers, some of whom want it to be treated like Transfer-Encoding (because browsers don't support Transfer-Encoding:gzip!), which complicates the situation enormously. > > -Boris -- Mark Nottingham http://www.mnot.net/
Received on Friday, 14 March 2014 18:38:50 UTC