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.

[legoktm]

In the Firefox 126 release notes:

Firefox now supports Content-encoding: zstd (zstandard compression). This is an alternative to broti and gzip compression for web content, and can provide higher compression levels for the same CPU used, or conversely lower server CPU use to get the same compression. This is heavily used on sites such as Facebook.

Not sure when this will make its way to Tor Browser and if we can enable it in focal's apache.