quikoa 6 hours ago

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.

Reply View 10 replies
  • pixelesque 6 hours ago

    Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.

    Reply View 6 replies
    • adzm 6 hours ago

      And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.

      Reply View 5 replies
  • gcr 3 hours ago

    Google refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.

    Reply View 2 replies
    • zaphar 2 hours ago

      Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.

      Reply View 1 reply
      • themerone an hour ago

        If you look at the issue tracker, the creator of Webp killed it because of untrue claims there was no interest or advantages over existing formats.

        Concerns about the implementation only came up after years of pushback forced google ton reconsider.

        Reply View 0 replies
WhereIsTheTruth an hour ago

> Rust certainly calms security fears

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

Reply View 1 reply
  • rkangel an hour ago

    > 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.).

    Reply View 0 replies