I'm of two minds when it comes to reports like this.
On the one hand, of course I love that people have the means to audit assumptions.
Both the ability to do so w.r.t the project being transparent and open, but also through time and technical ability.
I am, however, a little upset when people poke at minor issues (that they themselves see as minor) and speak at length about them. *not* because those issues should not be addressed, but because it gives ammunition for people who recommend closed platforms, or more opportunity for people to think of the community as being more divided than it really is.
The more uncertainty a thing is surrounded by: the more people are likely to just say "fuck it" and choose any option as long as it works, and guess what works? Closed platforms, especially those with coherent messaging like facebook or whatsapp.
So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project.
I know it is going to sound like an ad-hominem, but once I realized that this is from the same person behind the "Grid protocol", I immediately closed the tab. This guy seems to be on a quixotic vendetta against msxid. It is the third or fourth persona (first it was from a personal account, then from his company, now he has even a non-profit advocating for privacy) that he created to re-hash the same old, outdated and irrelevant argument.
And the pathetic thing is, if he had spent more time working on his "Grid protocol" instead of pointless nitpicking, maybe he would have a lot more credibility on the matter.
I don't get this kind of thinking? How does the why of what he's saying influence the what? Or even worse, disqualify it? If it's factually correct then the reason behind writing it seems quite irrelevant, to me at least.
And you're mentioning it's outdated, which would be natural given that the last commit was over two years ago.
It was outdated two years ago already, people already back then assuming good intent and pointed out that the "issues" he complained about were being worked on, yet he adamantly continued to ignore it and claim that everyone using Matrix was being duped and that his implementation of the id server was the only way to go. That is why.
Ad hom would be saying the author smells like moldy cheese and therefore we should disregard his opinion.
The parent comment is not using ad hom. They're critiquing the author's work and assessing their credibility based off of that. It's perfectly fine, and a great viewpoint to consider.
> So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project.
Under "Purpose and Scope":
> This document is a research paper by Libre Monde ASBL, nonprofit dedicated to protecting people's privacy. We had the need to document privacy points for The Grid Protocol project, fork of the Matrix protocol.
So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. In fact, that might be why they are focusing on the issues they find, minors one included.
> So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor.
I was not aware of the Grid project, but they seem to make good points. Matrix is developed by a restricted group of people with a startup vibe and some cringy/questionable actions:
- spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ; which takes us to the situation where Matrix has the exact same selling points which XMPP had 20 years ago... and keeps on reinventing the wheel
- pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix clients are all incompatible with one another (because only Element implements them all) and once they have been upgraded rooms cannot be downgraded so in many places only Element can chat
- requiring a web rendering engine for certain extensions (eg. Video chat) ; HTTP is a decent foundation for a protocol, but why is a Jitsi <iframe> considered a decent extension mechanism? it will just harm security/privacy (through potential XSS) and make it near-impossible for clients to be implemented without a Chrome-based engine, reinforcing Google's monopoly on the web
- putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms; beyond clients, investing in bridging with useless platforms like Microsoft Teams (though i did not find the code for that) while neglecting interop with open protocols like IRC/XMPP (relations with IRC/XMPP people are notoriously not very good though i hope it will improve over time)
All in all, i'm very glad matrix exists because they have popularized bridging and they do care for UX concerns like Spaces. But claiming people who forked the project because of political and technical disagreements are biased because they are a "competitor" is itself a very biased position based on the idea that only one true protocol must remain and others are heretics trying to undermine our technical purity (for their economic gain).
I wish we could have people from different protocols sitting across the table and working on interop so we can stop arguing about which network is best.
> which takes us to the situation where Matrix has the exact same selling points which XMPP had 20 years ago... and keeps on reinventing the wheel
I don't get it. XMPP had MEGOLM, cross signing, decentralized chat rooms, good iOS support in practice, very simple sync of e2ee chat history, ... 20 years ago?
> spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ;
This simply so wrong: Matrix was created exactly because if the failure of existing protocols [0]. And the mentioned extension was one failure in their mind.
And imho it was the best thing to do.
You don't repair a car if repairing costs much more than getting a new one
> pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix
In fact there are 9 versions today. Though afaik only one of them was due to a broken consensus algorithm. Others exist for new features.
Strangely I can use even the latest ones with alternative clients such as Fluffy Chat - contrary to your claims
> but why is a Jitsi <iframe> considered a decent extension mechanism
It is? Source needed
Native Matrix video chat is being implemented as of now
> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms
Also wrong: Element has a native Android and a native iOS clie t
I feel like they are just throwing out lots of old information they read without checking if its still true, since its up to room version 9 now :P and like you said they are working on native video calls in matrix
Within Element, new features are developed in cross-functional teams and released in tandem; e.g. Spaces was released on web and mobile at the same time.
On performance - there are definitely some performance issues with matrix clients in general, particularly larger rooms and accounts which are in many rooms. This is an active focus of development, e.g. see work on sync v3, a more efficient matrix sync protocol https://github.com/matrix-org/sync-v3
The Jitsi thing is going away, matrix already has its own video chat for 1:1 chats, and it's coming for rooms soon too. The Jitsi option was a temporary setup.
The clean rooms approach is a good thing I think. Xmpp is becoming a pileup of different add-ons and suffers from the same issues you mention for matrix (not all features supported by all clients). Probably in a worse way.
I know the reluctance of IRC operators to allow (global) matrix bridges is often a case of different paradigms. On IRC a conversation can only be seen by users who are present at the time. A user joining a bridged matrix room can see the entire history from before they joined. This changes the privacy model a lot (insofar as IRC has any semblance of privacy, but whatever is there is regarded as very important). People running their own Heisenbridge puppeting bridges solves this issue though.
I'm not a matrix dev but I do like it, especially the phenomenon of bridges.
> A user joining a bridged matrix room can see the entire history from before they joined.
This is not the case, Matrix rooms can be set to allow viewing history only from joining time on. And that is how IRC bridge rooms are mostly configured, indeed based on policies from the bridged IRC networks.
Ah ok I remember this was a problem that was mentioned by the hackint network when people wanted to add a bridge there. We moved our community to OFTC as a result.
Perhaps this was only introduced later? I'm talking about 3 years ago. But good to see this was fixed.
> pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix clients are all incompatible with one another (because only Element implements them all) and once they have been upgraded rooms cannot be downgraded so in many places only Element can chat
This is false. Clients don't do state res, servers do. Clients don't care.
Meanwhile on the serverside, there have only been two versions of state resolution; the original beta version that turned out to be buggy, and the current fixed one which has been heavily scrutinized and is okay: https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i....
The amount of incorrect info in the GP post is very unfortunate - although I too wish that open standard comms protocols spent more time collaborating than spitting at each other.
Yeah, I didn't want to say anything because I'm no expert, but as far as I can tell, Matrix clients use a Rest API. It's not like they are resolving state deltas locally or something. It seems like the big complexity right now is the encryption, since that, by definition, has to happen on the client. There's a concerted effort, however, to make that as easy as possible with shared libraries and such.
A lot has happened in and around Matrix since. While this looks like an honest and thorough review, as it’s focusing on defaults and UX/expectations, I’m assuming several things to be outdated. Maybe some of the critique brought up here has even resulted in changes in docs, Element and Synapse already.
Haven’t yet read thoroughly enough to say what, will probably follow up here later.
Note that mxisd (the “only other identity server” referenced), from the paper authors, is now deprecated and part of their “Grid Server”. A community-maintained fork lives on as ma1sd. AFAIK this is the one identity server software to consider for self-hosters.
Also for those new to Matrix, “Riot” referenced is now rebranded as “Element Messenger”.
Unfortunately Signal is a walled garden actively fighting against alternative clients and servers. This is enough for me to avoid it and recommend Matrix. If you feel that those issues are critical, please donate your money or time to solve them.
This isn't responsive to the previous comment. Either the messenger meets or exceeds the privacy and security of Signal or it doesn't. If it doesn't, that's material regardless of what you believe about the aesthetics of Signal or their communitarian spirit. Most people who use secure messengers are LARPing (often in a good-willed performative way, as a way of supporting the privacy of others who truly need it).
But some people aren't LARPing, truly need privacy, and compromising their safety to make a point about federation is immoral.
Security is not everything there is to want from a messenger. Due to its centralized approach, Signal is having a problem with financing and I doubt it can be easily solved. It had a large downtime recently. Also, it becomes an easy target for all kinds of bad actors, since it's the single server. I trust it less for those reasons, even if it's "secure" by your standards. I just don't see it being secure long-term, not enough to suggest it to my friends or use myself.
People who truly need privacy in the short term, should consult a professional and not trust random comments from strangers.
I agree that security isn't everything there is to want from a messenger. But when the question being asked is "which messengers are secure", it is the only question that matters.
None of what you've said to support that argument sounded persuasive to me. I think it's a pretty transparent rhetorical sleight of hand to say "the only way things can actually be secure in the long run is for them to be federated the way I want them to be". I get it, you want to run federated systems that you can build your own clients for. The evidence for those kinds of systems being the most private runs strongly in the opposite direction.
Would you like an example that's especially relevant to this thread? Because I can provide you with one.
> "the only way things can actually be secure in the long run is for them to be federated the way I want them to be"
I never mentioned any particular kind of federation that I prefer. I also never mentioned word "private", which is mostly tangential to federation.
My point is that, in the long run, only federated systems are sustainable, because nobody is able to fund huge servers with millions of users without infinite money. For example, Signal and Telegram are both struggling with that currently; the latter introduced advertisement recently. On the other hand, Mastodon does not seem to have such problem (you could argue that it's too early though).
I do not want to build my own clients, I'm not even a programmer. I want a sustainable network, which could be achieved by a large number of self-hosted instances federated with (possibly) large servers. It has been working fine with email for decades. Also, the competition of various independent clients improves the user experience (like any other healthy competition elsewhere).
Yeah. How'd that work out for Matrix? Here's a hint: find out when the project was started, and when the network first required end-to-end encryption. Warning: the answer to that entirely vindicates Signal's position on federation; you may not like it.
That doesn't make Matrix bad. It makes Matrix different. Matrix has different goals than Signal, and those goals simply prioritize security and privacy differently than Signal does.
I'll bite: we first created Matrix in 2014; we started implementing E2EE in 2016 and we turned it on by default in 2020. The reason it took so long was because we focused first on getting decentralisation (not federation) correct, and then the protocol started to get prematurely successful and we got sucked into ensuring the implementations (and spec) scaled and the governance was correct... even before E2EE was stable enough to be on by default.
You're completely right that we have different goals to Signal (openness + freedom rather than privacy-at-all-costs), but I'm not sure that blaming federation is the right answer here. We just prioritised building an open standard over having E2EE from day 1, instead choosing to design things so we could add it later.
As I recall, you had false starts getting E2E enabled by default (6 years after the project started)... because popular client software didn't have it working. That's not a problem Signal has or ever will have: when they want to roll out new privacy features (like they just did days ago!), they roll the clients.
Again: I'm not dunking on Matrix. There are things the Matrix approach will do better than Signal can. But protecting individuals is probably never going to be one of them; you're competing with a project that has security and privacy as its overriding goal, and nobody at Signal ever has to ask whether federation --- a protocol complexifier if ever there was one --- merits a security hit.
I don't use Signal for everything (or even most things). I'm completely open to the argument that other messengers are better "overall" than Signal. But on a thread that asks the question of whether Matrix is as secure as Signal (not "secure enough", but rather "at parity with"), there is simply a clear answer.
I don’t think we had any false starts on e2ee by default? We wrote pantalaimon as a local shim to let any unencrypted matrix client do e2ee, and then (eventually) flipped the switch. The thing that stopped us doing so earlier is that we wanted to have optional online keybackup and cross signing and better key verification UX before we forced everyone into it.
> nobody is able to fund huge servers with millions of users without infinite money. For example, Signal and Telegram are both struggling with that currently
I'm willing to believe that this is true for Telegram, since they do pretty much everything on the server. With Signal, though, message databases and most business logic are client-side, so the servers are surprisingly dumb and lean. Signal spends way more on salaries and wages than on its servers. In 2019, Signal paid more to Twilio for SMS verification than it did to AWS for hosting: https://projects.propublica.org/nonprofits/organizations/824...
The problem is that such security is unstable due to unstable funding and the single target. You never know when it stops being secure (without a warning) or even available.
I am mostly talking about a use case, where you try to switch all your friends and relatives to a new IM system. If you have to ask them to switch again in a couple of years, you will loose their trust quickly.
You keep alluding to the "instability" of Signal's security, but your argument for that is a non sequitur. Repeating it doesn't make it more compelling.
And Signal forces you to use your phone number as your identifier, which can be traced relatively easily to a person or at least a geographical position by the authorities.
The content of the message might be encrypted, but metadata can provide valuable intelligence insights.
At least Matrix can be used mostly anonymously through a user-generated identifier, without an email address or phone number, and can be used through Tor.
> And Signal forces you to use your phone number as your identifier
Signal forces you to use "a" phone number as your identifier. It does not have to be your primary phone number, or home phone number or office phone number. Just a phone number that you have control of.
I was speaking about the prepaid cellular phones. Again, in most parts of the world, you cannot get an anonymous sim-card. AFAIK you also cannot create a Google account without a phone number.
Everyone loves to say depends on your threat model so lets define "tied to your real identity".
1. the number everyone you have met since you were 12 has in their contacts.
2. the number a few people have but you also use for you facebook account.
3. the number nobody / no tech has but you have provided your legal id to the network provider.
4. the number nobody / no tech has and you gave the network provider a burner email for.
5. the number nobody / no tech has that you paid for in cash while wearing a wig and glasses half way across town. You put into a new, paid for in cash phone, activated and used briefly while carrying no other electronic devices while disguised and avoiding cctv.
6. the inbound phone number in the lobby of the ritz carlton.
Some of those are better than using 'firstname.lastname' as you identifier. 1&2 are definately public numbers 4&5&6 are not.
#3 in the real world is semi-anonymous - for those with real privacy needs, they should be taking many other precautions and shouldnt be carrying a tracking device or using a single phone number or service irrespective of it being in their name or someone elses or nobody at all. For privacy LARPERS of course it is not at all anonymous.
> Signal doesn't store anything about you aside the date you joined and the time of your last ping.
Last I checked, Signal uses AWS, Azure and GCP. All of those services are completely logged and although "Signal" may not be storing metadata, intelligence services on those networks definitely are.
Data is sent over a network, and has an origin and destination. Of course Signal wouldn't store things like that, but the network administrator wouldn't have much trouble collecting extra metadata such as that on top of what is stored.
I recently changed my mind on this: being able to use phone numbers as identifiers also has some benefits: Last time I was on vacation, it was easy to get in touch with service providers (e.g. surf school, massage place) via WhatsApp, simply because I had their number, and everyone used WhatsApp anyways. If Signal would be more popular, I could instead contact them directly via Signal, since I only need their phone number. It allows for a more seamless transition.
Matrix OTOH would have a harder time getting adopted: businesses would need to update their websites, facebook pages and flyers to add the matrix contact info. Which they wouldn't do until Matrix is more popular. Which is a chicken and egg problem.
Matrix still has 3pids, including phone number and email.
The most common client, Element, will by default ask you for your phone number when registering with the default matrix.org homeserver and the default vector.im identity server will associate your phone number with your matrix user.
So by default (changing servers and/or opting out is easy and encouraged BTW), Matrix already works like you would prefer.
This is BTW a main critique in the OP since it makes vector.im a PII and metadata aggregator.
In terms of closed centralized services, I’d say Telegram is my top pick, followed by Signal. But I would take open source decentralized networks over them anyday, and my favorite is Freenet, or the much newer network, MaidSAFE because it is the most secure thing I have ever seen (but that’s not mainstream yet).
I don’t need it encrypted BY DEFAULT. If I want to encrypt something, I can. It also means the chats aren’t available on other devices and you lose other capabilities
I actually trust it more to not have backdoors. Signal is written by the same guys who sold to Facebook, and although both Moxie and Pavel are anarchists, I trust the guys who were actually ousted from their own country and yes, rolled their own encryption (with bounties to break it) rather than use an officially approved one
Besides - Moxie is kind of against decentralization, he thinks that by centralizing trust in a certain entity, things can be better. I am not convinced that such an approach leads to a better model for me to have encrypted communications:
I like that Signal started using SGX though. It’s not ideal (now I have to trust Intel instead) but at least if you’re going to be running some code on a centralized service instead of byzantine consensus, let me know you aren’t backdooring it:
In short? When you look at a room, your client sends a (public) read receipt. So stalkers get near-realtime data on your activity and the simple act of viewing different rooms (and maybe even just focusing the window) to see what's up causes data to be sent to the server. Ugh.
IMHO, aspects like metadata and application security are often much more important than the cryptographic protocol when assessing the security of a system like a messenger. People e.g. love to celebrate the Signal protocol because of its double-ratchet key rotation scheme, which is of course great and provides a little bit of additional security, but the other technical and organizational aspects of the system are just as important to assure privacy and security.
From that angle I like systems like Matrix way more than centralized solutions like Signal, Threema etc., because the whole security and privacy guarantees of the latter can be completely nullified by a single software update. If users don't have full control over the software running on the endpoint then end to end encryption is little more than a marketing gag, IMHO.
Unless something has changed in the past years, Signal and Matrix have this in common that any room you join displays your identifier for every one to see (phone number / MXID) publicly, leading to problems of harassment/spam.
But i entirely agree with your point that relying on a single actor for updates/security is really the worst.
I'd say that revealing a phone number is probably worse than a matrix ID. But indeed, it would be nice if miatrix clients from element would support multiple identities.
Then you can join a room with a disposable account.
An project that looks interesting to me is Cwtch, precisely for its focus on metadata leak-resistance. It seems to be more of a research-focussed project right now, but I think looking in exactly the right direction.
so many people read these things and forget to check when it was written, its honestly infuriating since so much could easily change related to the article
Seems pretty private to me. I run a Matrix server (synapse) and have a handful of friends in a private encrypted room. Regularly, people become unable to read each others messages, for no obvious reason. Some cryptic message about not having each others keys or whatever. Doesn't get much more private than that.
I've only had this issue when its between 2 people on the same HS, but I've never had it happen when I'm talking to someone on another HS its weird as hell
It's all tradeoffs. You can't have perfect security, _and_ store historical messages on the server, for example. But I use Matrix because I don't want ephemeral messaging. Matrix found a way to get 99% of the security of Signal while giving me the features I need, and that's why I use it.
Plus, I self host, which, in my opinion, more than makes up for anything else. Hell, I'd take storing my own plain text over E2E on someone else's server even.
I recommend a secure home server, People home servers something are not reliable or secure. Got to find a home server to use and sign up to. I would recommend using kde.org, As it is 100% reliable and secure. Others may very.
Use as much open source applications as possible, And if you want to. Do not force anyone to use them, Just be smart in providing your information.
I use:
Matrix - It's end to end encrypted but some groups i am in, The owners have it disabled for some reason.
Keybase - Keybase was sold, But still end to end encrypted. Plus i was using it before they got sold so.
Telegram - Telegram is not end to end encrypted by default, Unless you enable secret chats.
That doesn't work if you are never (or not often) online at the same time as the other.
I use signal to chat with my cousin who is in another continent, and he is online only when within reach of public wifi when he's outside, which is at night for me. My phone is always connected to 4G, so maybe what you propose could work in this specific case, but in other cases it could be an issue.
Sure, you could. How many people do? I don't. I could. But that doesn't solve my problem with Tox.
I use IM apps to keep in touch with people in my social circle. I've been coercing a lot of my close friends to switch to Matrix (I use the word "element" because they're not tech savy and I don't want them to be too off-put), and some of them actually do.
If Tox does not have an app on iOS store, that, as of now, makes it impossible for me to suggest it to approx. 60% of my friends, folks I exchange instant messages with, on a daily basis. Due to this, I'm sure you could see why this limitation makes this platform/service absolutely useless for me.
> If Tox does not have an app on iOS store, that, as of now, makes it impossible for me to suggest it to approx. 60% of my friends
If iOS does not allow 3rd party programs on "their" phones (or GPL'ed software on their "store"), that, as of now, makes it impossible for me to suggest it to 100% of my friends. It's easy to shift the blame on volunteer developers when you have a multi-billion corporation making their lives miserable (see also the background notification issue on iOS).
Also, mostly rich people use iPhones. The rest of us use cheap Android devices or dumb phones... iPhones are non-existent in my social circles, except for the odd second-hand-with-broken-screen iPhone someone got for free.
> iOS does not allow 3rd party programs [ ... ] or GPL'ed software ...
I one hundred percent agree that not allowing GPL software on the store is problematic. I am still torn on whether not allowing 3rd party programs on their store is problematic or not. As a person on HN, of course I would LOVE if they did allow third party stores/downloading application distributables and executing them.
But considering the innovative nature of malware/spyware and the tech-illiteracy of my mother, I can't help but feel if she isn't better off on a platform where applications go through _some_ form of human verification, and a random pop up on some random website would not end in her details being leaked/accounts being hacked/phone being bricked?
> iPhones are non-existent in my social circles
That's a fair point. Developing one less app would make the turn around time for the rest of the stuff faster for the supported platforms. At some point of time though, the folks behind Tox would need to min-max this out for optimal availability and usability.
from a certain pragmatic sense, I agree with you. a messenger app that wants wide adoption needs to have clients for the devices the userbase uses. adding device switching costs on top of app switching costs is not something i'm after.
granted my goal is simply to have just a bit more privacy than the plaintext bulk scanning that messenger does, so i use centralized signal rather than something 'purer' like running my own matrix. (though i do run my own zulip)
matrix p2p at general availability will be my next move after signal once signal has its next big outage
On the one hand, of course I love that people have the means to audit assumptions.
Both the ability to do so w.r.t the project being transparent and open, but also through time and technical ability.
I am, however, a little upset when people poke at minor issues (that they themselves see as minor) and speak at length about them. *not* because those issues should not be addressed, but because it gives ammunition for people who recommend closed platforms, or more opportunity for people to think of the community as being more divided than it really is.
The more uncertainty a thing is surrounded by: the more people are likely to just say "fuck it" and choose any option as long as it works, and guess what works? Closed platforms, especially those with coherent messaging like facebook or whatsapp.
So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project.