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

Re: [integrity] What should we hash?

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 15 Mar 2014 05:38:20 +1100
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-Id: <164995F7-DD49-4A7B-80A8-D2FA1EBA4514@mnot.net>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
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"        

(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

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