Re: [integrity] What should we hash?

I have a question on what an implementor needs to do WRT to file downloads.
My understanding is implementors are not required to buffer a file in
memory until the integrity check, right? Presumably we can still stream the
download to a temporary file or something somewhere. Sorry if this has
already been discussed somewhere else previously.

On Wed, Apr 9, 2014 at 10:18 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 4/9/14 1:11 PM, Devdatta Akhawe wrote:
>
>> 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.
>>
>
> "Just fail to save the file the user asked you to save" is not exactly
> something I would like to ship.


I agree with Boris here, although I'm not entirely sure why we need to do a
recompress. Can't you just keep the compressed bytestream and not have to
spend CPU cycles on recompressing? Decompression is only for integrity
verification, right?


>
>
>  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.
>>
>
> Correct.
>
>
>  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.
>>
>
> Yes.  The default Apache config, last I checked.
>
>
>  Browsers can fail SRI check for such downloads to avoid a streaming
>> decompress/recompress.
>>
>
> See above.  You'd be setting up a situation where the download works fine
> in a browser without SRI but fails in one with.  Which is a general problem
> with SRI, of course...  But the point is that from a user's point of view
> the browser will update and stuff will stop working.  That is what we call
> a Bad User Experience.
>
>
>  Since this would be easily noticeable during testing
>>
>
> You're assuming people test their stuff on the web.  Some do.  More
> don't...
>
> -Boris
>
>