News for hackers. Stuff that matters.
Re:Chrome still hasn't changed its opinion about dropping JP... by karaterobot on Tuesday June 06, 2023 @11:56AM (#36214776)
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.
Re:Chrome still hasn't changed its opinion about dropping JP... by 13of40 on Tuesday June 06, 2023 @12:24PM (#36215199)
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.
Re:Chrome still hasn't changed its opinion about dropping JP... by arp242 on Tuesday June 06, 2023 @12:40PM (#36215487)
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.

Re:Chrome still hasn't changed its opinion about dropping JP... by cesarb on Tuesday June 06, 2023 @12:38PM (#36215448)
> 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.

Re:Chrome still hasn't changed its opinion about dropping JP... by 13of40 on Tuesday June 06, 2023 @01:40PM (#36216401)
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.
Re:Chrome still hasn't changed its opinion about dropping JP... by Dylan16807 on Tuesday June 06, 2023 @02:34PM (#36217160)
Activex did way more than render things.
Re:Chrome still hasn't changed its opinion about dropping JP... by zdragnar on Tuesday June 06, 2023 @12:07PM (#36214912)
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.

Re:Chrome still hasn't changed its opinion about dropping JP... by lonjil on Tuesday June 06, 2023 @12:10PM (#36214965)
The JXL team at Google Zurich offered to take on JXL-related maintenance work in Chrome, but they were rejected.
Re:Chrome still hasn't changed its opinion about dropping JP... by izacus on Tuesday June 06, 2023 @12:06PM (#36214892)
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.

Re:Chrome still hasn't changed its opinion about dropping JP... by josefx on Tuesday June 06, 2023 @01:10PM (#36215959)
> 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.

Re:Chrome still hasn't changed its opinion about dropping JP... by magicalist on Tuesday June 06, 2023 @03:37PM (#36218024)
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.
Re:Chrome still hasn't changed its opinion about dropping JP... by spider-mario on Thursday June 08, 2023 @09:05AM (#36241215)
It wouldn’t be a fork, it would be another implementation. There are already a few.
Re:Chrome still hasn't changed its opinion about dropping JP... by jeffbee on Tuesday June 06, 2023 @02:23PM (#36217022)
Chrome uses WUFFS to decode GIFs. It could also use WUFFS to decode JXL, if WUFFS supported JXL.