"Now the end-to-end encryption will leak into the UX even more and you better like it"
I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mean that the user doesn't have to do any extra actions whatsoever to make it work.
If that's true, then E2EE will never become mainstream. Consider this scenario: "My phone got lost/stolen/broken, so I just got a new one. I haven't logged in to this app since I got my last phone, so I forget my credentials for it. I'll reset them through my email. What do you mean my conversation history is gone?"
That's not really far-fetched. If you can get your conversation history back in that scenario, then so can the server operator so it's not real E2EE, and if you can't, then by your statement it won't become mainstream.
I more or less agree. And I also agree with the other commenter who says this may mean e2ee will never become mainstream. I think a lot of e2ee enthusiasts don't realize that the overwhelmingly most important feature for a messaging system is "when I log in, I can see all my messages". If there is a chance of that not happening, you're going to lose a lot of users.
I think there's the potential for a slight middle ground, but it would involve giving up a lot of the e2ee bells and whistles that privacy enthusiasts enthuse about (like perfect forward secrecy). You could image for instance a system where you have a single e2ee password and your data is encrypted on the server with that password. When you log in, you supply two passwords: your login password and your e2ee password. Then you have access to everything.
This tends to irritate people on both sides, since you can still lose your messages if you forget your e2ee password, and your privacy guarantees are also weaker, since the e2ee password can be a single point of failure that allows someone to read your messages. But people already rely on this level of security in other contexts. For instance, some cloud backup solutions encrypt your backup with a single passphrase. People are okay with having one password to unlock their entire hard drive's worth of data but not with one password to unlock their chat history?
I think it's worth exploring the space of e2ee solutions to find something that finds the balance between the levels of privacy and convenience that most users want. The thing is that existing apps that tout e2ee often do so to appeal to hardcore privacy advocates or people like dissidents in authoritarian states who are at risk of death if their messages are discovered. This level of security simply isn't a concern for the average person, and so they're not willing to take on the inconveniences that go along with it.
Technically they are, but neither of them fits the strict definition of a E2EE messaging app, while also still hurting the UX.
Whatsapp is very insistent about backing up your messages to cloud services without encryption. To use it on desktop, you have to make everything go through your phone. And, afaik, you still can't transfer message backups between Android and iOS.
Even disregarding the extreme gatekeeping, iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
> iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
It relies on Apple device managing your encryption keys, no? Which, yes, Apple can still access if it really wanted to simply by virtue of being able to push an iOS update that does that. But the same exact vulnerability applies to any app running on your iPhone.
>Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
This is simply not true, any serious analysis of Signal would be performed on the binaries and not the source code. Having access to the source code does not make it any easier to discover well-hidden backdoors, but it is possible to exploit e.g. compiler behaviour in a way to create a backdoor that is essentially impossible to detect by reviewing source code.
Access to source code might very well make it easier to discover non-intentional bugs, but does not solve the problem of trust.
I mean we’re there for Signal. The parts that suck still are regarding access/retention of old messages which is an area Matrix is ironically slightly better about. But Signal we don’t need to think about verification, at worst it says this asshole has a new identity and then I have to tell them I’ve reset my iPhone for the 4th time this week…
Normal users do find retention important even if privacy/security minded users find value in ephemerality.
Officially it supports linking other devices like their desktop app as a secondary. I currently use this to link into signal-mautrix on my matrix homeserver. This way I can access signal from multiple phones and multiple computers using a matrix client instead.
But you still need one "primary" device and it has to be a phone, right? That's different from Matrix where you can have arbitrary devices that are all on an equal footing.
Yes. And, annoyingly, when you only use Signal occasionally, these desktop sessions expire. And you have to link again. And when you do, you end up with a gap in your conversation history because "security".
I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mean that the user doesn't have to do any extra actions whatsoever to make it work.