Investigate / enable brotli compression for HTTP responses

[legoktm]

Description

brotli is a (relatively) newer compression algorithm originally developed by Google that broadly provides better compression than gzip.

How will this impact SecureDrop users?

Better compression will lead to faster downloads, which even at say 10% improvement, could be a nice optimization given the slowness/flakiness of Tor.

How would this affect SecureDrop's threat model?

It's possible there are attacks against brotli that don't apply to gzip, but we rely on Tor for network level protection, so those attacks shouldn't apply to us, unless Tor itself is also vulnerable (and then out of our scope, IMO).

Technical notes

• it's not as simple as a2enmod brotli, there's some other config snippet that needs to be added: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972632
• Tor Browser sends a Accept-Encoding: gzip, deflate, br header, where br is brotli
• I noticed this when I was reviewing the async-compression crate for sd-proxy. reqwest has a feature flag to enable brotli compression (we currently just opt-in to gzip).
• I think we want to figure out if we can have both brotli and gzip enabled. If we had to lose gzip, I don't think it's a huge deal because all the clients we need to support presumably support brotli.

[eloquence]

If we revisit the compression choice, see also some of the usability considerations in our current confusing mix of ZIP and gzip: #2289

[legoktm]

Ahhh, right. I should clarify that I was just thinking about brotli for HTTP-level compression.