[Andrew_nenakhov]

Not really. E2EE imposes severe limitations on user experience:

Want a fast server-side archive search? Forget it, you're using e2ee.

Want to add a new device and load all your chat history? Forget it, you're using e2ee.

[maqp]

The first case might be true (at least until homomorphic encryption matures), but client-side encrypted cloud backups are already a thing, e.g. Signal is working on it: https://signal.org/blog/secure-value-recovery/

[Andrew_nenakhov]

Just stop and think about it for a second. End to End Encryption means that the data is encrypted between TWO ends, your device and the device of your chat partner.

Now, by downloading and decrypting it on another device, you are adding a THIRD end where is is accessible. To achieve that, you have basically two options: one is to pass over decryption keys to a new device (potentially breaking E2EE security model for another guy who does not expect you to use 2 devices without his explicit authorization), and another approach is to do an own encrypted archive to store data and sync between your devices. You basically encrypt data and store it on a server, decrypting it with your password or certificate or something that you share between devices. It's not E2EE at all, actually, cause you'll be breaking the security model for some convenience, because the idea of e2ee is to communicate only with devices, each and every one of which were authorized by you. If you don't follow this rule, you make a travesty out of E2EE, basically stating that all you really need is a nice and cozy feeling of being secure, not true security.

You have to face it: true E2EE is not achievable without significant sacrifices of user experience.

[maqp]

>Now, by downloading and decrypting it on another device, you are adding a THIRD end where is is accessible

You're not thinking straight. End-to-end encryption does not refer to two devices, it refers to two parties. If you have two devices that can receive the message, that's still only accessible to you.

>one is to pass over decryption keys to a new device (potentially breaking E2EE security model

That's just stupid, you can scan e.g. public key of the other device and then have your device send packets to that

>and another approach is to do an own encrypted archive to store data and sync between your devices.

Which is perfectly valid provided the user has to create sufficiently secure password.

> It's not E2EE at all

The reasoning how you came to claim this is beyond moronic.

>actually, cause you'll be breaking the security model for some convenience

You aren't breaking anything. Claiming things without reason is moronic.

>because the idea of e2ee is to communicate only with devices

No the idea is only you and your peer have access to the data. You can't be serious.

>each and every one of which were authorized by you

Yeah that is kind of what happens with proper E2EE, only you have access to your data on devices you've authorized by e.g. scanning the QR code of the trusted instance.

> basically stating that all you really need is a nice and cozy feeling of being secure, not true security.

Geez, maybe start by learning how cryptographic protocols work before making such claims.

>You have to face it: true E2EE is not achievable without significant sacrifices of user experience.

Majority of them are with smart cryptographic design. The claims you made were more hand waving than I've ever seen before. Incredible.