Include JXL (JPEG XL) Support
OkyDooky opened this issue · comments
Preliminary checklist
- I have read the README
- I have read the FAQs.
- I have searched existing issues for my feature request. This is a new issue (NOT a duplicate) and is not related to another issue.
- I have searched wont fix issues and this request is not among them
- This is a feature request for the Cromite browser; not the website nor F-Droid nor anything else.
Is your feature request related to privacy?
Yes
Is there a patch available for this feature somewhere?
I opened an issue for this on the Build-Tools repo, but someone brought this repo to my attention and suggested I also open it here, as well.
This is obviously not strictly related to privacy in this browser, but it gives users a privacy-respecting option for a mobile browser that supports the new format that Google is trying to torpedo. Currently, the only known option is the Android build of Thorium, which is not a privacy-oriented browser.
Here are two patches available that may be usable by this project:
https://github.com/Alex313031/thorium-libjxl
https://github.com/OpenMandrivaAssociation/chromium-browser-stable/blob/master/chromium-restore-jpeg-xl-support.patch
Describe the solution you would like
I would like one of the above patches (or any others that become available) to be included in the builds for this browser, so that we can have a privacy-respecting browser that also supports a highly-desired new format right out of the box.
This can make it easier for others to suggest a browser option to friends and such. But, it also will help encourage adoption by other Chromium forks, like Brave or Vivaldi and the like.
Describe alternatives you have considered
I'm thinking of also asking the guy behind DivestOS if he'd consider including one of these patches in his builds of Mulch. Otherwise, I'll still be stuck with having two large Chromium browsers on one device (Thorium and your Bromite build) in order to have access to JPEG XL on the web and to have all the other features that Bromite provide(d/s), which is both inconvenient and bloats my already small internal storage (32GB).
I hope this gets considered and merged. Maybe talking with Alex of Thorium could be an option to help make the process smoother and easier.
Thanks again for your work. It is highly appreciated
Considering the default WebView on CalyxOS is using patches from Cromite, this could also help other projects in Cromite's periphery. Considering a JXL patch is already available for Chromium & other browsers like Thorium already support JXL, I think this would be a wise decision. The entirety of the Apple ecosystem natively supports JXL now, & sites like Shopify are serving JXL images currently
are required:
Name: libjxl JPEG XL image decoder library
Security Critical: yes
Name: Highway: C++ library for SIMD
Security Critical: yes
I'm sorry, I might be able to activate it, but that Security Critical: yes scares me and I have neither the time nor the expertise.
Can you share the links to those entries, so that I can share them with the JXL channel? That really isn't something you should have to worry about fixing. Once they're cleared, then maybe the patch(es) could be merged?
Can you share the links to those entries, so that I can share them with the JXL channel?
sure.
https://github.com/Alex313031/thorium-libjxl/blob/main/src/third_party/highway/README.chromium
https://github.com/Alex313031/thorium-libjxl/blob/main/src/third_party/libjxl/README.chromium
are from @Alex313031 but I imagine they are part of the rollback relating to support in chromium
That really isn't something you should have to worry about fixing
also because I would not be able to.
However, the problem is not so much in that.
Having third-party libraries in chromium not managed by the excellent security team that google certainly has is a problem in itself.
just to give you an example one of the last fixes released for chromium contained precisely the fixing of a security bug relating to a third-party library (High CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx link to fix <-- literally incomprehensible to me)
if it's not done directly by the chromium team, it would force me to check the status of those libraries to find out when and how to update them.
and then, to find out whether a security issue has been exploited requires logs that cromite does not have.
and finally, I don't know how I would behave if I ever became aware of a security bug, perhaps not a public one, I don't think I would continue to put that patch in cromite, perhaps disclosing the problem to the public.
context: Issue 1178058: JPEG XL decoding support (image/jxl) in blink (tracking bug)
motivation: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84
Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
patches:
https://chromium-review.googlesource.com/c/chromium/src/+/4081749
https://chromium-review.googlesource.com/c/chromium/src/+/4095497
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4100605
note: no reference to Highway: C++ library for SIMD
if someone helps me set up dependabot we can think about it
Context
I'm not sure what you're trying to convey in this post, other than that Google made a decision that we're all aware of. 🤔
Plus, their justifications have all been thoroughly debunked and refuted by virtually everyone and their grandmother, at this point.
note: no reference to
Highway: C++ library for SIMD
What is the significance? That they didn't need that library to begin with? If it's unnecessary and should be removed entirely (rather than waiting for a fix), then maybe I or anyone could make an issue on the Thorium patch repo? I guess that also would mean I should just bring up the first issue with the JXL group. If it's been fixed already, it could just be that the Chromium patch would need to build from the JXL Git repo directly, instead of waiting for a full release.
Also, have you looked into the second patch, at all? Someone in the JXL channel recommended it (the OpenMandriva one) because they felt it was more straightfoward. But, that's, of course, subjective.
The links I was hoping for were official CVE links or something, since I have no idea what Alex is basing the "security critical" assessment on (which means it's harder to know what to fix, if anything).
Edit: I just did a quick search and both NIST and CVE Details show zero security concerns found in the latest release (8.2). Version 8.2 was released in June and includes notes for a security issue from the previous release that they patched (here). That still leaves the C++ library, but I'm doubly not sure what @Alex313031 meant by "Security Critical: Yes" in those READMEs. Maybe he can comment?
Would it be best to introduce JXL support behind a flag initially so the development burden can be evaluated with nearly zero impact on the users? Considering actually legitimate CVE databases do not find any concern with libjxl regarding security & JXL adoption is growing quickly, I think this may be a worthwhile move to help streamline the introduction of such a valuable feature to Cromite users.
JXL adoption is growing quickly
Do you have any proofs for this claim?
JXL adoption is growing quickly
Do you have any proofs for this claim?
If you mean user adoption, no. Since, there's no way to track that (yet). If you mean software and corporate adoption, there are several lists, including one maintained on the libjxl Github repo: https://github.com/libjxl/libjxl/blob/main/doc/software_support.md
That list used to be noticeably shorter, last year. Some highlights are several major pieces of Adobe software and the recent adoption by Apple, as mentioned by @gianni-rosato in the first reply. "Adoption" isn't some imaginary thing that JPEG XL fanatics are dreaming up to convince others. It's very real and they just get excited every time there's a new addition, even if it's "small."
@OkyDooky #351 (comment) <--- no hidden meaning, I draw the links that are useful for me to eventually create the patch
note: no reference to Highway: C++ library for SIMD
What is the significance?
that the original patch does not mention the need for that library
Also, have you looked into the second patch, at all?
No.
since I have no idea what Alex is basing the "security critical" assessment
it is not alex but the chromium team
I think this may be a worthwhile move to help streamline the introduction of such a valuable feature to Cromite users.
I don't know whether it is valuable or not, that's not the point. cromite should not be my browser but everyone's.
if there is not sufficient technical justification for not introducing jxl, I should not be the one to block the inclusion of that feature, I would behave like google otherwise.
no hidden meaning, I draw the links that are useful for me to eventually create the patch
That makes sense. Thanks for clarifying.
that the original patch does not mention the need for that library
Sure. I was fishing to see if that meant that it is not necessary or if Google/ChromeDevs was being weird with their notes, etc.
it is not alex but the chromium team
Maybe I'm missing something with how patching is done, but I cannot find anything linking those READMEs to the Chromium devs (edit: I found the original (for libjxl) in the source patch, but the rest of the point still stands: there's zero indication for why or how they derived those conclusions, especially with highway. The date in the libjxl one here is from April, which is before the last CVE got patched). And, since there's no open CVEs for either libjxl or highway (highway doesn't seem to even have a product entry on NIST's site), there doesn't seem to be a way to check why there would be any reason to consider these libraries as compromised in the wild, let alone how to check when they would be deemed safe. :/
I think this may be a worthwhile move to help streamline the introduction of such a valuable feature to Cromite users.
I don't know whether it is valuable or not, that's not the point. cromite should not be my browser but everyone's. if there is not sufficient technical justification for not introducing jxl, I should not be the one to block the inclusion of that feature, I would behave like google otherwise.
Google's stated reasons for denying support to this feature are effectively baseless. However, legitimate security concerns are not and need to be addressed first. I would be fine with it being introduced behind a flag with the default being "off," but I also would prefer there to be no major issues at all. So, I apologize for all the handholding I've been requiring, but I wanted to put in as much helpful leg work as I am able to remove those, as you put it, "technical justifications for not introducing jxl." Google monkeywrenched the adoption process, so these are efforts to try to unstick the process.
Thanks for being patient with me and others with this issue.
Edited with new information.
there's zero indication for why or how they derived those conclusion
anything that receives a stream of bytes from outside without a blink or browser-side check is potentially at risk.
Google's stated reasons for denying support to this feature are effectively baseless.
the process of adopting changes on the blink side is standardised, as opposed to the browser side.
Now, I still don't understand how much is in google's hands and when it is not, but from what (for now) I understand, if someone follows all the necessary steps (which are not few and which I do not yet know well), google cannot refuse to include them in the code base. Then it can only deactivate the function in chrome.
If anyone knows more, I would be interested in understanding more.
@OkyDooky Those readmes are from here > https://source.chromium.org/chromium/chromium/src/+/main:third_party/highway/README.chromium and here > https://source.chromium.org/chromium/chromium/src/+/refs/tags/109.0.5414.120:third_party/libjxl/README.chromium
I just updated their content to reflect the fact that I updated libhighway and libjxl to newer versions than what was used in M109.
Thank you for clarifying, @Alex313031
Also, this feedback was posted in the JXL channel:
Details
@OkyDooky No, I knew that Chromium has highway for other stuff. I updated the highway version to a newer version than what Chromium by default uses. This is shown in the DEPS file. I updated that README.chromium file to reflect this.
You can tell him, or redirect him here to let him know
I will do both. Thanks for that. And, seriously, thank you and the patch authors for doing huge work in getting this ball rolling.
check the status of those libraries to find out when and how to update them.
see https://github.com/uazo/cromite/blob/master/.github/workflows/check_nist.yaml
and https://github.com/uazo/cromite/blob/master/tools/cves/libjxl.txt
the patch is similar to yours, after all it is a revert of a chromium commit.
the only major difference is in third_party/libjxl/BUILD.gn (see for example https://github.com/uazo/cromite/blob/master/build/patches/00Add-support-to-jxl.patch#L2731-L2747)
Should allow you to no longer have to manually edit https://github.com/Alex313031/thorium-libjxl/blob/main/src/third_party/libjxl/src/lib/include/jxl/version.h
of course, if you want, free to use it (and I'll stop telling you :)
Thanks for looking into and doing this. I'll advocate for this browser being added to the software list on the libjxl repo. That will hopefully expand awareness of this project and give more users a reason to try it out.