Retain jpeg xl support?

[schance995]

Google is dropping JPEG XL from Chromium.

Will it be retained in ungoogled-chromium?

[PF4Public]

If someone submits a patch with this feature behind a flag — why not.

[networkException]

I'm against keeping around such complicated parts of the codebase as it increases the attack surface without any chance of getting security updates by upstream. Especially because an image decoder deals with arbitrary data

[gitoss]

The point of increased attack surface of any code is valid, but if the option is toggled by a flag every user could decide for him/herself.

I don't want to spam this thread, but +1 the importance of chromium spin-offs to pick up and support this patch set - which is even nicely packaged by now.

This is even more vital because Thorium is a one guy project atm and lagging updates - currently, it's still on 117 and JPEG-XL support might even further deteriorate and go the way of Iridium, Bromite...

[PF4Public]

@gitoss Would you be willing to work on enabling JPEG XL (derived from Thorium, for example) in ungoogled-chromium and submit a PR?

[gitoss]

Fair enough question, but I'm afraid my dev days are long over.

I just took the liberty to make a statement about the attack surface problem - btw a concern I issued myself a couple of times when there was a discussion about how to reason JPEG-XL back into official chrome.

[PF4Public]

@gitoss You see? I hope you get my point. Any feature request equals work. Work does not make itself, someone has to do it. Not everyone is willing to do work, let alone for free, let alone has necessary experience. More so if the result would bring very little additional value. Even more so if maintaining it would equal even more work.

There is no need to reiterate already stated arguments. It hardly changes anything.

[schance995]

The commit that dropped jpeg-xl is definitely nontrivial: https://chromium-review.googlesource.com/c/chromium/src/+/4081749

[jonsneyers]

In terms of attack surface: note that libjxl is integrated in many applications, not just browsers, and there is definitely a commitment by its contributors to keep fixing security bugs if and when any are found. Also note that this would in general not be a particularly attractive attack vector imo, considering 1) few browsers currently support jxl, and 2) the process doing the image decode should be relatively isolated from most of the other parts of the browser, so in case of a vulnerability, it is hard to do much more than to stall or crash a tab.

[jonsneyers]

Thorium enabled jxl by default, and it looks like they're also looking at keeping it in after upstream removed it: Alex313031/thorium#104

[networkException]

It looks like they use GPLv3, we won't be able to include patches from the here.

[PF4Public]

we won't be able to include patches from there

Maybe after #1845?

[networkException]

🤷

[jonsneyers]

Well libjxl itself is BSD licensed, and the integration code was part of chromium until M109 so I don't think there is a license issue with that either.

So I don't think there is any code with an incompatible license.

[Alex313031]

I have moved both the thorium repo and the thorium-libjxl repo to BSD-3 licenses now.

[Danny3]

Any updates on this?
I've been using this browser for a long time, but JPEG-XL seems too good to not have support for it.
Since I like this browser I'm not eager to move, but Thorium having support for it makes me think twice.
If you can, please add support for this here too!
Thank you!

[Alex313031]

@Danny3 @jonsneyers @schance995 @PF4Public @networkException I have moved both the thorium repo and the thorium-libjxl repo to BSD-3 licenses now.

[schance995]

Thanks for clarifying the license!

[jstkdng]

@Alex313031 is applying the patches in the repo enough to get support or is something else needed?