Re: Some general thought on CRIME and Compression and Headers

The hard part of any such schemes is determining what is sensitive,
especially in the face of any future semantic/header changes. So, be
careful :)

SPDY as deployed today uses the fact that we have a good idea today about
what is sensitive, that we'll be throwing it out soon, and it only allows
gzip to compress something IFF it is not sensitive, or, if sensitive, IFF
the entire sensitive atom matches the previous sensitive atom.
This is, in effect, what is being proposed here.

One other thing... The delta encoder which was proposed here does not
strive for the best possible compression. If it did, I wouldn't leave bits
on the floor by doing byte alignment!
Rather, it is meant to be a compromise, giving excellent compression
(especially if/when we adapt to the idea that *change* causes an increase
in bytes on the wire), but also allowing proxies to do minimal redundant
work (of recompression/reencoding) etc.

If we're willing to throw more CPU at the problem (currently delta is 3x
more efficient than gzip in terms of CPU, not even counting proxies) I know
from experimental data we can get better compression ratios :)
-=R


On Sat, Jan 12, 2013 at 3:22 AM, Frédéric Kayser <f.kayser@free.fr> wrote:

> Hello,
> gzip/deflate streams are made of different types of blocks cf. RFC 1951
> http://www.ietf.org/rfc/rfc1951.txt (btype 0 is non compressed - fixed
> length-, btype 1 uses predefined Huffman tables, and btype 2 embeds Huffman
> tables specially tailored for the current data). The stream could switch to
> btype 0 when sensitive data has to be compressed, and afterwards this
> region could be excluded from LZ matches to avoid reuse, the resulting
> stream would be perfectly compatible with current Deflate decoders
> implementations.
>
> Le 11 janv. 2013 à 20:45, James M Snell a écrit :
>
> So far, the techniques we have explored to address this problem have been
> to alter the compression mechanism (e.g. delta) so that the compression
> ratio can't be effectively used to reverse engineer the sensitive data.
> This, however, brings along a range of issues, not the least of which is
> the fact that delta encoding is not nearly as efficient as gzip.
>
>
>