"I really like Telegram. It being a secure messenger would make it perfect".
I'm not really snarking at you; a lot of things would be better if they were also secure messengers; Slack is an obvious example.
I'm not really snarking at you; a lot of things would be better if they were also secure messengers; Slack is an obvious example.
The parent comment is requesting that an existing feature be switched on as default and not introduce a whole change in the communication layer of the app.
Unfortunately you then lose syncing across devices, so I understand where telegram wants to make less secure the default.
I suspect there is enough implementation there to write a server implementation too, at least a simple one.
It's not. If you want to write your own, you have to reverse engineer most of the protocol. The clients aren't fully open source, and when they are, the public code usually lags behind the actual binaries that are released, often by months. It's nearly impossible to write a client that keeps up with the features in Telegram.
You may be thinking of the bot API documentation, which is documented. Many bots don't use that, though, as it's very limiting.
I suspect there is enough implementation there to write a server implementation too, at least a simple one.
The servers behave in very strange, unexpected ways, and the official clients expect these quirks. Most of the third-party clients either use TDLib, which is official and not fully open source, or have also grown to expect these quirks.
Just as a quick example, pretty much everything in Telegram has a numeric ID. Clients, bots, etc. have come to expect that IDs within certain ranges represent certain objects--users have a range, private chats have a range, channels have a range. These ranges aren't documented and may not be obvious even in a fully open source client, but if you don't adhere to them, stuff will break.
They're not: they reimplement their own frameworks on top of relatively low-level UI primitives.
Non-native to me is typically a a pure web client or when you use Java Swing or Electron.
What do you mean by native?
It's just a matter of how an application has been architected and how to transition a large platform for such an addition. Neither of these are easy to change/do with Telegram's current scale. Telegram also prides itself in very fast searches since it stores messages in plaintext on its servers.
It's not like it's technically impossible for Telegram to transition to E2E as the default and only way to communicate (similar to Signal, WhatsApp and Wire).
Telegram has its issues, yes, but it would be nice if we could agree at some point that it is possible to discuss security outside the context of E2E encryption.
> I'm not really snarking at you;
Well I'll have to take your word for that but you have a long history of showing up on Telegram discussions.
https://faq.whatsapp.com/en/android/26000005/?category=52452...
I'm not a security expert, but this sounds like an obvious problem.
Since your average users would be fine with this, it seems fair to have it as an optional feature.
It's also completely unable to work on multiple devices. Not really comparable in usability.
Interested, although not surprised, to see my factually indisputable comment getting massively downvoted.
Depending on one's threat model, this could be considered a feature.
But Signal is perfect to stay private against non-nation-state actors. If I want to make sure that my ISP, mobile carrier, etc. can't snoop on my messages, Signal is my phone messenger of choice. Until and unless Facebook is demonstrated to not be on the level regarding Whatsapp's implementation of the Signal protocol, then I'll keep Whatsapp on the list as well.
Telegram is not on that list. If my threat model consisted solely of "that guy with the manbun and macbook working on his novel in the coffeeshop", then maybe Telegram would be acceptable. Let me know when Telegram has default and mandatory end-to-end encryption, using a properly-implemented and proven-secure protocol like Signal's, on all clients both mobile and desktop. Until then I'll consider it to be about as secure as SMS - "hilariously not".
You don't seem to realize this, but your argument is essentially "I trust Signal more", a purely authoritative one. And I don't think there even exists a threat model where anything that Signal offers over competition is important, especially given their obsession with control.
So long as Telegram's developers refuse to implement mandatory-and-default end-to-end-encryption with a properly audited protocol and implementation in all clients, I will not use it. And I will discourage friends and family from using it.
Except there are no solid technical reasons, just trust and distrust, because security people really love to claim authority on how "solid" security things are. The last people on earth you should ask about security are those claiming authority on these issues.
Wrong, you already do. You either don't realize it, or you're being disingenuous about it.
Did you write 100% of the code of the web browser you used to post your comments?
Did you write the OS that browser runs on?
Did you write the compiler used to build the OS, and did you provably avoid the sorts of issues brought up in "Reflections on Trusting Trust"?
Did you fabricate the chips your OS runs on?
Did you design the die mask for those chips?
Did you build the chip fab facility?
Did you design the locks on the front doors of the chip fab facility?
Did you stay awake 24/7 inside the chip fab facility to make sure no-one broke in to conduct an evil maid attack on the process?
Unless your answer to all of the above is an honest "yes", at some point in the chain of tech, you accepted an outside authority. So kindly knock it off with the "you're automatically wrong because that's appeal to authority!" nonsense.