That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.

And a nominally “lossless” image may have been reencoded from a lossy source.

This is probably an unpopular opinion but I think that if all this effort went in to improving Firefox, or a fork of Firefox if the goal is to totally de-Google it, then that wouldn't be such a problem and it would overall be healthier for the web. I don't really understand the purpose of this titanic software engineering effort just to avoid... a default search engine setting?

> if all this effort went in to improving Firefox, or a fork of Firefox

Someone tried to instigate that on Mastodon recently. It didn't work.

https://mastodon.social/@sarahjamielewis/116959309031485270

Spread the word. Contact the developers, ask them.

The forks I know about:

• Waterfox -- https://www.waterfox.com/

• Librewolf -- https://librewolf.net/

• Floorp -- https://floorp.app/

• Zen browser -- https://zen-browser.app/

• Mullvad -- https://mullvad.net/en/browser

• Konform -- https://codeberg.org/konform-browser

Others:

GNU IceCat – https://www.gnu.org/software/gnuzilla/

Mercury – https://thorium.rocks/mercury

I fear it would be hard to get some of the earlier forks on board... these are all based on much older codebases:

• Palemoon -- https://www.palemoon.org/

• Basilisk – https://www.basilisk-browser.org/

• Seamonkey – https://www.seamonkey-project.org/

I think you misunderstood: the point was sometimes project corruption is due to a defect in our software, in which case it is definitely our fault and we race to fix it. But most reports of corruption are bad zip files, which aren't our software (unless you think the widely used and battle-tested library zip.js is writing bad zip files, which I don't think is the case). My best guess is it's faulty hardware or system-level issues.

Author here: we write zip files with the widely-used library zip.js [1], so if that's writing bad zip files, the problem is going to be widespread across many web apps. But I'd argue that zip.js is thoroughly battle-tested (current open issue count: 0) and not the cause of the problem.

[1] https://gildas-lormeau.github.io/zip.js/

Thank you for replying back with relevant details.

Are you perhaps zipping something that other zip.js apps are not? Perhaps you have stumbled upon some edge case.

If the exact words we choose when writing matter so much, then why use a non-deterministic LLM that produces slightly different output on every run?