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

Re: [integrity] What should we hash?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Fri, 14 Mar 2014 22:09:36 -0700
Message-ID: <CAPfop_3uf3MWQy55VhFkXQPrT_j77Dzu4NoWLNZpUBrx2=zmsw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Mark Nottingham <mnot@mnot.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> Unfortunately, the default web server in many cases is to serve .tar.gzip
> files with Content-Encoding: gzip, at least last I checked.

Yeah, and this was actually why I agreed with you throughout. In fact,
right before I sent this new suggestion, I even wrote down what I
thought is the consensus (I am pasting it again below). Reading this
text, I became sad and sent in the new proposal above.

1. UAs must check hash against the representation (which is  the
message payload before content codings are applied,

2. An exception is the case where the UA will save files to disk with
the content encoding preserved, the developer needs to provide the
hash on the gzip'ed file.

Why I removed the encoding=gzip part for now:

Having the encoding=gzip in markup brings up the issue of "well, what
to do if it is not specified where we need it (.tar.gz download)? OR
specified where we don't need it (e.g., images)? Or some completely
different encoding (e.g., file is sent with gzip but encoding=sdch is
set)?" All these issues will likely make the spec painful for browsers
to implement and so maybe we are better off avoiding them (for now

The choice seems to be the spec above (or something similar) or what I
believe is the much cleaner option of "Always remove
content-encoding", where we ask developers to do a bit more work. I
tested Google Code, SourceForge, and Dropbox and none of them seem to
use Content-Encoding: gzip. (a random Apache server I tried did use
Content-Encoding gzip).

Like me, are you considering revising your opinion after reading the
possible spec text above?

Received on Saturday, 15 March 2014 05:10:25 UTC

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