Posted by LorenDB 11/20/2025
That's confusing even for very technical people; because, it simply doesn't make sense.
Saying "verified or primary client with recovery keys generated" seems too long, so they should just say something like "less secure" on the "unverified" sessions.
I don't like the way groups/chatrooms are displayed to be honest. Its confusing. It feels like its trying to get away from the "server room/#somechat" model that works well with IRC and even with trendy current products like Discord.
If this is that case what will happen is that people will start verifying everyone (because they might want to text to strangers that they can't bother verifying because the stakes are so low) and so verification will lose all meaning.
SSH is an example of TOFU.
You still can... it just displays a warning message on first use, as does ssh.
A domain can layer on HSTS to that, which directs clients to additionally refuse to trust a new cert for a domain until the one you currently trust has expired.
Self-verification means that any new secondary devices you log into your account with will need to be verified by an existing login by way of an automatic popup that asks if you trust the device. It used to just be a Yes/No button but I think now they've added QR codes and/or emoji matching.
The other kind is verification between two different people, like when starting a direct message conversation, you might get the same emoji matching window to verify each other.
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.
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.
Yes? :)
Given the choice, the vast majority of people would pick convenience over the kind of security that requires this much effort.
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.
iMessage and Whatsapp are both mainstream.
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".
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.
Normal users do find retention important even if privacy/security minded users find value in ephemerality.
Here's the thing. You can already! Whether you should or not.
I'm in favor of the change, the only downside I can think of is users with esoteric clients or simple bots that don't support verification won't be able to post to encrypted rooms with element users.
I feel like I'm alone in having good luck with matrix. I've been self hosting for nearly a decade to a handful of users, and it was a bit rough troubleshooting the encryption problems back when element was still called riot, but it's been a number of years since any of us have had a single encryption issue, and we added a new user recently with no trouble. we're still on 'element classic' though, the new 'element x' is a bit of a mess and loses the background sync feature, you need to set up a unified push server which I'm not looking forward to.
Self hosting the call/video feature became a lot more complicated though (and it's incompatible with the old system).
I'm still going to get around to it, because element classic will be deprecated eventually. one of my users is on iOS and has a well-known bug with images not loading, which will probably never get fixed because they're focusing on the new client. and unfortunately I do have users that expect voice calls to work, so it sucks to hear that'll be annoying too.