4 ms·

To be fair issues in jpeg decoding libraries also have been used in the past as vector for malware payload. While the webp ecosystem is far less mature, I am pr

• lifthrasiir 3y ago
  > 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.
• acdha 3y ago
  To be clear, I’m not saying we shouldn’t add new formats - more that it’s one of those “take the developer’s estimates for how long it’ll take and double them, and then put a zero on the end” situations. I’m not sure WebP was worth it but AVIF definitely is and both of them do have one advantage over other formats if they can share code with VP8 and AV1, respectively, since browsers were definitely going to ship those. What I wonder is whether this is saying there should be two tiers, where stuff like JPEG XL might be implemented in WASM for better sandboxing so browsers could more easily add support with less security risk and then possibly “promote” it to a core format if it proves successful and there’s enough performance win.
  • toastal 3y ago
    Except no one will want to ship an encoder/decoder for performance (network & CPU) as well as requiring JS. It would take of images to break even on the cost of shipping the WASM—so these things would never get adopted.