4 ms·

Pretty much every codec in every browser is written in an unsafe language, unfortunately. I don't see why JXL should be singled out. On the other hand, there is

by lonjil 3y ago

Pretty much every codec in every browser is written in an unsafe language, unfortunately. I don't see why JXL should be singled out. On the other hand, there is a JXL decoder in Rust called jxl-oxide [1] which works quite well, and has been confirmed by JPEG as conformant. Hopefully it will be adopted for decode-only usecases. [1] https://github.com/tirr-c/jxl-oxide/pull/267 https://github.com/tirr-c/jxl-oxide/pull/267 > It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique. Rust and C++ are exactly the same in how they optimize, compilers for both assume that your code has zero UB. The difference is that Rust makes it much harder to accidentally have UB.

jiggawatts 3y ago
"We've never had to wear helmets before, why start now?" There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Adding a fourth image format is increasing this attack surface by a substantial margin across a huge range of software. Not just web browsers, but chat apps, server software (thumbnail generators), editors, etc... This is the kind of thing that gets baked into standard libraries, operating systems, and frameworks. It's up there with JSON or XML. You had better be damned sure what you're doing is not going to cause a long list of CVEs! JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. The JXL source is 1.4 MB zipped, making more than twice the size of the above three combined! The other libraries use C/C++ not because that's a better choice, but because it was the only choice back in the ... checks Wikipedia ... 1980s and 90s! We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise.
- lonjil 3y ago
  > "We've never had to wear helmets before, why start now?" > We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise. That's why I specifically said that it's unfortunate that C++ is still wide spread, and pointed to a fully conformant JXL decoder written in Rust :p > There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Every browser ships libwebp and an AVIF decoder. Every reasonably recent Android phone does as well. And every iPhone. Every (regular) install of Windows has libwebp. Every Mac has libwebp and dav1d. That's all C++. AVIF in particular is only a couple of years older than JXL, and yet I've never seen opposition to it on the grounds of memory safety. That is what I meant about JXL being singled out. > JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. > A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. > The JXL source is 1.4 MB zipped, making it nearly twice the size than all of the above combined. Which code exactly are you including in that? The libjxl repo has a lot of stuff in it, including an entire brand new JPEG encoder! Though jxl certainly is more complex than those three combined, since JXL is essentially a superset of all their functionality, plus new stuff.
  - jiggawatts 3y ago
    I revised my numbers a bit by filtering out the junk and focusing only on the code that most likely contributes to the runtime components (where the security risks lie). E.g.: Excluded the samples, test suites, doco, changelogs, etc... and kept mostly just the C/C++ and assembly code. I also recompressed all of the libraries with identical settings to make the numbers more consistent.
- JyrkiAlakuijala 3y ago
  I believe JPEG XL binary size is about one third of AVIF binary size. It is relatively compact. It is easy to write a small encoder: libjxl-tiny is just 7000 lines of code.

by lonjil 3y ago

jiggawatts 3y ago

"We've never had to wear helmets before, why start now?" There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Adding a fourth image format is increasing this attack surface by a substantial margin across a huge range of software. Not just web browsers, but chat apps, server software (thumbnail generators), editors, etc... This is the kind of thing that gets baked into standard libraries, operating systems, and frameworks. It's up there with JSON or XML. You had better be damned sure what you're doing is not going to cause a long list of CVEs! JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. The JXL source is 1.4 MB zipped, making more than twice the size of the above three combined! The other libraries use C/C++ not because that's a better choice, but because it was the only choice back in the ... checks Wikipedia ... 1980s and 90s! We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise.

lonjil 3y ago
> "We've never had to wear helmets before, why start now?" > We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise. That's why I specifically said that it's unfortunate that C++ is still wide spread, and pointed to a fully conformant JXL decoder written in Rust :p > There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Every browser ships libwebp and an AVIF decoder. Every reasonably recent Android phone does as well. And every iPhone. Every (regular) install of Windows has libwebp. Every Mac has libwebp and dav1d. That's all C++. AVIF in particular is only a couple of years older than JXL, and yet I've never seen opposition to it on the grounds of memory safety. That is what I meant about JXL being singled out. > JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. > A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. > The JXL source is 1.4 MB zipped, making it nearly twice the size than all of the above combined. Which code exactly are you including in that? The libjxl repo has a lot of stuff in it, including an entire brand new JPEG encoder! Though jxl certainly is more complex than those three combined, since JXL is essentially a superset of all their functionality, plus new stuff.
- jiggawatts 3y ago
  I revised my numbers a bit by filtering out the junk and focusing only on the code that most likely contributes to the runtime components (where the security risks lie). E.g.: Excluded the samples, test suites, doco, changelogs, etc... and kept mostly just the C/C++ and assembly code. I also recompressed all of the libraries with identical settings to make the numbers more consistent.
JyrkiAlakuijala 3y ago
I believe JPEG XL binary size is about one third of AVIF binary size. It is relatively compact. It is easy to write a small encoder: libjxl-tiny is just 7000 lines of code.