Posted by theanonymousone 1 day ago
"By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread."
For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow
The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports
SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments
The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services)
1. "As of 2021, no major browsers supported SPDY" https://en.wikipedia.org/wiki/SPDY
2. https://en.wikipedia.org/wiki/HTTP/2_Server_Push
3. https://foxio.io/blog/header-accordions-qpack-amplification-...
Most of the discussion here is about vulnerabilities in servers, but it looks like its mostly a client problem.
Is there a way to turn brotli off?
Going back to your point, if we kept things simple we would be a lot more secure.
Every user is different
For me I'm a text-only user not interested in graphics
I do not use a so-called "modern" browser to make HTTP requests
I don't request brotli-compressed content/resources^1
Normally I don't send an Accept-Encoding header
Almost always servers to which I connect^2 will return uncompressed text, which is what I want. No Accept-Encoding header needed
Occasionally servers will send gzip-compressed text by default and will ignore "Accept-Encoding: identity"
However the popular so-called "modern" browsers will send an Accept-Encoding header whose value includes brotli (br) by default
Unsuspecting www users are consequently opted in to Google's brotli experiment. Me, I opt out
1. I use a text-only browser (1.3MB static binary) to read HTML. I compile it without brotli support
2. Other users may connect to different servers. Preferences vary from user to user
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
However, why not switch to the Rust lib when it was available? I suppose people at Dropbox are now pretty happy they did in 2016: https://dropbox.tech/infrastructure/lossless-compression-wit...
It's slower, though. Too high a price to pay for safety it seems.
There is a cost to conversion.
Dropbox switched to it a decade ago, so it's probably quite product-ready.
How many clients only accept brotli?
So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
As an attacker I setup a new server that serves only brotli and then submit that URL to the SaaS.
That's a clever example, but why would you do that? The avatar should be a static resource. As such, I'd only provide an upload file dialog.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
That's basically one of the core ingredients of security. Build a threat model.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
If you want something else you can take your pick based on need from dozens of other options
SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.
For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.
Multiplexing is the default in HTTP/2 and 3. So you're still wrong.
https://stackoverflow.com/questions/36517829/what-does-multi...
So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.
I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.
The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.