https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.
Aviso: http
If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't.
> while being written in an unsafe language
They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.
Concerns about the implementation only came up after years of pushback forced google ton reconsider.
I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.
On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.
In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:
1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.
2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.
Skal also took care of integrating the lossless format into the lossy as an alpha layer.
Well it is up to you to decide. The link was submitted a dozen of times on HN and the whole thing was well reported. And Jyrki Alakuijala already classify its creator status.
They deliberately made up a flawed test to show AVIF is better than JPEG XL. When most evidences shows contrary.
https://github.com/search?q=repo%3Alibjxl%2Fjxl-rs%20unsafe&...
And my discovery (which basically anyone could have told me beforehand) was that ... "unsafe" rust is not really that different from regular rust. It lets you dereference pointers (which is not a particularly unusual operation in many other languages) and call some functions that need extra care. Usually the presence of "unsafe" really just means that you needed to interface with foreign functions or hardware or something.
This is all to say: implying that mere presence of an "unsafe" keyword is a sign that code is insecure is very, very silly.
No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling
A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
I agree with this. But for a component whose job is to parse data and produce pixels, the security worries I have are memory ones. It's not implementing a permissions model or anything where design and logic are really important. The security holes an image codec would introduce are the sort where it a buffer overun gave an execution primitive (etc.).
You can get an awful lot done very quickly in C if you aren't bothered about security - and traditionally, most of the profession has done exactly that.
What about against a vigilant Rust programmer who also manually validates everything and uses available tools at its disposal?
So, a fairy-tale character?