4 ms·

Does anyone have an estimate on how much work it is to maintain support for JPEG XL in Chrome? Your comment sort of implies that it's the kind of thing they'd n

Does anyone have an estimate on how much work it is to maintain support for JPEG XL in Chrome? Your comment sort of implies that it's the kind of thing they'd need to really weigh the pros and cons of before pushing their chips forward, but my (unfounded) assumption is that, having implemented it in the first place, the maintenance would be relatively low, essentially a dim star in the constellation of things a browser manufacturer has to maintain support for. So, it just feels odd that, faced with at least some criticism from the community, and in the face of growing support for the format (e.g. from Apple) they would choose to dig their heels in on this issue.

izacus 3y ago
It's a C++ library that Google needs to secure and maintain security patches forever. If there's any bug in that library, it's Chrome and Google that will get blasted and blamed by rabid news media and HNers - so people here are essentially demanding that private company supports and patches their library for ever and ever. Once released, it's pretty much impossible to rollback support for media formats on the web. Behaving like there's no cost in such maintenance is just whack.
- josefx 3y ago
  > It's a C++ library that Google needs to secure and maintain security patches forever. Compile it to wasm and run it in a sandbox? Or throw some rust groupies at it? > Once released, it's pretty much impossible to rollback support for media formats on the web. We must live in a time where flash still dominates short web animations, streaming providers use silver light and every enterprise user is stuck waiting for the companies 5GB Java applet to load right when IE6 suddenly pops up to kill everything with an ActiveX based Windows update that adds more video codecs instead of removing them from the system. The list goes on forever. Browsers are not above killing features and breaking things for security reasons or if they just feel like it.
  - magicalist 3y ago
    Maintaining your own rust fork of a codec or forcing the web through another painful breaking change drawn out over years seem like fantastic arguments to wait until the ecosystem is visibly moving to jpegxl before committing to it, actually.
    - spider-mario 3y ago
      It wouldn’t be a fork, it would be another implementation. There are already a few.
- jeffbee 3y ago
  Chrome uses WUFFS to decode GIFs. It could also use WUFFS to decode JXL, if WUFFS supported JXL.
zdragnar 3y ago
Supposedly, the person who initially submitted the patch to add jpeg xl support has been keeping it up to date in the event that chromium wants to re-introduce it. If that's the case (and if the implementation is sufficient, rather than a leaky prototype) it would seem that the burden is quite low.
lonjil 3y ago
The JXL team at Google Zurich offered to take on JXL-related maintenance work in Chrome, but they were rejected.
13of40 3y ago
This might seem crazy, but I can imagine a world where the first time my browser encounters a file of some new format it gives me the option to download a codec to render it and it doesn't matter if it's google software or not, just that it's signed with a trusted cert.
- cesarb 3y ago
  > I can imagine a world where the first time my browser encounters a file of some new format it gives me the option to download a codec to render it That world existed, in the 90s and early 2000s, and it was called "ActiveX". The codebase= attribute of the <object> element exists for that use case. It sucked, for two major reasons: first of all, it was a reliable way to get malware into user's machines (being "signed with a trusted cert" doesn't help when all you need for a trusted cert is money and/or hacking a trusted software publisher). Second, it was very Windows-specific, and a significant obstacle to the adoption of alternative operating systems, hardware architectures, and browsers.
  - 13of40 3y ago
    I don't think it was the idea behind ActiveX that made it suck, it was the implementation. Back when we were making Windows XP I found a ton of exploits where you could load an arbitrary COM component from a web page and buffer overrun it. If the same thing was based on modern sandboxed IL it would be a lot safer and more portable between platforms.
  - Dylan16807 3y ago
    Activex did way more than render things.
- arp242 3y ago
  We tried the whole plugin thing with NPAPI and ActiveX, and it was a never-ending source of security holes. This is one of those things that sound nice, but there's a lot of practical caveats, and in reality it would all be pretty complex. Who would provide the "trusted certs"? How do you decide between a "good and safe plugin" and "not so good and unsafe plugin"? How do you update these decoders? etc.

izacus 3y ago

It's a C++ library that Google needs to secure and maintain security patches forever. If there's any bug in that library, it's Chrome and Google that will get blasted and blamed by rabid news media and HNers - so people here are essentially demanding that private company supports and patches their library for ever and ever. Once released, it's pretty much impossible to rollback support for media formats on the web. Behaving like there's no cost in such maintenance is just whack.

josefx 3y ago
> It's a C++ library that Google needs to secure and maintain security patches forever. Compile it to wasm and run it in a sandbox? Or throw some rust groupies at it? > Once released, it's pretty much impossible to rollback support for media formats on the web. We must live in a time where flash still dominates short web animations, streaming providers use silver light and every enterprise user is stuck waiting for the companies 5GB Java applet to load right when IE6 suddenly pops up to kill everything with an ActiveX based Windows update that adds more video codecs instead of removing them from the system. The list goes on forever. Browsers are not above killing features and breaking things for security reasons or if they just feel like it.
- magicalist 3y ago
  Maintaining your own rust fork of a codec or forcing the web through another painful breaking change drawn out over years seem like fantastic arguments to wait until the ecosystem is visibly moving to jpegxl before committing to it, actually.
  - spider-mario 3y ago
    It wouldn’t be a fork, it would be another implementation. There are already a few.
jeffbee 3y ago
Chrome uses WUFFS to decode GIFs. It could also use WUFFS to decode JXL, if WUFFS supported JXL.

zdragnar 3y ago

Supposedly, the person who initially submitted the patch to add jpeg xl support has been keeping it up to date in the event that chromium wants to re-introduce it. If that's the case (and if the implementation is sufficient, rather than a leaky prototype) it would seem that the burden is quite low.

lonjil 3y ago

The JXL team at Google Zurich offered to take on JXL-related maintenance work in Chrome, but they were rejected.

13of40 3y ago

This might seem crazy, but I can imagine a world where the first time my browser encounters a file of some new format it gives me the option to download a codec to render it and it doesn't matter if it's google software or not, just that it's signed with a trusted cert.

cesarb 3y ago
> I can imagine a world where the first time my browser encounters a file of some new format it gives me the option to download a codec to render it That world existed, in the 90s and early 2000s, and it was called "ActiveX". The codebase= attribute of the <object> element exists for that use case. It sucked, for two major reasons: first of all, it was a reliable way to get malware into user's machines (being "signed with a trusted cert" doesn't help when all you need for a trusted cert is money and/or hacking a trusted software publisher). Second, it was very Windows-specific, and a significant obstacle to the adoption of alternative operating systems, hardware architectures, and browsers.
- 13of40 3y ago
  I don't think it was the idea behind ActiveX that made it suck, it was the implementation. Back when we were making Windows XP I found a ton of exploits where you could load an arbitrary COM component from a web page and buffer overrun it. If the same thing was based on modern sandboxed IL it would be a lot safer and more portable between platforms.
- Dylan16807 3y ago
  Activex did way more than render things.
arp242 3y ago
We tried the whole plugin thing with NPAPI and ActiveX, and it was a never-ending source of security holes. This is one of those things that sound nice, but there's a lot of practical caveats, and in reality it would all be pretty complex. Who would provide the "trusted certs"? How do you decide between a "good and safe plugin" and "not so good and unsafe plugin"? How do you update these decoders? etc.