I took this to mean "in the simple case" (which would be ECB), but the wording could be improved here to make that clearer.
Right, especially since a few paragraphs down, he introduces all the different modes, including ECB.
To me at least, it makes sense to introduce a complex topic gradually, in stages. But regardless, I still agree that the wording in the paragraph you called out could be improved for better clarity.
Sorry to keep hammering on this, but ...
I don't know in what context it would be reasonable even as a simplification to say that block ciphers are semantically insecure like that. Anyone who listed that as a disadvantage to block ciphers should be regarded as confused, not speaking from a big picture perspective.
Furthermore, even if you're going to explain it that way as a result of building up the complexity gradually, you need to explicitly "unring" that bell, e.g. "Earlier I said X, but actually Y...". This author didn't.
> A block cipher is so-called because the scheme encrypts one block of data at a time using the same key on each block. In general, the same plaintext block will always encrypt to the same ciphertext when using the same key in a block cipher whereas the same plaintext will encrypt to different ciphertext in a stream cipher.
A block cipher will turn the same plaintext into the same ciphertext only if you're using it with the ECB mode; otherwise, the same plaintext in different places with the same key will encrypt into different ciphertext.
If he means "key" in the sense of "final thing that gets XORed to make the ciphertext", then that's true, but then it's equally true of stream ciphers as well.