If I take the kindest interpretation of your statements, they are factually wrong in whole but true in part. That is, the Telegram server code is closed source, yes. But Telegram clients and the protocols they use to "speak" are all either open source or documented where source code isn't applicable (MTProto 2). What's more is that reproducible builds are available for Android and iOS.
There's nothing really wrong with MTProto 2. You appear to be pointing to a very long time ago when MTProto 1 was in use. MTProto 2 is based on standard crypto primitives and is well-documented. No vulnerabilities have been announced by security researchers in the years it's been in use. It is ok that not everyone uses the Signal Protocol. Not everything needs to descend from Moxie.
I run my own Matrix homeserver and it's great. I also have it rolled out to all our employees at my workplace. It's an excellent choice. I also use Telegram because I appreciate its' balance of features and security. All of my family members love Telegram and that makes me happy because they're not using a Facebook product.
The way Matrix handles keys for E2E by default is not great: it's very easy for users to lose the key encryption phrase or not care and throw it away. I'm not sure how much better we can make E2E by default.
I am completely ok with turning on Secret Chats as I need them for chats I know to be disposable. My message history is extremely precious to me and Telegram does an admirable job protecting it and making it searchable for later reference. It truly is a sort of outboard brain for me.
This does not need to be a turf war between Signal people and Telegram people. I have expressed many times on the Telegram subreddit the need to come together in our use of better tools for communication than the incumbents. A person choosing Telegram or Signal over WhatsApp and Discord is a huge win for all of us.
How would you know without E2EE? A Telegram sysadmin could copy all your messages from non-secret chats and you would never know.
The lack of E2EE is also why many (including security experts) recommend WhatsApp over Telegram.
Telegram, on the other hand, is not open source, nor does it do e2ee by default. Having to explicitly select "new secret chat" ultimately means the non-technical inclined can and will use it wrong, getting no privacy whatsoever.
Therefore, I cannot support the idea that Telegram is any better than WhatsApp or Discord.
Regarding "open protocol", I suspect that what you think it means is not what an open protocol actually is.
But as far as I can tell, no steps have been taken since; In the downloads page, it warns me that for the Desktop version to work, I need to create an account with my phone first.
I'll keep an eye out.
1) option for large groups (around 250) This drops Signal out which has a limit of 150 on groups: https://support.signal.org/hc/en-us/articles/360007319331-Gr...
2) e2e encrypted (because it sounds good, not because people actually understand what it is), including groups. This drops Telegram out: no e2e rooms.
3) handles sending photos, videos, and voice messages. More or less kills XMPP, unless people are on the latest-and-greatest version of Conversations and maybe ChatSecure.
4) the maintaining organisation needs to be reasonably big with decent privacy.
5) usable for completely non technical generic population - meaning Tox is out as well.
As much as I dislike to admit it, this leaves Matrix, and nothing else. My problem with Matrix is that it's so resource hungry - both the servers and the clients - is that it's silly. Yes, I know "optimization is coming" but even Dendrite eats 1.5GB memory easily with a single user joining a few, medium sized, federated rooms (yes, I've tried).
Footnote: Threema... no. There is no need for yet another competing open source thing, there are enough with Signal, Matrix, and XMPP.
Dendrite is still in beta, and hasn't been tuned that much yet, but every release has had a substantial improvement. In other words, if you're not using today's release (0.3.5) you're on stale data. For context, dendrite.matrix.org (running 0.3.5) has ~5K users on it, and is in ~3K rooms spanning 162K users... and its RAM usage is stable at 488MB (occasionally spiking to 2GB during traffic spikes). This doesn't seem unreasonable at all for a chat server of that size. Meanwhile, Synapse has been steadily improving too.
On the client side, Hydrogen (https://hydrogen.element.io, https://github.com/vector-im/hydrogen-web) is our next-gen client implementation, which gives you full E2EE, complete with backup (I have no idea what Durov is banging on about in the OP) - and uses 14MB of RAM for an account in 3,000 rooms spanning 350K users (i.e. my personal one). This is an 100x improvement on Element Web which uses 1.4GB for the same account, although there's also a lot of optimisation that can be done there too.
If I was going to criticise Matrix, I'd focus more on the fact that there are still a lot of papercuts on Element's UX which are holding us back. We're painfully aware of this though and are trying to fix as rapidly as we can.
As you haven't mentioned it: Supporting e2ee isn't enough. It must be the default, else the non-technically inclined will often end up not using e2ee.
>As much as I dislike to admit it, this leaves Matrix, and nothing else.
I'm in the same position. Never been a fan, but I have to support it, because that's really the only option, even if bloated.
I also tried running a server (synapse) with similar results. I have hopes for dendrite, but they've just been dampened by your report.
Fortunately, the client side is far more important, and there's some options there. Particularly, the web-based hydrogen is massively less resource-hungry than the web-based element, and nearly there featureset-wise.
>XMPP
I didn't even list that one, because e2ee is not the default, and support was added way too late in the protocol's trajectory.
>Signal
I mentioned it, but I'm actually not about to use it. The reason is that accounts are tied to phone lines. That's a non-starter for me.
That is not a thing with XMPP. The very essence of it is adding things in, and OMEMO is quite good.
It is with this knowledge that I cannot recommend XMPP.
e2ee should be at the core. Not as an entirely optional extension added decades after.
As I already stated, because I want the non-technical inclined to have privacy, I can only support options where e2ee is the default.
The "only" problem is that it isn't easy, and thus most people do not use them at all.
Therefore, I cannot recommend XMPP.
can't be many
Seriously... setting up your own email server. All users use a web client (there are tonnes out there, with the option of using thicker clients).
Bots can be used to organise the groups, add new users, etc.
Most people chatting to their friends and family don't need that level of security.
If you don't want China listening to you: don't use someone else's system.
When you get into groups with hundreds of members I think Slack and Discord are probably the dominant chat apps there.
As far as old messages goes, Matrix rooms do not allow new participants to see old history, unless explicitly enabled.
>if you have 250 people in the chat I'm not sure it'll be very effective. It only takes one of those people to leak the messages.
Ultimately, the system is only good when the members of a room deliberately leaking messages is the primary concern; It means the system is working as intended, thus privacy is a matter of trust on the conversation members, as it is away from keyboard.
I can't suggest XMPP to non-technical people, because I know they'll end up talking to each other with neither e2ee nor awareness of lack of e2ee.
and how is it achieved when you want that? Standard feature that is expected by people using Telegram, Matrix, Slack, etc.
Your own link mentions "Size limit of 1000", where did you see 150?
To be fair that's for new groups, maybe the limit used to be lower. Or do you mean that in practice it's not usable beyond 150 people?
https://wire.com/en/products/personal-secure-messenger/
And why's Threema out? You can hardly complain that there is no solution to your needs, and then, when one is offered, say "no need for yet another solution"...
Are there any popular XMPP clients that don't support "HTTP File Upload" at this point? I went looking for a list of those that do and had to give up. They all support it now.
On it's own, XEP-0363 (HTTP File Upload) and OMEMO both work well everywhere, even in my horribly overpatched Pidgin.
But if you put the two together, Conversations, for example, will encrypt the message and encrypt the upload as well.
My Pidgin then will handle the message well, but display an url starting with aesgcm:// leading to the still encrypted file.
The question is then: is the correct behaviour what of Conversations is doing - encrypt the message and upload as well? If yes, is OMEMO a requirement to HTTP File Upload or the other way around?
When you send a pic in a conversation, the content-type of the resource is "image/*". It doesn't matter whether the image is encrypted, compressed on-the-fly, or whatever, the receiving end must "undo" all of it to present the intended resource to the user
Most XMPP clients are plugin based as well. Should the OMEMO plugin then look for aesgcm:// urls, download it, and decrypt it, or should the http upload plugin look for the availability of encryption and try to decrypt?
There will always be hacky and badly implemented clients. It comes with the idea of an open specification. That doesn't mean we should use them as a point of comparison.
It has a single UI, so it's out. Wire specifically disallows anything 3rd party.
And an Android app that doesn't combine the slowness of iOS and Android would be nice. To be clear - their animations (to me) drag on too long (as one might say about iOS), and UI input takes a noticeable amount of time (which is commonly found on Android apps that aren't well-written).
While this may not be helpful for anyone looking to improve the apps, that's kinda more of the same point - nobody is allowed to make a better client, as it's against the Wire ToS. This is why there's no Matrix bridge.
Found Matrix, happy with it. It likely will adopt MLS, too.
PS: these days swiss based is a bit of a stretch
I read the article and he claims it does? It's just that the default uses their cloud backup where Telegram has access to the private keys.
When creating a 1 to 1 chat, it's one of the default buttons. In Android, you click a {pencil} icon, then "new chat" (encrypted in transit and at rest like your bank website) or "new secret chat" (end to end encrypted)
> - It is not an open protocol.
The protocol is fully open source and audited. https://telegram.org/apps scroll down to source code.
> - It is not open source.
As above https://telegram.org/apps . The client apps are fully open source and reproducible.
> - It has a history of extremely poor cryptography practices.
People pointed out the security issues in MTProto v1, and they were all addressed in MTProto v2 over 3 years ago.
You may be recalling some FUD spread by the author of what eventually became Signal, but none of what you said above is factual.
"Now, normally the two sides would compute the shared key as (g^a)^b mod p and (g^b)^a mod p. Instead, the original version of MTProto computed it as
(g^a)^b mod p XOR nonce
where nonce was an arbitrary, supposedly random value sent by the server along with the peer’s public contribution.
This was a completely non-standard and useless addition, and all it did was let the server perform an undetected Person-in-the-Middle attack."
https://buttondown.email/cryptography-dispatches/archive/cry...
That's a really long way to say e2ee requires special steps: Deliberately selecting "new secret chat".
If there's ANY barriers to e2ee such as this one, then non-e2ee ends up being used.
That's just how it is, how non-technical people are, and why we should steer everybody away from Telegram.
What matters is that:
- It doesn't do e2ee by default.
- It is not a properly documented protocol[0].
- It is not an open protocol.
- It has a history of extremely poor cryptography practices[1][2].
- It is not open source.
Thus, we should steer people away from it, and into acceptable solutions that meet these fundamental requirements.
Matrix, Signal and Tox come to mind; I have experience with all of these, and I can only recommend Matrix.
[0]: https://core.telegram.org/mtproto
[1]: https://news.ycombinator.com/item?id=25726068
[2]: https://news.ycombinator.com/item?id=25641399