Warn users about Cromite adding and enabling JPEG XL

JPEG XL is extremely bulky and complex. The reference decoder, implemented in multithreaded C++, is over 100,000 lines of code, making it a significant security risk. This concern was a major factor in Google’s decision to drop support for JPEG XL in Chrome. Even Mozilla, a company that allowed their Android browser to basically have no sandboxing for almost a decade, has expressed some serious security concerns with JPEG XL, stating that it would add a substantial amount of attack surface to Firefox.

Considering all the above, I think it would make sense to warn people about such an addition to Cromite.

4 Likes

Interesting stuff…

I think Mozilla is technically “neutral” on JPEG-XL

So we don’t see support for JPEG-XL as either good or bad for the Web. We might find it necessary to support the format if usage becomes more widespread, but that will be a product decision

There was also this article, which I wonder if there has been anymore info on.

Our primary concern has long been the increased attack surface of the reference decoder (currently behind a pref in Firefox Nightly), which weighs in at more than 100,000 lines of multithreaded C++. To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox.

It also sounds like Google did not think the juice was worth the squeeze.

During our experiment to support JPEG-XL in Chrome, we concluded that it did not provide substantial benefits over AVIF

source

This concern was a major factor in Google’s decision to drop support for JPEG XL in Chrome.

This is not really known, and mostly speculation. What Google argued when they removed it was mostly about “not enough interest in the ecosystem[1]”, which is, objectively, untrue, considering that the Chromium issue alone has a ton of comments from various engineers (from NVIDIA, Cloudinary, etc.) against the decision. It was also the most requested feature for Interop 2024[2] and now Interop 2025[3]. Furthermore, Apple products, including Safari, have JPEG XL support[4] using the reference implementation. But I digress.

Even Mozilla (…) has expressed some serious security concerns with JPEG XL, stating that it would add a substantial amount of attack surface to Firefox.

This is true[5]. However, they also said they would implement it given a proper Rust decoder[6] is implemented, one of which is now in the works[7] by the JPEG XL team and also seems to be at least partially intended for use in browsers[8].

Sources (due to link limits).

I do agree that maybe a warning could be added, considering the increased attack surface. Or maybe a note/link to similar features that are/will be implemented in Cromite that can potentially increase attack surface.

3 Likes

By now, I’d expect popular browser vendors to be capable of containing such codecs?

Android most certainly can, for example, with constrained sandbox for mediaserver.

Pardon my lack of knowledge, but how could this be used for exploits from the end-user’s side? Could it be exploited by a malicious site they visit, or does it require someone tampering with the browser itself?

I just don’t understand how a large chunk of code would be open to any more vunlerabilities than the browser is without it. And that’s a genuine question lol, I’m just not knowledgeable on the way malicious actors can actually exploit one’a system like this.

There have been exploits in image format implementations in the past and there will continue to be more:

Plenty of examples to look into if you want to know more about it.

3 Likes

Very informative, thank you!

1 Like

Yes; in this case probably via malicious websites loading well-crafted jpegs.

You’re right that browsers are more complex than a single codec, but code for all those codecs add up. Also, browsers like Chrome & Firefox are likely to have better security posture (for the code they author and build) than most other dependencies they might link into.

OP opines that the already vast browser codebase should avoid linking into potentially unsafe code (written in C/C++ as opposed to say Zig/Rust). This is now a widely accepted norm / rapidly emerging consensus in the industry.

1 Like

I should note that I don’t have anything against the new rewrite in Rust, that will probably be included in both Chromium and Firefox soon.

Probably not in Chrome itself, because Google is for some reason really protective of their (inferior) formats Webp and Avif. But I’m sure projects like Cromite and Brave would be able to port it once it’s ready.