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

Re: [integrity] What should we hash?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 9 Apr 2014 12:11:37 -0500
Message-ID: <CAPfop_27BOSJN9kex7mN1H0KyVexfkjy=gi_w=4nj75Ufakiwg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Mark Nottingham <mnot@mnot.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> And require tarball downloads in browsers from a server that sent
> content-encoding:gzip to do a streaming decompress+recompress, right?
Or just not do a streaming decompress/recompress. If content-encoding:gzip
is sent but the browser didn't plan on doing a decompress already, the
browser can just fail.

If I am not wrong, if I want to download exe, pdf etc and the server sends
these with a content-encoding:gzip, browsers already do a decompress. The
only place where a decompress isn't done is something like: file is
foor.tar.gz, content-type is application/x-tar and content-encoding is
gzip. Browsers can fail SRI check for such downloads to avoid a streaming

If the server wants to use SRI for such files, it needs to use something
similar to what dropbox does: send it as "application/octet-stream" without
any content-encoding and specify a filename=foo.tar.gz in
content-disposition. Since this would be easily noticeable during testing,
I don't imagine it being a problem.

Again, as a UA developer it seems like a pretty positive property if I hash
> the bytes I'm already working with...
Absolutely! I agree, but spec ugliness can also be a negative. I am just
trying to find the least bad solution :)

Received on Wednesday, 9 April 2014 17:12:35 UTC

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