Re: [integrity] What should we hash?

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