30 ms·

> Mozilla also isn't interested in supporting it Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put in

> Mozilla also isn't interested in supporting it Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready. https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064

masklinn 1y ago
You have a really strange interpretation of the word “consider”.
- mistercow 1y ago
  Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
  - masklinn 1y ago
    Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
    - OneDeuxTriSeiGo 1y ago
      From the link > To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it. That is a perfectly clear position.
      - deskamess 1y ago
        How far away is JPEG-XL rust version from Google if Chrome is not interested in it?
        ac29 1y ago
        You can review it here: https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs Seems to be under very active development.
m-schuetz 1y ago
Now I'm feeling a bit less bad for not using Firefox anymore. Not using it because it's C++ is <insert terms that may not be welcome on HN>
- mistercow 1y ago
  Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.
- kouteiheika 1y ago
  So you think it's silly to not want to introduce new potentially remotely-exploitable CVEs in one of the most important pieces of software (the web browser) on one's computer? Or are you implying those 100k lines of multithreaded C++ code are bug-free and won't introduce any new CVEs?
  - deleted 1y ago
    [deleted]
  - archerx 1y ago
    [flagged]
    - OneDeuxTriSeiGo 1y ago
      It's not about being completely bug free. Safe rust is going to be reasonably hardened against exploitable decoder bugs which can be converted into RCEs. A bug in safe rust is going to be a hell of a lot harder to turn into an exploit than a bug in bog standard C++.
    - mistercow 1y ago
      > and don’t think that the programmer more than the languages contribute to those problems This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part. Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.
out_of_protocol 1y ago
There's way more than one rust implementation around - https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs - https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide - https://github.com/etemesi254/zune-image https://github.com/etemesi254/zune-image Etc. You can wait for 20 or so years "just to be sure" or start doing something. Mozilla sticks to the option A here by not doing anything
- OneDeuxTriSeiGo 1y ago
  The jxl-oxide dev is a jxl-rs dev. jxl-oxide is decode only while jxl-rs is a full encode/decode library. zune also uses jxl-oxide for decode. zune has an encoder and they are doing great work but their encoder is not threading safe so it's not viable for Mozilla's need. And there's work already being done for properly integrating jxl implementations with firefox but frankly things take time. If you are seriously passionate about seeing JPEG-XL in firefox there's a really easy solution. Contribute. More engineering hours put towards a FOSS project tends to see it come to fruition faster.

masklinn 1y ago

You have a really strange interpretation of the word “consider”.

mistercow 1y ago
Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
- masklinn 1y ago
  Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
  - OneDeuxTriSeiGo 1y ago
    From the link > To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it. That is a perfectly clear position.
    - deskamess 1y ago
      How far away is JPEG-XL rust version from Google if Chrome is not interested in it?
      - ac29 1y ago
        You can review it here: https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs Seems to be under very active development.

m-schuetz 1y ago

Now I'm feeling a bit less bad for not using Firefox anymore. Not using it because it's C++ is <insert terms that may not be welcome on HN>

mistercow 1y ago
Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.
kouteiheika 1y ago
So you think it's silly to not want to introduce new potentially remotely-exploitable CVEs in one of the most important pieces of software (the web browser) on one's computer? Or are you implying those 100k lines of multithreaded C++ code are bug-free and won't introduce any new CVEs?
- deleted 1y ago
  [deleted]
- archerx 1y ago
  [flagged]
  - OneDeuxTriSeiGo 1y ago
    It's not about being completely bug free. Safe rust is going to be reasonably hardened against exploitable decoder bugs which can be converted into RCEs. A bug in safe rust is going to be a hell of a lot harder to turn into an exploit than a bug in bog standard C++.
  - mistercow 1y ago
    > and don’t think that the programmer more than the languages contribute to those problems This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part. Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.

out_of_protocol 1y ago

There's way more than one rust implementation around - https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs - https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide - https://github.com/etemesi254/zune-image https://github.com/etemesi254/zune-image Etc. You can wait for 20 or so years "just to be sure" or start doing something. Mozilla sticks to the option A here by not doing anything

OneDeuxTriSeiGo 1y ago
The jxl-oxide dev is a jxl-rs dev. jxl-oxide is decode only while jxl-rs is a full encode/decode library. zune also uses jxl-oxide for decode. zune has an encoder and they are doing great work but their encoder is not threading safe so it's not viable for Mozilla's need. And there's work already being done for properly integrating jxl implementations with firefox but frankly things take time. If you are seriously passionate about seeing JPEG-XL in firefox there's a really easy solution. Contribute. More engineering hours put towards a FOSS project tends to see it come to fruition faster.