Re: [integrity] What should we hash?

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

Received on Friday, 14 March 2014 14:27:09 UTC