[rwmj]

From the browser makers' point of view there's quite a bit of risk with introducing a new image format. libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. I'm sure that someone will write a decoder in a safer language, but that work still needs to be done and/or finished, and then integrated with the browser. At the same time there are to 5 significant places probably 0% of websites that host .jxl files. So at the start it's all downside and almost no upside.

(Chicken and egg problem here of course which is no one will create the websites until there is wide browser support.)

[zokier]

> If having a high quality Rust decoder implementation would arise as the only gating factor for choosing JPEG XL into interop 2024, the JPEG XL developer team in Google Research can deliver such by the end of Q2 2024

> We have tested conformance of the jxl-oxide decoder (which is implemented in Rust) and it is a fully conforming alternative implementation of JPEG XL. It correctly decodes all conformance test bitstreams and passes the conformance thresholds described in ISO/IEC 18181-3.

https://github.com/web-platform-tests/interop/issues/430

[BlackLotus89]

https://github.com/niutech/jxl.js a javascript polyfill taken from the main page https://jpegxl.info/

There are other decoders [0] written in a "safe language" (rust) listed as well. So no there are many "safe" implementations

[0] https://github.com/tirr-c/jxl-oxide

[amluto]

It takes some effort to implement, but Google has WUFFS for almost exactly this purpose:

https://github.com/google/wuffs

[rwmj]

Yes this is pretty great actually.

[apichat]

Two rust implementation projects :

https://github.com/tirr-c/jxl-oxide

https://github.com/libjxl/jxl-rs

[rwmj]

Unfortunately a Rust implementation doesn't solve everything that could go wrong in a browser. You need to think about amongst other things: total memory that an image could allocate, safety of network references (if the format allows that, like SVG or XML), any kind of unbounded processing or memory usage caused by the image (such as a "zip bomb"), and what could possibly go wrong for every corner case in the standard. The Wikipedia page says that JPEG XL supports up to 1 terapixel images, which is unlikely to be a good idea for a browser even if it's handled in a memory safe way.

A while back I fuzz tested qemu's handling of various different disk image formats (I know, a different type of "image", but bear with me!) I found many cases where qemu could consume huge amounts of memory or CPU time on some inputs. Often times the inputs were quite small too, allowing nasty amplification attacks. As a result of this standard advice for clouds that allow you to upload untrusted images is to decode in a separate process. That process is protected with ulimits, so it will die, rather than trying to allocate all memory in the machine or consume huge amounts of CPU.

[croes]

Isn't that true for the other new formats they support too?

Why single out JPEG XL?

[rwmj]

It is true about other formats, but those have been in browsers for a long time so by now we have patched most of the exploits.

WebP is one of the most recently added image formats, and it had zero day exploits as recently as 6 months ago.

[cubefox]

> It is true about other formats, but those have been in browsers for a long time so by now we have patched most of the exploits.

The current debate is about JPEG XL vs AVIF. Advantages of old image formats are not relevant here.

[solardev]

How are they not irrelevant? This is a cyclical problem browsers and OSes have dealt with many times before, and JPEGXL will hardly be the last time. It's a fundamentally challenging situation that applies to the newest image codec as much as it does to old ZIP files or hostile PDFs.

There will always be some new format with some advantage or another, but safely parsing complex user generated content just isn't trivial, so every one of these is both a cost benefit analysis on its own merits but also a chance to reflect on historical implementations, vulnerabilities, and lessons learned.

[croes]

>it had zero day exploits as recently as 6 months ago

That not a measure of security.

How many malware exists for MacOS compared to Windows. Does that mean MacOS is safer?

You could easily argue the other way around that WebP and say has more undiscovered exploits.

[jmull]

> Why single out JPEG XL?

Hopefully it isn't singled out, and any prospective support for a new image format gets the same scrutiny.

The question is different for any image format that is already supported, because removing it breaks the web to the extent the format is being used. That's really an argument to be particularly careful about adding support for a new format: once it is widely available for a while it is almost impossible to remove. This is a one-way decision (unless it's barely used, in which case there wasn't a good reason to add it in the first place).

[IshKebab]

Chrome already handles excessive CPU or memory use by a tab, and I very much doubt the format supports urls (and it would be trivial to check).

Nothing you've said should be an issue. I expect really they just don't want "their" formats to be obsoleted.

[rapsey]

A safe Rust implementation solves the biggest problems.

[rwmj]

It's definitely better than no memory safety, but not sufficient to deal with all the cases that a browser (or anything parsing untrusted data from the internet) needs to think about.

[cesarb]

> libjxl is written in C++ so undoubtedly will be full of undiscovered security issues.

There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.

[pmarreck]

Aren't there C++ static code analysis tools at this point that might mitigate such risks?