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.
> 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.
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.
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.
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).
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.
Readit News
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.
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.
And you're mentioning it's outdated, which would be natural given that the last commit was over two years ago.
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.
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.
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”.
But some people aren't LARPing, truly need privacy, and compromising their safety to make a point about federation is immoral.
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.
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.
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.
But i entirely agree with your point that relying on a single actor for updates/security is really the worst.
Then you can join a room with a disposable account.
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.