this post was submitted on 10 Aug 2024
590 points (98.5% liked)
Privacy
32045 readers
786 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Matrix isn't secure depending on how you use it. It also doesn't protect individual identities terribly well.
Simplex Chat would be the better option however the main Simplex Chat server and matrix server could end up blocked as well.
Matrix is entirely self-hostable, and you can turn off both federation, and the requirements for any linkable identifiers.
Signal by contrast requires your phone number, isn't self-hostable, and is based in a five-eyes country.
Matrix doesn't protect metadata, which is arguably just as (if not more) important than message data. Signal by contrast does protect metadata and proper implements Perfect Forward Secrecy for all chats. I do think Signal's centralized design and phone number requirements problematic, but Signal still has many merits. Such as its massive user base for a AGPL-only project.
Matrix also implements Perfect Forward Secrecy, and that's been the case for a very long time: https://security.stackexchange.com/questions/162773/are-matrix-messages-encrypted-using-perfect-forward-secrecy
What do you mean by AGPL-only? Synapse is also AGPL. And you can only guarantee that there won't be projects with other licenses if you prevent them from existing.. which is not something to be desired
Isn't it? Maybe I'm misunderstanding something, so let's start from the definition. PFS is when future joined users can't read messages sent before they have joined, right?
In that case, it is not just implemented, but cannot be avoided and is a major hassle to deal with. In my understanding when someone joins, all members start a new olm session, meaning they now encrypt future messages with a new key. The old keys are not being sent to the joined users, not even if the room has been set up to allow reading history, and this results in them only seeing undecryptable messages, and all the metadata you're taking about (except when the client hides these to reduce new user's confusion).
Former keys are not shared among clients for now because there's no mechanism (for now, but this is planned) to verify that a new member is actually a legit member, not just someone popped in by the server admin by DB editing or whatever.
Earlier there was a workaround mechanism, where with element clients, when you have invited someone, your client has sent keys to all the previous messages which it had, to the invited user. That was not (yet?) reimplemented in their new crypto library, but apparently they're working on it.
But the point is, that afaik PFS is on and cannot be disabled for encrypted rooms, new rooms are encrypted by default, you have to toggle that off by yourself if you don't want it, and it can't be toggled off after room creation.
That's right. I don't think that'll ever change, but it's for sure that it'll not change for a long time, because fundamental changes would be needed.
But! For when that is a concern, you are not entirely unprotected. For example you can set up a room to never federate, or only federate with specific homeservers. If your group runs their own, on owned real hardware, information can't really leak from your control.
In my experience, room encryption is opt-in and permanent for a room.
Indeed.
It is optional, but enabled by default when you create a room, at least in the element clients.
Citation needed. It is undisputed that the software that runs on their servers is not identical to the code they release; if they release at all because sometimes they just stop for a year or two, until people complain 🫠
This is false. You still need a phone number to sign up and it is used as an internal identifier.
All they did is to optionally allow you to hide your phone number from other users.
plenty of servers for both though
Couldn't they block them too? Monitor the domains people connect to, check if it's a Matrix server and block it if it is.
You don't need any blockchain there, you need mixnets and hidden services like with tor and i2p
What would a blockchain provide here?
buzzwords
Overhead
The overwhelming majority of users are on the main servers. It also impacts self hosted Matrix servers that use the matrox.org identity server.