Hacker News new | ask | show | jobs
by padjo 1049 days ago
How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?
2 comments

Integration of a new decoder is not all that complicated code wise. What is complicated is the effects of the change and ongoing support.

1. Binary size cost, in my experience working on Firefox this is in the 100s of KiB range when adding a new decoder.

2. Ongoing costs increased compile times, new integration tests, functional tests and so forth. Keeping those tests passing and non-flaky.

3. Once something is accepted into the web ecosystem the intention is to support it for 10s of years if not forever. Web feature deprecation is quite slow, ex <keygen> & <blink>. The web has not deprecated a primary image format.

4. Security, a 'new' binary format is a place for security vulnerabilities, crashes and hangs. The web is actively hostile place for web browsers.

For a browser, it means permanent, forever, support for the format and continued maintenance and security patching for the library. Any CVE, any issue that might cause the browser to be insecure will be blamed on the browser and the developers will have to make sure any codec they use is safe forever.

That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (they're complex code that handles malicious downloaded files) and supporting a new one is a rather big maintenance burden for everyone involved.

And if Chrome gets backdoored by a JXL library security hole, everyone will blame Google for it.

If, by any chance, supporting JXL becomes too much of a burden, everyone will again blame Google for being evil if they ever remove it from Chrome.

These sound like good reasons to quickly disable AVIF and move fully to JPEG XL. AVIF is about 3-5x more code than JPEG XL.