Comment by innocent_name

11 hours ago

Wasn't it due to poor security? libjxl had notorious bugs that would've on par with webp exploit, if present in browser:

https://security.snyk.io/vuln/?search=libjxl

I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.

No, that was not part of the reason the Google Chrome team gave: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

  • There are very interesting values here.

    Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.

    Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.

    Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.

    A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.

    • Interesting.

      I'm on the other side, I hate webp because if I download such an image a lot of apps don't support it. So typically I need to screenshot it instead to get a usable jpg/png.

      Now one more format to hate.

      I would say webp/jxl/avif is anti-general compute, since they require very recent software.

      7 replies →

that's what firefox said, not chrome

  • And even Firefox took well over a year to bring it up, after stating they didn’t really care for JPEG XL. It was literally no one’s primary concern from the get-go.

Probably why Google implemented their own decoder in Rust

https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...

  • “Their own” is a bit misleading. It’s largely a subset of the people who implemented libjxl in the first place, but this time in Rust.

  • Thanks for pointing that out. The stated reasoning for not supporting JXL is understandable, though quite vague. It feels like the sort of general trade-offs you could cite about not supporting any codec. In my experience in large companies, such 'tough choices' on features that would be "nice to have, but doesn't make the priority cut" are usually driven by demand from internal stakeholders or corp strategy not exceeding budget/head count constraints.

    While I'm happy for the reversal, it would be helpful to have a corresponding explanation addressing what changed leading to this reversal just two years later (assuming the decision to support was made 9-12 mos ago). Since significant decisions are usually harder to make in big companies (due to many competing prioritities, stakeholders, and processes), they tend to also be harder to reverse (especially in just two years, when most of original deciders are still in the same roles). I suspect the real thing that changed is more interesting than "the technology or people changed" or "our prior assessment was wrong".