Hacker News new | past | comments | ask | show | jobs | submit
nayuki | on: Broccoli2Shell: Brotli decoder RCE in Node.js, Python and more
I see some irony here. For a period of time, Google chose not to include JPEG XL in Chrome because vulnerabilities in the library could compromise the software - a legitimate concern. Yet, Google is the author of the Brotli data compression format a decade before the JPEG XL drama, and was happy to use it in Chrome and encourage others to use the library, despite the fact that it also increases the attack surface.
progbits | parent | next
1. People change their minds over time.

2. JXL is waaay more complex than Brotli so the risk of vulnerable implementation is also higher.

They should have demanded more rigor from the Brotli library, same for countless other dependencies chromium has. But there's no irony.

gsnedders | parent | next
Things like Rust in Chromium weren’t even being talked about back when Brotli was introduced to Chromium.

I think Chromium as a project would be happier if they had less unsafe code in general, and holding new dependencies (especially those like media formats, which have a long history of security issues) to that standard doesn’t seem particularly surprising.

There’s always going to be trade-offs: how much benefit does this provide (users, developers) compared with how much risk does it incur (safe/unsafe code, quantity of code you’re now on the line for the security of).

(And that’s taking that reason to not support JPEG XL at face value, ignoring any debate about it.)

anthk | root | parent
Sandbox + more Rust: vulnerabilities axed down.
da_chicken | parent | next
Well, don't worry. libjxl includes the brotli library, too, so it's also vulnerable to this.

https://github.com/libjxl/libjxl/pull/5062/commits/269661f71...

cxcorp | parent | next
Brotli reduces their compute costs, whereas JPEG XL reduces storage which at least historically is cheaper than compute?
gsnedders | root | parent
From a browser point-of-view, the real questions are about data size (if you can get the wireless interface back to a low power state, you’re winning on power benchmarks), about decompression cost (again, power benchmarks), and decompression time (for performance benchmarks and user-perceived performance).

Storage and compression compute costs aren’t really relevant — only insofar as if there’s very little adoption, the security risk of exposing the code is there but isn’t providing user benefit.

wat10000 | parent
This is getting real close to "yet you participate in society, curious." Yes, Google chose not to use some software and chose to use other software. It's not ironic to decline to use some software because it increases the attack surface, and then find out that it's not enough and the software you did choose to use is vulnerable. It's just unfortunate.
rpdillon | root | parent
My reading of the critique is that the criteria was unevenly applied. Decompression vulnerabilities exist in both libraries. They rejected one on the basis that it expanded the attack surface area, but accepted the other, despite similar claims applying to it as well.

It's pretty far from the "yet you participate in society" anti-pattern.

wat10000 | root | parent
They thought one was worth it and the other was not. That’s only similar if you ignore the concept of tradeoffs being different.