As someone who doesn’t really care for E2EE (in the context of what I’d be interested in Matrix for, large group chats, where it seems kinda pointless), Matrix still isn’t fit for purpose. The performance, user experience, client/server ecosystem quality is still unacceptable.
(I still don’t like Signal either, but at least the E2EE works there for one-on-one conversations.)
The performance, user experience, client/server ecosystem quality is still unacceptable.
I see people say things like this online, but this doesn’t match my experience at all. I spend a substantial amount of time on Matrix (it is where the official Neovim support chat is, along with our developer & off-topic chats) as well as Discord and IRC. I use ElementX on iOS and both Element Web and Cinny on desktop.
I wouldn’t say that Matrix is the best, but in my experience it’s far from “unacceptable”. These days it mostly just works. The only thing that comes to mind in terms of bad user experience was the recent performance degradation issues on matrix.org. That certainly was bad, and if that happened frequently my opinion on Matrix would sour, but that’s the only time that has happened in my memory.
Matrix regularly fails at reliable message delivery (or notifying of delivery issues). Just this week, I a coworker asked me why I was replying to a message he didn’t get. Both he and the message’s author are on matrix.org.
but that’s the only time that has happened in my memory
I like Matrix and use it every day. But it definitely has flaws.
element-web often fails to load messages by link. Just hanging forever or alerting that it can’t find the message.
element-android often fails to refresh keys at the right time leading me to send messages that fail to be decrypted. (This is most notable when talking to my mautrix-meta bridge which aggressively rotates keys.) element-web and the new Element X for Android seem to not have this problem.
Lots of data is not encrypted. Even some new protocols seem to be keen to offer unencrypted options (for example sticker packs). A “proper” E2EE solution would encrypt anything all of the time, now have optional encryption for each protocol (where often the encryption half of that optional isn’t even speced out yet).
Half of the time I can’t pick up calls. And then calling back seems to be broken for a while until the state settles down.
I have to say it is currently the best option available. But I would much rather see it focus on being a polished, secure and reliable product rather than continuing to gain a half-assed implementation of every feature.
Soatok is one of my favorite applied cryptography bloggers, and his blog posts are always a joy to read. I frequently learn a lot from his blog and feel good about reading it due to his humor and sharp writing.
That being said, I should respectfully point out that in this instance, the tone doesn’t match the findings. While the findings are legitimate, they are more or less known, and I can share that they’ve been spotted earlier by other auditors but deemed to be of no serious practical impact.
I see no serious immediate concern arising from these issues. At most, they are “would be nice to fix”es down the line.
I think we need to be able to criticize cryptography engineering without feeling like we need to end every single post with something along the lines of “This is fucking clownshoes.” regardless of the actual real-world criticality of the findings.
Martin R. Albrecht, Sofía Celi, Benjamin Dowling and Daniel Jones’s work on practical exploits in Matrix, from last year, is what can actually be cited if you want to talk about serious vulnerabilities in Matrix: https://eprint.iacr.org/2023/485
This is common with Soatok in my experience. They love to talk about hypothetical attacks that don’t apply to the way anyone practically uses a system, and then use that to build a big fear mongering about the system itself.
I think that’s kind of the curse of popularity. Soatok has written great articles in the past, and he probably pressures himself to keep up this performance.
Don’t they pretty much say in recent articles that they feel compelled to keep commenting on such crypto issues by external queries y but really don’t want to? I’d not come across them until recently but what I’ve read gives off an “I’ve had enough of this shit, but if you insist on knowing what I think…” vibe, genuine annoyance. Seems to wrong to criticise the tone when those disclaimers are pretty much explicit..
I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?
If we’re going to insist that everyone should be using Element if they want to be secure, that defeats the entire marketing point about third-party clients that Matrix evangelists cite when they decry Signal’s centralization.
So I really don’t want to hear it.
I don’t see anyone insisting that users have to use Element in order to be secure. Every Matrix client here can switch to a non-libolm cryptography library just as Element itself has, in response to this public disclosure of a vulnerability with libolm. Indeed it looks like both Cinny and FluffyChat have open github issues about moving away from libolm in response to this blog post or the earlier deprecation notice on libolm.
If the problem is that they can’t all be compelled to do so automatically by the same organization that maintains the protocol, then this is in general an indictment of any 3rd party client for a protocol that uses encryption. Maybe a cryptographer would argue that centralization of clients is necessary in order for end users of a protocol to be (relatively) assured that when they use the protocol, they’re using software that has had any cryptography-related vulnerabilities patched. But this requires accepting the downside of centralization that the one entity maintaining the one client can add code that does things the end user doesn’t want.
Every Matrix client here can switch to a non-libolm cryptography library just as Element itself has
From some of the issues linked in the Mastodon thread, it appears that this is not easy. The new library is written in Rust, the old one is C. There was a compatibility wrapper that let you use the new one but it’s unmaintained and now broken. A few clients were using it and have now reverted.
Maybe a cryptographer would argue that centralization of clients is necessary in order for end users of a protocol to be (relatively) assured that when they use the protocol, they’re using software that has had any cryptography-related vulnerabilities patched.
I think this is almost exactly the point Moxie (creator of, and former Signal CEO) had in favour of centralisation. However I don’t recall if he acknowledged any of the downsides to it.
As someone who doesn’t really care for E2EE (in the context of what I’d be interested in Matrix for, large group chats, where it seems kinda pointless), Matrix still isn’t fit for purpose. The performance, user experience, client/server ecosystem quality is still unacceptable.
(I still don’t like Signal either, but at least the E2EE works there for one-on-one conversations.)
I see people say things like this online, but this doesn’t match my experience at all. I spend a substantial amount of time on Matrix (it is where the official Neovim support chat is, along with our developer & off-topic chats) as well as Discord and IRC. I use ElementX on iOS and both Element Web and Cinny on desktop.
I wouldn’t say that Matrix is the best, but in my experience it’s far from “unacceptable”. These days it mostly just works. The only thing that comes to mind in terms of bad user experience was the recent performance degradation issues on matrix.org. That certainly was bad, and if that happened frequently my opinion on Matrix would sour, but that’s the only time that has happened in my memory.
Matrix regularly fails at reliable message delivery (or notifying of delivery issues). Just this week, I a coworker asked me why I was replying to a message he didn’t get. Both he and the message’s author are on matrix.org.
Previous one was in April, matrix.org was down for a workday: https://mastodon.matrix.org/@matrix/112314086128920640
I like Matrix and use it every day. But it definitely has flaws.
I have to say it is currently the best option available. But I would much rather see it focus on being a polished, secure and reliable product rather than continuing to gain a half-assed implementation of every feature.
Reactions are always sent unencrypted, this one really surprised me when I accidentally found it out.
Soatok is one of my favorite applied cryptography bloggers, and his blog posts are always a joy to read. I frequently learn a lot from his blog and feel good about reading it due to his humor and sharp writing.
That being said, I should respectfully point out that in this instance, the tone doesn’t match the findings. While the findings are legitimate, they are more or less known, and I can share that they’ve been spotted earlier by other auditors but deemed to be of no serious practical impact.
I see no serious immediate concern arising from these issues. At most, they are “would be nice to fix”es down the line.
I think we need to be able to criticize cryptography engineering without feeling like we need to end every single post with something along the lines of “This is fucking clownshoes.” regardless of the actual real-world criticality of the findings.
Martin R. Albrecht, Sofía Celi, Benjamin Dowling and Daniel Jones’s work on practical exploits in Matrix, from last year, is what can actually be cited if you want to talk about serious vulnerabilities in Matrix: https://eprint.iacr.org/2023/485
This is common with Soatok in my experience. They love to talk about hypothetical attacks that don’t apply to the way anyone practically uses a system, and then use that to build a big fear mongering about the system itself.
I think that’s kind of the curse of popularity. Soatok has written great articles in the past, and he probably pressures himself to keep up this performance.
Don’t they pretty much say in recent articles that they feel compelled to keep commenting on such crypto issues by external queries y but really don’t want to? I’d not come across them until recently but what I’ve read gives off an “I’ve had enough of this shit, but if you insist on knowing what I think…” vibe, genuine annoyance. Seems to wrong to criticise the tone when those disclaimers are pretty much explicit..
I don’t see anyone insisting that users have to use Element in order to be secure. Every Matrix client here can switch to a non-libolm cryptography library just as Element itself has, in response to this public disclosure of a vulnerability with libolm. Indeed it looks like both Cinny and FluffyChat have open github issues about moving away from libolm in response to this blog post or the earlier deprecation notice on libolm.
If the problem is that they can’t all be compelled to do so automatically by the same organization that maintains the protocol, then this is in general an indictment of any 3rd party client for a protocol that uses encryption. Maybe a cryptographer would argue that centralization of clients is necessary in order for end users of a protocol to be (relatively) assured that when they use the protocol, they’re using software that has had any cryptography-related vulnerabilities patched. But this requires accepting the downside of centralization that the one entity maintaining the one client can add code that does things the end user doesn’t want.
From some of the issues linked in the Mastodon thread, it appears that this is not easy. The new library is written in Rust, the old one is C. There was a compatibility wrapper that let you use the new one but it’s unmaintained and now broken. A few clients were using it and have now reverted.
I think this is almost exactly the point Moxie (creator of, and former Signal CEO) had in favour of centralisation. However I don’t recall if he acknowledged any of the downsides to it.