I really appreciate your argument, Dong. There was a study I read some time ago, I cannot find it now, which theorized that SETI is critically dangerous to civilization because it is impossible to prevent crafty, malicious aliens from starting something like a suicide cult religion using very convincing messages, no matter how the SETI receiver operators are isolated or restricted in the kinds of messages that they can pass. I think it’s important not to give up on security at all layers but still keep in mind the practical needs of communication.

This is all a fuckup by the responsible vendors Apple and Google who aren't using commercial static analyzers that can easily detect this sort of buffer overflow. They both have billions in cash to pay for dedicated engineering teams to do this work.

Are you saying it's bad that Apple's using an open source solution, or that Clang Static Analyzer (built into Xcode) is bad specifically? https://www.youtube.com/watch?v=jajgCfkLNdk

But the initial security issue was in libwebp, which is made by Google, and surely Google had already fuzzed it and run all the available static analyzers in the world.

Static analyzers are nice to have, but they can't warn of every issue out there.

The initial security design failure was inventing lossless WebP, which is a completely different format from lossy WebP, which means the library has double the code for double the attack surface.

I am skeptical inventing any kind of WebP was a good idea, but I know the inventor and he got mad at me last time I said that, so I won't.

Maybe because going "I think WebP was a bad idea" when its implementation has the same bugs in it that every other image parser has is not a very useful comment to make.

I think there’s a stronger form of the argument: image formats are expensive to create and secure, and that should have factored into WebP adoption given its marginal benefits.

The lesson I hope was learned is that nobody should be writing new parsers in an unsafe language. WebP is old enough that it was defensible at the time but everyone should have a “no new C/C++” policy for internet-facing code.

Yes, I think we’re going to see this moving forward. The tools are in place to make this possible.

No, it's a bad idea because they based it on a video codec and then released a much better video codec a year later but couldn't update it.

It's not better enough than JPEG to be worth existing.

The same could be said for half the formats Apple ships: HEIF/HEVC, for example. Or even LZFSE: who asked for an algorithm that compresses worse, slower?

It could but HEVC is actually an open standard, whereas WebP is a proprietary codec they bought and then released with no community feedback. (That's why the next VPx codec was better.)

Also HEIF actually has useful features, it supports HDR!

AVIF is certainly better though. I only feel positively about AVIF and JPEGXL.

The Isosceles blog post[0] on the initial webp exploit, linked by the article, says:

> Google's OSS-Fuzz project has fuzzed hundreds of open source libraries for many years now, including libwebp and many other image decoding libraries. It's possible to look in full detail at the code coverage for OSS-Fuzz projects, and it's clear that lossless support for WebP was being fuzzed extensively… In fact one of the first things that Google did after the WebP 0day was fixed was to release a new fuzzer specifically for the Huffman routines in WebP. I tried running this fuzzer for a bit (with a bit of backporting required due to API changes) and it predictably did not find CVE-2023-4863… This bug also shows that we have an over-reliance on fuzzing for security assurance of complex parser code. Fuzzing is great, but we know that there are many serious security issues that aren't easy to fuzz.

So perhaps it’s not so simple as throwing a fuzzer at it.

[0] https://blog.isosceles.com/the-webp-0day/