Re: [integrity] What should we hash?

> 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?

Well, we aren't supporting progressive hashes right now. But, yes the
browser will need to decompress the final output and hash it once the
download finishes. Then, throw away the decompressed file.

On the other hand, this won't be needed for exe, pdf etc. This is only
needed for the weird .tar.gz (and similar cases) where the browser
does not remove the gzip Content-Encoding when saving the file to
disk.

> 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...

I was saying that downloads in general, and .tar.gz-like downloads in
particular, are far and away a lot rarer than sub-resources (images,
scripts) etc.

> On the other hand, if this spec is all about subresource integrity, then
> maybe it should just be ignored for downloads?

As you said above: specifying hashes and asking the user to check is
pretty common. It would be nice if we can support it. So, I am going
to still try getting this feature right :)

> I'm not convinced we should overcomplicate the already complicated data flow

How about a hybrid with Mark's idea only for only the downloads case?
We default to undoing content-encodings and the developer can opt-in
to computing the hash on the gzip'ed file. In most cases, the
programmer won't need to specify anything extra but for .tar.gz file,
the programmer will need to add a "encoding=gzip" to the anchor link.
The spec can allow browsers to just delete the download if they don't
want to do unzip the document and the programmer forgot to give the
hash with encoding=gzip.

I believe the hybrid above will be actually the least amount of work
for developers and for browsers.

What do you think?


thanks
Dev

Received on Saturday, 15 March 2014 02:51:24 UTC