3 ms·

> netizen were arguing that jpeg xl should be adopted as fast as possible, and for that to be possible the browser developer "only needed to include the referen

> netizen were arguing that jpeg xl should be adopted as fast as possible, and for that to be possible the browser developer "only needed to include the reference decoder code into their codebase" at "very little cost". Because otherwise AVIF should not have made into the codebase. High-profile C/C++ projects can't prevent all security bugs, but they can make them easier to find and harder to get in. AVIF and JPEG XL roughly have the same impact in this regard (written in C++, uses Google's standard convention, tested and fuzzed regularly, and so on).

Filligree 3y ago
Then why is it C/C++? To be allowed into the browser, a new codec ought to be implemented in a memory-safe language.
- lifthrasiir 3y ago
  Because browser vendors have already invested too much into the existing C/C++ code base. They can thus accept new code with the same degree of coding standard.
  - acdha 3y ago
    Those same vendors are using Rust and Swift now which have comparable performance and solid interoperability. It seems like time for a policy saying new internet-facing code be implemented in a safe language.
    - saagarjha 3y ago
      Browser vendors are ahead of you on this. They just need time to put it into practice.
      - acdha 3y ago
        Yes - I know both Mozilla and Chrome are doing this. The main thing I was thinking is that it’d be a lot more supportable if the response was, say, “we’ll add JPEG-XL only in Rust”.
acdha 3y ago
> High-profile C/C++ projects can't prevent all security bugs, but they can make them easier to find and harder to get in. AVIF and JPEG XL roughly have the same impact in this regard (written in C++, uses Google's standard convention, tested and fuzzed regularly, and so on). Isn’t all of that true of libwebp? I’m sympathetic to the argument that it’s a lot of work to replace C but I’ve been hearing that C/C++ will be safer with enough diligence and better tools since the 90s and it hasn’t happened yet.
- lifthrasiir 3y ago
  Correct, hence "[they] can't prevent all security bugs". They are written in C/C++ primarily because their primary users (e.g. web browsers) will still use C/C++ anyway, so the interoperability is more important. This is changing thanks to Rust and other languages, but the pace is still much slower than we hope.
brigade 3y ago
AV1 video support was already a baseline since Youtube and other websites really want to use it, so AVIF didn't add any attack surface with the decoder. (this is also unlike WebP vs VP8, since WebP added a lossless mode which is quite literally the part this vuln is in) HEIF container parsing was the additional attack surface added by AVIF, and while it's probably more complex than JPEG-XL's container alone, it's definitely less complex than a full JPEG-XL decoder.

Filligree 3y ago

Then why is it C/C++? To be allowed into the browser, a new codec ought to be implemented in a memory-safe language.

lifthrasiir 3y ago
Because browser vendors have already invested too much into the existing C/C++ code base. They can thus accept new code with the same degree of coding standard.
- acdha 3y ago
  Those same vendors are using Rust and Swift now which have comparable performance and solid interoperability. It seems like time for a policy saying new internet-facing code be implemented in a safe language.
  - saagarjha 3y ago
    Browser vendors are ahead of you on this. They just need time to put it into practice.
    - acdha 3y ago
      Yes - I know both Mozilla and Chrome are doing this. The main thing I was thinking is that it’d be a lot more supportable if the response was, say, “we’ll add JPEG-XL only in Rust”.

acdha 3y ago

> High-profile C/C++ projects can't prevent all security bugs, but they can make them easier to find and harder to get in. AVIF and JPEG XL roughly have the same impact in this regard (written in C++, uses Google's standard convention, tested and fuzzed regularly, and so on). Isn’t all of that true of libwebp? I’m sympathetic to the argument that it’s a lot of work to replace C but I’ve been hearing that C/C++ will be safer with enough diligence and better tools since the 90s and it hasn’t happened yet.

lifthrasiir 3y ago
Correct, hence "[they] can't prevent all security bugs". They are written in C/C++ primarily because their primary users (e.g. web browsers) will still use C/C++ anyway, so the interoperability is more important. This is changing thanks to Rust and other languages, but the pace is still much slower than we hope.

brigade 3y ago

AV1 video support was already a baseline since Youtube and other websites really want to use it, so AVIF didn't add any attack surface with the decoder. (this is also unlike WebP vs VP8, since WebP added a lossless mode which is quite literally the part this vuln is in) HEIF container parsing was the additional attack surface added by AVIF, and while it's probably more complex than JPEG-XL's container alone, it's definitely less complex than a full JPEG-XL decoder.