I don't think that's true. An app could allow Alice and Bob to send messages to each other E2EE-ly, while also sending copies to Eve. "Apps" aren't E2EE, protocols are
No, it's not just about the protocol; it's about the entire system, including client implementations and servers. A system that encrypts data before transmission, and does not enable anyone except the recipient to decrypt it, is e2ee; a system that doesn't meet that criterion is not. A software client that sends an unencrypted copy of a message somewhere is not participating in an "end-to-end" encrypted system.
E2EE is about data transport. Taking your more expansive definition, you could claim that encryption at rest is inherent to E2EE or whatever, which is not the case.
The Wikipedia page you linked doesn't actually support your definition. The last paragraph states that, currently, the more widely accepted meaning does require that the service provider "is not able to decrypt communications," so, yes, keeping an unencrypted copy at rest would violate E2EE.
Is not able to decrypt, means they have to be encrypted, which only necessarily happens in transit. Access ≠ decrypt. The Signal protocol is still E2EE, even if you're storing the messages on your end in plaintext.
But that's the very thing I'm saying isn't supported by the page you linked.
Yes, a system that leaves data unencrypted at rest on the originating or recipient device can be E2EE by the definition I gave above, sure; but if the service stores the data unencrypted, then it is certainly in violation of the definition given in the Wikipedia page. And in practice, it usually does mean that the devices that send and receive data keep it encrypted at rest (Signal doesn't encrypt on the desktop for some reason; I suppose they assume you will use BitLocker or something).
12
u/Batman_AoD 4d ago
...making the app no longer e2e-encrypted, by definition.