So, I was told to not use Signal, so all that is left is Matrix. And I am not techy enough to have my own server and neither are my relatives, so Matrix.org is the only option
So, I was told to not use Signal, so all that is left is Matrix. And I am not techy enough to have my own server and neither are my relatives, so Matrix.org is the only option
Probably yes, it depends on your threat model.
If you are using E2EE on a matrix.org account then your message content, attachments (images) and most other traffic isn’t accessible to anyone but the people in the chat. However Matrix isn’t the most private option, it has a number of leaks such as reactions and chat topics (these are being worked on but aren’t close to happening).
For most people Matrix is a very private and secure option and the fact that it is federated is a huge plus. If you want something more secure you are probably looking at Signal (which you don’t want to use and isn’t federated) or Simplex Chat (which doesn’t have multi-device support).
Unfortunately even with E2EE, the admins of a homeserver can still impersonate you or take over your channel.
Of course you could run your own instance, or maybe none of this is part of your threat model, but I felt like bringing it up either way.
No, they cannot. Your homeserver admin could create an impostor login session on your account, but it would be pointless with E2EE, because it would be flagged with an obviously visible warning. You and all of your contacts would see that the impostor session was not verified as you (this typically shows up as a bright red icon on the impostor and another one on the room they’re in) and the impostor would be unable to read your communications.
What do you have to say about this then?
Perhaps we have a different definition of “impersonate”… not everyone will pay attention to unverified warnings, and afaik they can still communicate with people (just maybe not read old messages)… but I would love to be proven wrong.
A compromised server could affect a denial of service attack against its users, of course. The attacker could do the same thing by simply turning off the server. That’s true on all platforms that use servers. A reasonable response would be to switch to a different server.
Exactly what events do you think would be dangerous?
No. End-to-end encryption ensures that only the intended endpoints can read the messages. Older Matrix clients have a setting to block the user from sending messages to unverified devices/sessions, in case they somehow don’t understand the meaning of a bright red warning icon. I think newer ones (e.g. Element X) enforce that mode; if you’re concerned about this, you could check for yourself, but…
…unfortunately, there are no guarantees when trying to fix human behavior. If you need a messaging app to make it hard for your contacts to do something obviously foolish, then I suggest waiting until Matrix 2.0 is officially released and implemented in the clients. The beta versions of Element X, for example, look like everything is locked down to avoid human mistakes like the one you’re describing.
But who/what gets to decide who the intended recipients are? Can’t the homeserver admin just join the channel and then the other members would exchange keys automatically and now they can see what people say?
The sender, of course.
No. Verification prevents that.
I don’t understand. How would the sender prevent messages from going to the admin user that joined the room? It sounds like you’re implying new users simply can’t join a room? That makes no sense to me… I’ve certainly never experienced that. I see new users join encrypted rooms all the time and they can talk just fine… so what’s the deal? And isn’t verification off by default?
It wouldn’t matter if a rogue admin eavesdropped on an E2EE room, because they would see encrypted blobs where the message content would be. That’s what E2EE is for.
https://en.wikipedia.org/wiki/End-to-end_encryption
You’re conflating multiple things. Merely joining a room does not grant access to message decryption keys.
I respect your curiosity, but I think you’re going to have to familiarize yourself with the software and concepts to get a detailed understanding of how all this stuff works. If you’re technically inclined, I suggest reading the protocol spec, or at least the parts that interest you. You could also drop in to the public chat room and ask more questions there: #matrix:matrix.org