Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ .

However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HTTP/2, we will have a custom header compressor which is intended to eliminate CRIME-like attacks: https://tools.ietf.org/html/draft-ietf-httpbis-header-compre... .

(Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

I saw an awesome talk my mnot recently about http/2.0 for which I'm really excited. A large part of it was basically "Lessons we learned from SPDY" which is great, in the longterm.

Personally I feel SPDY was a huge benefit to the internet, but in saying that it was a huge benefit in the form of "a cautionary tale to others"

What is the caution?

It turns out that compression with TLS is hard.

You can use a compression level of 0. That is, pass through.

You can, but then you've got to write this enormous block comment saying "I realise this looks wrong and broken, but ssl is also broken so don't change this constant", until some junior dev inevitably does anyway.

Having known vulnerabilities baked into a standard with "weird looking" mitigation strategies is really poor choice IMO.

That said, I do see your point. There are also other edgecases, like serving statics on a seperate, uncookied domain that benefit greatly from SPDY in the here and now.