I actually agree with you that not requiring an explicit IV is a bad interface choice.

On the other hand, I'm appalled by the idea of any library that exposes AES directly to applications anyways. There's a myriad of mistakes developers make using AES directly. CBC IVs are not among the top three.

But ECB mode may be a useful primitive component of some other, more secure, mode. For example, this API doesn't support CTR mode, but if you needed it, probably the most efficient thing would be to fill a buffer with your nonce and counter values pass it to this API to be encrypted using "ECB mode". It's parallelizable that way.

And that is the point of this level of crypto API: providing efficient access to whatever software implementation or hardware acceleration may be available on the target system.

And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default".

I want to give Nadim some credit here: he is thinking like an attacker now!

This represents a great improvement over his previous crypto implementation endeavors.

And, I agree with the fundmental point he's making: optional IVs for CBC mode are a bad interface details for lay programmers. Just remember, every AES library makes similar (usually worse) design mistakes.

Generalists are very poorly served by low-level AES libraries (where "low level" certainly includes any library where you have to think about IVs or, indeed, which block cipher mode to use).