Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.
JPEG XL is not that massive.
JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.
A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.
A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.
A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.
The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.
JPEG XL is not that massive.
JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.
A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.
A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.
A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.
The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Works for me with Qubes OS.
Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
3 replies →
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
4 replies →
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
It's slow for tasks requiring GPU, but allowing GPU for chosen, trusted VMs is planned: https://github.com/QubesOS/qubes-issues/issues/8552
Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
1 reply →