The case I think about the most is web fingerprinting. For example if the authorities in a country that funnels all external traffic through a point of mediatio

The case I think about the most is web fingerprinting. For example if the authorities in a country that funnels all external traffic through a point of mediation want to identify who is reading certain specific pages on wikipedia - they likely can. The most effective forms of web fingerprinting focus on static resources; the two most prominent papers focus on Google Maps tiles, and Netflix videos, which were both collections of static resources that were compressed offline. Static resources are easier to target because the size of response is fixed, and the domains they're hosted on tend to be relatively free from cookies, auth tokens, query strings, and other noise. In practical terms for attackers, it's easiest to focus on the images, CSS and javascript that your browser is downloading; since these are usually static, pre-compressed, and on CDN-hosted domains. This is pretty feasible against Wikipedia, but also Facebook shares, tweets, etc ... anywhere where you're viewing content that includes images or video. O.k. so far nothing controversial, nobody would even get much of a paper published about this, we bucket it under "Traffic Analysis" and while it might shock the average internet user, cryptographers aren't surprised. Where CBC vs GCM comes in is that GCM reduces the "cost" of these fingerprints and increases the effectiveness of the whole approach. If a webpage contains say 4 images, and an external CSS reference, that gives you 10 points of information to fingerprint. You get 5 request lengths and 5 response lengths. Given the spread of URL lengths and file sizes, it's pretty easy for that combination to be unique, or at least narrow things down to a small set of possibilities. With CBC enabled, each request length and response length is rounded to the nearest 16-bytes. That's not a huge amount of padding, more would be better, but it still reduces the uniqueness of the fingerprinting by an exponential factor. It's particularly effective on the request lengths, which are small to begin with. Now with more requests, and a bigger graph, it's still probably possible to de-fuzz this; but my point is that in practical terms - when you have exact lengths, you just don't need to this. With exact lengths, you can ask a junior SDE to code this up for you in a few weeks. Someone who barely understands tcpdump and mysql can build this. With blocks and /some/ length hiding, the same person finds that they get less signal and have to correlate between more requests and pages, it might not even be practical for many sites. On principle, I think it's dumb to lower costs for practical attacks like this.