W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: [integrity] What should we hash?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 14 Mar 2014 10:26:39 -0400
Message-ID: <5323119F.3050306@mit.edu>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: Mark Nottingham <mnot@mnot.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC