Comment by jckahn 4 days ago
Cool! I’ve recently consolidated all of my Google Chat and WhatsApp friends onto Matrix (via Element) because it’s E2EE. Gchat isn’t and I assume that Meta has a backdoor into WhatsApp conversations. So, those platforms can’t be trusted. Signal doesn’t have a web interface, so that’s a no-go for me. lol Telegram.
Matrix has been great for me and I recommend that everyone else use it!
You're absolutely right. End-to-end encryption protects message content, but WhatsApp still collects metadata, which is incredibly valuable.
Even though they can't read your messages, they know who you talk to, how often, when, and for how long. They also track your device info, IP address (which can reveal your location), network details, and app usage patterns.
And this data isn’t just sitting there—Meta uses it. For example, if you chat with a business on WhatsApp, you might start seeing ads for that business on Instagram or Facebook. They don’t need to read your messages when they can infer so much just from how you use the app.
Disclaimer: Comment translated from Spanish and corrected by Chat GPT.
> Even though they can't read your messages
I've long wondered if this is actually true.
If I have a closed-source app and claim (and can verify!) E2EE, surely I could still read every message from my closed-source app, within the app itself, and you'd never know.
I've never been a mobile app developer but I've been a desktop and web developer since the 90s so I don't know what apps can and cannot see but in a desktop app or web app, if it's on the screen, it's decrypted and I can put code in to read/steal it.
Am I missing something here?
At about 2:33:15 here, Zuckerberg somewhat alludes that Meta can take screenshots of WhatsApp messages.
It's true in a sense - using an iPhone or an Android phone Apple/Google could be streaming your screen contents constantly, so even e2ee wouldn't help.
I just don't know if that is actually true, or if meta doing e2ee and then pinging your messages around from the app after they're delivered is true. I've no reason to believe either is.
And the default/largest homeserver, matrix.org, uses cloudflare, so all your data belongs to them as well.
It is disappointing that they use Cloudflare, especially since most Matrix metadata hasn't yet been moved to the end-to-end encrypted channel.
(Arathorn: is e2ee metadata still on the roadmap?)
But no, not all your data is exposed. The e2ee parts, like message content in encrypted rooms, are opaque to Cloudflare.
yup, encrypted metadata is very much on the roadmap. https://github.com/matrix-org/matrix-spec-proposals/pull/425... is one of the more recent proposals for it.
It's wonderful that it seems work well for you but my experience in bridging group chats with XMPP or IRC was terrible. Lost messages, bridge crashes, puppet accounts getting randomly broken/duplicated with discarded messages.
From the bridges I've run, only the Telegram bridge is somewhat stable for me but it also has it's warts.
Might be different if you run a strictly personal server for 1:1 conversations but I'd say from an ux perspective the bridges idea largely failed IMHO.
I don't think it's the fault of element/matrix it's a difficult problem and I guess with limited resources they made a lot of progress and made things possible that weren't before but it's not plug and play, at least it wasn't for me.
In general I've found it's also difficult to communicate in group chats if there are two worlds with a slightly different view (missing reactions, some elements of the messenger are not supported like captions, polls and so on...)
Signal doesn't have a web interface, but being able to use a desktop app is OK for me.
The big downside for me is not being able to use it on two devices. All the other services, privacy concerns or not can now do this. It's one reason why I stopped donating to / advocating for signal.
Settings -> linked devices?
https://support.signal.org/hc/en-us/articles/360007320551-Li...
It's something I've just recently run into trying to set it up on an Android tablet. The funny thing is they allow it on an iPad. It'd be great if they allowed just any phone or tablet to link to the primary device. I'd complain but it's been deaf ears for the last 4 years to get them to put gifs back into the desktop app.
You mean you access all these on Matrix/Element via the bridge? Or you actually mean you convinced all of them to ditch their chat apps and migrate to Matrix, or at least install Element as well in addition to the other ones? It’s a feat if it’s the latter without or without ditching. Is this a very privacy conscious demographic?
I got my friends to install Element and use that to message me instead of Gchat/WhatsApp. They’re all quite tech savvy and have varying degrees of privacy consciousness.
I also got my partner to switch to it. She’s not a super nerd like me but she was able to figure it out easily enough.
Wasn't there a big falling out between the Matrix team and Element or am I misremembering what happened?
Element is the company formed by the team who created Matrix to work on Matrix, almost all of whom are still there; there is no falling out :)
The Matrix Foundation is the non-profit set up by the Matrix team in 2018 to keep Matrix itself independent of Element and other Matrix vendors - to act as a steward of the protocol and a standards body. Originally Element donated almost all of its code on Matrix to the Foundation (e.g. Synapse, the original Matrix server) as permissive Apache-licensed FOSS, assuming that if Matrix was successful, folks would want to fund it.
In practice, by 2023, Matrix was very successful... but it transpired that the vast majority of folks commercially building on the Foundation's Apache licensed code failed to route any funding back to the Foundation (as the hosting body) or to Element (as the primary code contributor), despite many polite requests. As a result, there wasn't enough $ to pay folks at Element to keep working on the core Matrix projects as their day job. So, to keep the lights on, Element stopped donating their work to the Foundation, and changed license to non-permissive AGPLv3 in order to sell AGPL-exceptions to the folks commercialising it. This has helped the situation somewhat (although Element isn't at breakeven yet). Meanwhile, it's left the Foundation focused on governance, the Matrix standards process, trust & safety and hosting core libraries like E2EE and matrix-rust-sdk.
There's no beef between the Foundation and Element over this. In a utopia the projects would certainly have stayed as Apache licensed code in the Foundation - but then again, other standards bodies like W3C or XSF don't publish code these days: it's a phase that a given protocol grows out of once third party organisations get busy building implementations.
Disclaimer: i'm conflicted on this, being project lead/co-founder for Matrix, and then CEO/CTO at Element.
I say this all the time, but the point of the permissive licenses is you're making a donation to private industry.
There are reasons to do this, for example if you believe that private industry adopting some technology is good and you want to make that happen.
But people keep seeming surprised by the fact that these donations aren't reciprocated (or at least people don't seem to plan for them to never be reciprocated). It sounds to me like the AGPL license was more consistent with their goals.
Not quite. The point of permissive licenses is that you're making a donation to everyone. If private industry uses your donation fine, if not that's fine too. But it's certainly true that if you have a problem with private industry using something you freely gave them, permissive licenses aren't for you.
FWIW I think AGPL is the right license choice for you. The more experience I gain the more I lean toward AGPL for products, MIT for libraries.
I don't think there's anything wrong with permissive license for a piece of software. But if you're running a business that needs to pay developers, it's really not a good idea. Very few, if any, people are going to donate to your project out of a sense of duty to help you keep the lights on.
I don't disagree, but I think the bigger risk is just that big companies who can and should throw some financial support your way, just won't if it's permissively licensed. They've demonstrated repeatedly that they'll just take the software and use it, including making (sometimes substantial) money on it, and none of that will flow back up.
There are ways to get web interfaces for Signal.
But I think the bigger issue is that any platform that controls the javascript sent to you from a web page, can also backdoor/MITM/inject malicious code at any time without you knowing.
For me the issue was contact names tbh. Is that solved? It used to be that the contact name was set by the contact and not by me/my address book.
You should not use it ! Xmpp is the answer with its few issues and matrix requires hell of system resources as well.
>lol Telegram
Did I miss something? what's wrong with telegram?
I'll tell you what's right about Telegram: I don't know how they're the only independent app that seems to be able to produce such a well built UI/UX for a chat application in 2025.
I maintain that someone should fork their codebase and bolt on a different backend (Signal, Matrix, whatever). It's right there and it's very, very good.
(Yes, I know it's not as simple as "bolt on a different backend". You know what I mean.)
> I don't know how they're the only independent app that seems to be able to produce such a well built UI/UX for a chat application in 2025.
Precisely because they don't spend so much effort for privacy. If your server can read all your messages, it's suddenly easier to provide great features. For instance, GMail can add your next hotel stay to your calendar automatically because it has access to your emails. That's great UX, but poor privacy.
This is not entirely true. For example, Calendar.app does the same by locally extracting the .ics out of Mail.app without ever sending anything to Apple.
I don't think Telegram's UX is tied to their permissive privacy, but they do seem to start with UX then do what's needed to support it. That does give them an edge. (Instagram has terrible privacy and actively mines information from chat and their UX is only passably good.)
> This is not entirely true.
My point is that it's generally harder to add those features in a privacy-preserving way. GMail couldn't do it if it couldn't read the content of the emails, period. It doesn't mean that there is no way to have nice features in a privacy-preserving way. I just said it's harder (sometimes impossible).
> I don't think Telegram's UX is tied to their permissive privacy
Not exclusively, but it is obviously a lot easier! Take a web client: if the server has access to the data, your client can just fetch it. If the server doesn't even know about the existence of the group, that's harder. Why do you think only the "secret chats" are E2EE in Telegram (and those don't support groups)?
> then do what's needed to support it
What do they do to support privacy? They don't have E2EE except in the secret chats! That hasn't changed in a decade!
> Instagram has terrible privacy and actively mines information from chat and their UX is only passably good
This keeps getting further from what I said :). Of course, it's possible to do worse than Telegram!
This is such an odd comment.
What on earth makes you think that the same engineers responsible for fluid and smooth UI/UX are the ones who’d ever influence the cryptography/privacy/security? Whether or not the chats are encrypted has zero to do with this.
Telegram has almost universally smooth scrolling, things work well across platforms, it’s native pretty much everywhere with low memory usage and mostly platform specific behaviors. Signal half asses this, and Element is… shoddy, at best, in comparison.
Telegram certainly has an excellent UI/UX. On the Element side, its quality bar has very much been the target for Element X - and (in my biased opinion) we are getting very close, if not exceeding it in some places. For instance, we just landed The Event Cache in Element X and matrix-rust-sdk (https://github.com/matrix-org/matrix-rust-sdk/issues/3280 - closed 2 days ago after a year of solid work), which provides seamless offline support and local encrypted-at-rest caching of the messages it's seen, which in turn then makes the native SwiftUI and jetpack-compose UIs go brrrrrr.
> its quality bar has very much been the target for Element X
I sincerely hope you get there, but it's really hard to believe it at the moment. You're not even at feature parity with the app (Element vs Element X) you're replacing, and it's been out for a bit now.
i.e, you have significant user experience related features that keep people using Element (open graph previews, just to name one).
It's just because all the effort has gone into EX over the last ~2 years, and it's a way way way better app (even if it doesn't have threads/spaces yet).
Meanwhile, Element One will support it shortly - the missing piece was MAS in production, which is now happening on matrix.org as per the OP.
I assume it's the lack of end-to-end encryption by default on basic features.
Good service btw, but not the best from a privacy point of view.
Besides that there it's also them choosing to roll their own crypto instead of using established cyphers and protocols.
And every time someone makes this comment. MTProto 2 uses standard crypto primitives. Besides this, do you know who else rolled their own crypto? Moxie. You don't get to roll your own crypto first and then weaponize this against your opponents but that's exactly what he did along with abusing words like "plaintext" to describe any encryption not E2EE.
It's nice to see their reasoning, but the issue remains: Telegram can read most direct messages (because almost no one uses private chats) and everything sent in groups.
It's a good service and in some cases it can compete with Matrix, Signal, etc, but most direct chats and all groups have no privacy from Telegram (and anyone with access to their servers).
I don't understand why you're downvoted for this question.
What's wrong with Telegram is the privacy story. It's not end-to-end encrypted, meaning that the server can read the content of your messages.
I hear that Telegram has a great UX, which makes it popular. But in terms of security... it's wanting.
Telegram is a joke in professional cryptography circles https://x.com/matthew_d_green/status/726428912968982529
To me it's just not an encrypted messaging app. I don't even get all the discussions about it...
It's a bit like if we analysed the E2EE guarantees of email over and over again. Every year, multitudes of people would publish a post explaining how email is "badly encrypted". Well, email is not E2EE, period. If you want E2EE, use a system that has E2EE.
You're again linking to old critiques of an old protocol no longer in use. Can you stop doing that, please?
1. It's not end-to-end encrypted by default.
2. No group chat, even a small one between close friends is end-to-end encrypted.
3. Almost all desktop clients support no end-to-end encryption for 1:1 chats, meaning if you use the desktop client as part of your workflow, you're forced to drop using the end-to-end encrypted secret chats.
4. No cryptographers have ever worked in the company.
5. Horrible teething issues for the protocol:
Telegram hosted a cracking contest back in 2013. Everyone in the industry know they are bullshit, and this was discussed back in 2013 The Fallacy of Cracking Contests (1998) | Hacker News The tldr is, Moxie issued a counter challenge to Telegram where he presented the same goals with already broken primitives like MD5, to break the encryption. Telegram never proved the challenge could be won even under those conditions. (Also again, given that Telegram’s built in backdoor of “people are lazy” exists, the cracking contest was pointless. It doesn’t matter how good the encryption is if the adversary wears you down to hand over the keys).
http://unhandledexpression.com:8081/crypto/general/security/...
https://eprint.iacr.org/2015/1177.pdf
https://web.archive.org/web/20160425091011/http://www.alexra...
https://words.filippo.io/dispatches/telegram-ecdh/
Also this:
https://blog.cryptographyengineering.com/2024/08/25/telegram...
> I assume that Meta has a backdoor into WhatsApp conversations
They don't need a back door when they control the front door: the app. End-to-end encryption doesn't protect the endpoints.
(In other words, your concern is warranted.)