# Remove Matrix/Element mentions from Real-Time Communication **URL:** https://discuss.privacyguides.net/t/remove-matrix-element-mentions-from-real-time-communication/20068 **Category:** Tool Suggestions **Tags:** rejected **Created:** 2024-08-15T03:30:53Z **Posts:** 39 ## Post 1 by @get2thepoint — 2024-08-15T03:30:54Z ### Why should this tool be removed? User Soatok published a [blog post](https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library) that detailed security issues with Matrix’s OLM library. In response, a lead dev complained about the criticism on HackerNews and ended up admitting that they didn’t fix known side-channel vulnerabilities for _years_. (See [addendum-2024-08-14](https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/#addendum-2024-08-14) in the blog post). Not only is Matrix just a dogshit and confusing experience in general, it’s evident it has issues with security as well as problematic development. It’s not acceptable for a team working with message encryption and communication to just disregard vulnerabilities like this. If PrivacyGuides cares about only recommending the most trustworthy software, they should seriously consider removing Element and Matrix recommendations and mentions from their website. --- ## Post 2 by @anon66226834 — 2024-08-15T04:47:27Z They should remove Session too. --- ## Post 3 by @Niek-de-Wilde — 2024-08-15T06:12:03Z While this does seem bad, I would rather contact matrix to hear their side of the story before picking up the pitchforks and torches. Ill try to make some time for this today. --- ## Post 4 by @anon48875053 — 2024-08-15T06:18:47Z Matrix should have never been on the same page as Signal, SimpleX, etc. It’s good for hosting communities, but it shouldn’t be recommended for 1:1 communications. --- ## Post 5 by @anon46412288 — 2024-08-15T06:30:38Z > [@get2thepoint](#): > > In response, a lead dev complained about the criticism on HackerNews and ended up admitting that they didn’t fix known side-channel vulnerabilities for _years_. (See [addendum-2024-08-14](https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/#addendum-2024-08-14) in the blog post). > > > At present, libolm uses Brad Conte's portable implementations [[1]] of SHA-256 a…nd AES-256. These have the advantage of being plain C and therefore work out-of-the-box under emscripten; however they are not side-channel resistant. > > I'm not aware of any portable implementations of AES which are resistant to side-channel attacks - indeed it is very difficult to create a constant-time implementation without access to machine-level detail. The correct fix to this is therefore to use different implementations in different environments - for example, we could link against openssl for a C library, and use webcrypto in the browser. > > It's also likely that doing so would bring performance improvements. > > The main difficulty is that it significantly changes data flows: for example, webcrypto provides an asynchronous interface, which means that the whole olm interface would need to be altered to be asynchronous, at least under emscripten. > > [1]: https://github.com/B-Con/crypto-algorithms this is from the linked github issue. > Update: the modern solution to this is just to use [GitHub - matrix-org/vodozemac: An implementation of Olm and Megolm in pure Rust.](https://github.com/matrix-org/vodozemac), which uses better implementations. --- ## Post 6 by @jerm — 2024-08-15T08:15:14Z > User Soatok published a [blog post](https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library) that detailed security issues with Matrix’s OLM library. It is deprecated, almost no popular clients uses it, you can see how the author linked affected Matrix clients which are all random forks that no ones uses. This author really likes to pick up on small issues and make a big deal out of it. --- ## Post 8 by @Niek-de-Wilde — 2024-08-15T09:30:21Z Its deprecated now, but what matters is that how long they knew about these side channels before moving on. --- ## Post 9 by @anon49578468 — 2024-08-15T09:37:33Z > > if you actually look at % of impacted clients, it’s tiny. > it’s pretty much any client that has E2EE and is not Element. in my earlier quick look at Alpine Linux repos this included: Fluffychat, Nheko, gomuks, NeoChat, Chatty, weechat-matrix. then i already know that still didn’t catch at least Cinny, which also is in Alpine, but includes libolm as wasm. > it’s literally all “Featured clients” listed on [Matrix.org](http://Matrix.org) except Element and Element X. > i’ll put it another way. if anything other than New Vector is “tiny” and doesn’t matter, is Matrix a “rich ecosystem”? Quoted directly from the HN discussion. I don’t think this is a small issue. Decentralized protocols should: 1. Have secure defaults and not push insecure implementations 2. Have a method to enforce all clients to use the most secure default and not depend on the goodwill of the author of the client. Currently, for this issue, it seems Matrix did neither. Also I dont think blaming the original article author is good faith unless you can point out the technical flaws in their arguments. --- ## Post 10 by @Tech-Trooper — 2024-08-15T10:05:57Z I second this. Matrix can be moved into a new page about community building and communication. Besides, I also believe Session does not deserve to be in this page. It has no superiority over Simplex. --- ## Post 11 by @Kratacoa — 2024-08-15T16:36:23Z Can someone explain how bad this kind of omission is? From the standpoint of a noob, I gathered that side channel attacks are bad enough to potentially cause the extraction of a secret key. However, it is unclear to me how feasible it is with the given algorithm being used and in the context of the Matrix protocol. --- ## Post 12 by @get2thepoint — 2024-08-15T17:31:15Z not put on a new page, but removed entirely. --- ## Post 13 by @get2thepoint — 2024-08-15T17:36:36Z Multiple years. they said it themselves. also, element isnt entitled to a spot or recommendation. even if this is just some misunderstanding, it is still the safer move to remove it until further notice until its cleared up. also this is to jerm (i dont want to make yet another comment): the fact that element is the only client really worked on and that people use, and yet its still awful, should only reinforce the need to remove it. it sucks to use, and its not worth recommending to anyone. --- ## Post 14 by @Rasta — 2024-08-15T19:58:35Z > [@get2thepoint](#): > > the fact that element is the only client really worked on and that people use, and yet its still awful, should only reinforce the need to remove it. it sucks to use, and its not worth recommending to anyone. I’d rather get my friends off of Discord and into Matrix for gaming, communities, and voip calls. Like @anon48875053 and @Tech-Trooper said, it’s good for communities. Realistically its the closest thing to discord that we have, which can help make transition away from discord easier. --- ## Post 15 by @exaCORE — 2024-08-15T20:05:31Z > [@anon49578468](#): > > it’s pretty much any client that has E2EE and is not Element. in my earlier quick look at Alpine Linux repos this included: Fluffychat, Nheko, Doesn’t Nheko use it’s own encryption implementation? --- ## Post 16 by @deadorbit — 2024-08-15T20:19:48Z It seems to me, based on the blog post, that the issues are in Matrix clients, not the server. Did I read that correctly? --- ## Post 17 by @exaCORE — 2024-08-15T20:23:31Z Yes, but only those that use the outdated libOlm library. --- ## Post 18 by @anon49578468 — 2024-08-16T08:18:00Z I don’t use nheko. Is it this one: [Link](https://github.com/Nheko-Reborn/nheko/issues/1786). If yes, it seems they also used libolm. --- ## Post 19 by @Tech-Trooper — 2024-08-16T17:19:25Z What do you propose for a discord/community alternative instead of Matrix/Element? --- ## Post 20 by @ph00lt0 — 2024-08-16T21:54:48Z While i agree with you and @Tech-Trooper this is already the case: > we do not recommend them for long-term or sensitive communications > **[The Best Private Instant Messengers - Privacy Guides](https://www.privacyguides.org/en/real-time-communication/#additional-options)** > > Encrypted messengers like Signal and SimpleX keep your sensitive communications secure from prying eyes. --- ## Post 21 by @fria — 2024-08-16T21:56:29Z Don’t really need one tbh. If you wanna use discord use discord. Main purpose is for public chats. --- ## Post 22 by @dngray — 2024-08-17T10:17:36Z We won’t be removing Element, as we mention Element specifically which uses vodozemac. The author claims that is not effected. We don’t recommend every other matrix client which hasn’t had an audit, and we don’t believe that [Matrix.org](http://Matrix.org) should be responsible for making sure unmaintained/hobby clients use the latest library (how could they anyway, the whole thing with decentralization). Those projects are not a part of [Matrix.org](http://Matrix.org) and are not covered by _their_ audits. --- ## Post 23 by @anonymous544 — 2026-02-19T12:48:30Z > [@dngray](#): > > We won’t be removing Element, as we mention Element specifically which uses vodozemac. Should this post be revived? A new article by @soatok talks about cryptographic issues in Vodozemac. I can’t understand the article since I’m not a cryptographer so I will put it in this thread for relevance. > **[Cryptographic Issues in Vodozemac - Cryptographic Issues in Matrix’s Rust...](https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/#cryptographic-issues)** > > Two years ago, I glanced at Matrix’s Olm library and immediately found several side-channel vulnerabilities. After dragging their feet for 90 days, they ended up not bothering to fix any of it. | Two years ago, I glanced at Matrix’s Olm library and... --- ## Post 24 by @KathyM — 2026-02-19T13:17:54Z Seconding the removal. I don’t understand computer code but that article has enough “technical trash talk” that I am scared of any _encryption_ matrix devs submit. Unrelated, the few encrypted rooms I visited were public which defeats the point of encryption. --- ## Post 25 by @TinFoilHat — 2026-02-19T13:18:47Z Although it is very tempting just to say “fxxk yes“, I think PG team, if decided to follow up on this “new“ issue, could reach out matrix for their response, and see if Matrix’s response/ remedy plan is acceptable. Given a POC is already provided by @soatok, I think PG team should take it seriously. Also given how poorly the Matrix team is performing (i.e. not telling ) in informing users / hosts / potential users about the protocol that each known client is using ( see [Matrix.org - Clients](https://matrix.org/ecosystem/clients/) , its nothing there). I don’t think Matrix should get an easy pass like [last time](https://discuss.privacyguides.net/t/remove-matrix-element-mentions-from-real-time-communication/20068/22). If Matrix team is unable to remedy in timely manner, I think PG should de-list Matrix/ Element **with an announcement** as the service provides false sense of security to people, which could put users in higher threat model at risk. --- ## Post 26 by @soatok — 2026-02-19T17:30:17Z > [@TinFoilHat](#): > > I think PG team, if decided to follow up on this “new“ issue, could reach out matrix for their response, and see if Matrix’s response/ remedy plan is acceptable. Matrix did respond: > **[Analysis of reported issues in vodozemac](https://matrix.org/blog/2026/02/analysis-of-reported-issues-in-vodozemac/)** > > Matrix, the open protocol for secure decentralised communications However, their response is flawed and a bit misleading. I added an addendum to my blog post to explain more: [Cryptographic Issues in Matrix’s Rust Library Vodozemac - Dhole Moments](https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/#matrix-response) --- ## Post 27 by @Libre_Software_Enjoyer — 2026-02-19T17:37:24Z > [@anon48875053](#): > > It’s good for hosting communities, but it shouldn’t be recommended for 1:1 communications. Still a lot better then for example Discord considering privacy, security and software freedom. --- ## Post 28 by @phnx — 2026-02-19T17:55:38Z I want the Matrix / Element recommendation to be rescinded. The Matrix protocol is a fragile mess, lacks proper perfect forward secrecy, leaks stupid amounts of metadata, and is not meaningfully open. Relevant comments from the GrapheneOS Foundation: [https://xcancel.com/GrapheneOS/status/1879270157576782143#m](https://xcancel.com/GrapheneOS/status/1879270157576782143#m) [https://xcancel.com/GrapheneOS/status/1963101488898519414#m](https://xcancel.com/GrapheneOS/status/1963101488898519414#m) --- ## Post 29 by @Libre_Software_Enjoyer — 2026-02-19T18:22:31Z > [@phnx](#): > > lacks proper perfect forward secrecy, The have partial forwards secrecy, right? > [@phnx](#): > > and is not meaningfully open. How do you mean this? --- ## Post 30 by @TinFoilHat — 2026-02-19T18:44:55Z I read your blog post earlier today, so seems I am up-to-date, thats good. I would prefer PG to reach them again, so they could have another chance to think before responding. --- ## Post 31 by @TinFoilHat — 2026-02-20T07:40:10Z Sorry just to bug [@team](/groups/team) for reconsiderations. --- ## Post 32 by @lyricism — 2026-02-20T14:20:00Z Matrix is better thought of as a competitor to XMPP, not Discord, and a poor one at that. Everything Matrix does XMPP does better. --- ## Post 33 by @maqp — 2026-02-20T15:57:22Z What’s the state of of XMPP E2EE protocols? Last I checked was maybe 2014, and back then it was mostly opt-in OTRv3 with its already borderline outdated crypto between two devices at a time, with extremely poor (if any) cross-device support and no E2EE for groups. @soatok adviced against OMEMO two years ago and latest addenum is from then too [Against XMPP+OMEMO - Dhole Moments](https://soatok.blog/2024/08/04/against-xmppomemo/) So what’s the current state of XMPP E2EE in terms of usability and security? --- ## Post 34 by @lyricism — 2026-02-20T16:18:50Z To clarify, I’m not endorsing XMPP + OMEMO in general, I just think that it is better than Matrix at federated E2EE IM. All the problems XMPP + OMEMO has, Matrix also has and more. I was just commenting on the failures of Matrix to actually succeed as an XMPP killer. Perhaps a better word choice on my part would be “everything Matrix does XMPP does less bad”. I strongly encourage everyone to just use Signal. --- ## Post 35 by @Anvil — 2026-02-20T16:37:08Z > [@lyricism](#): > > I just think that it is better than Matrix at federated E2EE IM > [@phnx](#): > > lacks proper perfect forward secrecy, leaks stupid amounts of metadata I think it’s important to remember that Matrix/Element is recommended under the social networks category and not the real time communication category. Obviously a reasonable level of security and privacy is desired, but it doesn’t need to be at the level of Signal or something for private chats (although of course that would be nice). If we’re thinking of removing Matrix because it isn’t as secure as Signal, we should be applying the same standard to Mastodon which is under the same category as Matrix/Element. Personally, as a social network, I find Matrix/Element far more usable and less buggy than XMPP. It’s also far more widely used by FOSS projects. Edit: Actually, I just noticed the title of this post. Sounds like it was recommended under RTC initially but is no longer. If folks want it to also be removed from the social networks category, they should probably create a separate thread. --- ## Post 36 by @lyricism — 2026-02-20T16:44:58Z > [@Anvil](#): > > Actually, I just noticed the title of this post. Sounds like it was recommended under RTC initially but is no longer. If folks want it to also be removed from the social networks category, they should probably create a separate thread. This got me too but I think in reverse, I didn’t realize it’s currently recommended as a social network rather than RTC until you mentioned it. I’m still not a fan but I agree it’s a separate conversation entirely in that context. --- ## Post 37 by @overdrawn98901 — 2026-02-20T17:19:59Z I guess, why are they doubling down and not just saying good catch? Like checking against the identity is pretty much DH 101. David Wong quite literally says “check validity of public keys or expect bugs”. The fact Signal didn’t check them is also non ideal. But Matrix mentions this as a whattaboutism. What’s most grating in their reply is that they say it’s not an issue, note that Signal didn’t patch a similar bug until last week, and then AFTER defending not checking it, they decide to patch it (and not even fully ack the risk) > It’s worth saying that in our private correspondence with the reporter we agreed to add the check as a defence-in-depth and to remove any doubt of whether this constitutes a vulnerability. The check will be added in a future vodozemac release. If Signal decides to patch a similar vulnerability (which risk has not yet been assessed), then is Matrix still handwaving if it as though it has no risk at all? Defense in depth is not a debate, it’s required for secure applications. I.e., software engineers deploy redundancy for production systems - not because we expect to deploy bad systems, but it provides failover strategy if an unknown occurs. And after enough time, those unknown grow larger with more complexity. Either Signal patched a real vulnerability (risk not yet determined), and this no check in Matrix is definitely a vulnerability of at least some correlation; or Signal had no vulnerability and their patch was just pre-emptive and Matrix was right all along. Now I’m curious: was the lack of the DH identity check in Signal exploitable in the same way as Matrix is? > [@phnx](#): > > Relevant comments from the GrapheneOS Foundation: [https://xcancel.com/GrapheneOS/status/1879270157576782143#m](https://xcancel.com/GrapheneOS/status/1879270157576782143#m) > [https://xcancel.com/GrapheneOS/status/1963101488898519414#m](https://xcancel.com/GrapheneOS/status/1963101488898519414#m) I once tried self hosting matrix, and I also concur it was a bit of a PITA. I wanted to utilize bridges, but honestly ditched it in favor of a direct IRC hosted service when needed. For my limited time, I prefer to host simpler things. > [@Anvil](#): > > Personally, as a social network, I find Matrix/Element far more usable and less buggy than XMPP. It’s also far more widely used by FOSS projects. This is the one use case I don’t terribly mind Matrix. Assuming public discussion of FOSS, --- ## Post 38 by @maqp — 2026-02-20T20:40:31Z > [@overdrawn98901](#): > > Now I’m curious: was the lack of the DH identity check in Signal exploitable in the same way as Matrix is? [https://eprint.iacr.org/2019/1416.pdf#page=10](https://eprint.iacr.org/2019/1416.pdf#page=10) Section 2.5 paragraph 3 > When users in a Signal group send encrypted messages to the group, they encrypt > and send the message to each group member, individually, with end-to-end encryption There’s no group key exchange and Chuck offering zero-public key to each contact in group sets the shared key to 0 for them and the contact. Then, any contact who sends a group message will, due to the nature of group chats, send one copy of the message to Chuck, and that particular ciphertext will use key deterministically derived from the zero-shared key. So to me it looks like it’s different in principle, that Chuck can’t meddle with other group members’ message keys, but it’s as bad in that the server can nonetheless decrypt Chuck-related ciphertexts, with the zero-derived message key. --- ## Post 39 by @Libre_Software_Enjoyer — 2026-02-26T19:31:35Z > [@lyricism](#): > > Matrix is better thought of as a competitor to XMPP, not Discord, and a poor one at that. Everything Matrix does XMPP does better. For example? The only thing that really bothers me with Matrix is that the clients I tested have no eassy option to view the public key’s of your contacts/people-on-server’s