←back to thread

94 points ksec | 1 comments | | HN request time: 0.209s | source
Show context
ekunazanu ◴[] No.44570052[source]
JPEG XL had so much going for it. Kinda sad it was killed off just like that.
replies(7): >>44570077 #>>44570161 #>>44570521 #>>44570580 #>>44570956 #>>44572410 #>>44575108 #
arp242 ◴[] No.44570521[source]
It wasn't "killed", it was always disabled by default in Chrome, and removed for really quite reasonable reasons: literally every other image decoder has had serious vulnerabilities. Enabling it by default would expose a gigantic attack surface that almost certainly will be exploited sooner or later.

This is also why Firefox doesn't support it by default (IIRC it doesn't even link against libjpegxl by default in release builds – only nightly ones).

There is nothing preventing the Chrome or Firefox people from revisiting all of this in the future.

It seems to me the Rust implementation of JPEG XL is by far the best path forward for broad JPEG XL support in Firefox, Chrome, and other browsers. While Rust is of course not a complete guarantee there will never be any security issues, it does eliminate virtually all of the major exploits that have targeted image decoders in the past. Both Firefox and Chrome have expressed interest in this.

replies(1): >>44570574 #
badgersnake ◴[] No.44570574[source]
And because they wanted to push WebP
replies(4): >>44570633 #>>44571463 #>>44572495 #>>44572804 #
lern_too_spel ◴[] No.44572804[source]
Then why did they develop libjxl, and why are they working on jxl-rs? https://github.com/libjxl/libjxl/blob/main/AUTHORS https://github.com/libjxl/jxl-rs/blob/main/AUTHORS

Maybe their stated reason for not enabling support in Chrome is the actual reason.

replies(1): >>44602677 #
1. ◴[] No.44602677[source]