User talk:Evergreenstreet

"Sir, please stop, look at the header of the same competitor Whatsapp, there is nothing said about encryption at all, you say that you can not allow additional amendments from others, the problem is that they will start saying the same thing as you. If you think the opposite, then please register and start a talk so that everyone can give their opinion. If the participants&administrators agree, then you can administer this part of the header yourself. Until then, all such changes are canceled."

Wikipedia isn't a marketing platform. What WhatsApp page says has nothing to do with what Telegram page should say. Arguing that is whataboutism which is not just a logical fallacy, it's a propaganda technique. Also, I did not say you can't allow amendments from others. Wikipedia isn't a fanboy platform either, its users don't get to deny factual information just because they don't like it. Furthermore, Since WhatsApp always uses Signal protocol, it does not suffer from the same issue of servers having access to decryption keys.

Considering the vast majority of private messaging apps, Telegram is a major exception to the rules "everything is always end-to-end encrypted". Telegram is constantly portrayed on media as being equal to always-E2EE apps like Signal, or Threema, and this has spread a major misconception that Telegram is private. It is not.

Telegram is actually less secure than WhatsApp, because with WhatsApp, all messages are always E2EE, but all metadata leaks to service provider. With Telegram, all metadata also leaks, but also, all group messages leak to service provider, all Linux/Windows desktop client messages leak to server, and all messages by default, unless the user explicitly opts in for E2EE secret chats, leak to the server.

Telegram intentionally obfuscates this fact by using proprietary client-server encryption, with exact same name as its end-to-end encryption: MTProto. They do not even attempt to make clear distinction between the two by using separate terms, or by providing some specifier, e.g. "MTProto-E2EE", and "MTProto-CSC".

Using proprietary protocol prevents Wikipedia from linking to e.g. article on TLS. Furthermore, a major problem is, non-technical users wouldn't even follow that link, and they would never understand the meaning of client-server encryption, because TLS is generally reserved as outermost layer of encryption in all messaging apps, or for encrypting web-site traffic, which does not recognize the concept of third party server in the middle having access to user data, because the receiving end is not another user, but the server itself.

There is excessive amount of misinformation that combines sentences like "Telegram is always encrypted with MTProto..." "The end-to-end encryption protocol MTProto..." which lie by omission by leaving out the crucial detail "client-server encryption with completely different threat model is also called MTProto".

Explaining that with cloud chats the server has access to the keys allows users to make an informed decision on what they say in cloud-encrypted chats. People who have the "ok I'm not going to discuss this in case server gets hacked" in the back of their heads, are much more safe than people who naively write anything that pops in their head, without thinking of the long term consequences.

Telegram's server is not invulnerable against hacks, it's impossible to prove it's unhackable from the fact it hasn't been hacked yet. If users have a misconception that Telegram always uses E2EE, their security is at risk. Cursory interviews have shown this misconception exist even amidst my fellow students who also major in computer science.

I understand many readers and editors here think Telegram is a great application to get people to switch away from Facebook, and it's completely understandable they'd like to give passes to Telegram for doing bad job at security if it only means "freedom from GAFA" or whatnot, but this is false dichotomy. Not only is it the case there are multiple alternatives to both, including Signal, Threema, Wickr, Session, Briar..., but the fact is this article needs to provide relevant information about Telegram to its users, and future users, and people who want to understand the program. The correct solution to Telegram's non-standard practice of mixed E2EE and client-server encryption is not to pretend the problem doesn't exist, or to bury it at the bottom of massive Wiki-articles, but to get on with the times and deploy usable E2EE like other vendors do.

Telegram does extremely bad job in explaining the proper implications to security wrt. its client-server encryption on its web pages, but this article must not do so. It is not under the control of the vendor, nor under the control of its fanbase. It doesn't enjoy the luxury of censorship of vital security information.

I'm not asking you to explain all this in the top header, although it would provide more substance than it does now, but critical piece of information what client-server encryption does, is VITAL to not just the neutrality of the article, but to also dissidents' lives in oppressive countries. Encryption saves lives, and vice versa, badly understood encryption actually endangers peoples' lives.

There is nothing non-neutral about saying "client-server encryption means server has access to the keys". The only reason someone would think this is non-neutral, is if they didn't want people to know this piece of information. Perhaps they're embarrassed about the implication, or perhaps they'd prefer people to not know the huge implications is has to security.

The security risks are real, and have been underlined by known security researchers and cryptographers multiple times:

https://twitter.com/esultanik/status/1129026682260721666?lang=fi

https://twitter.com/matthew_d_green/status/726428912968982529?lang=fi

https://www.schneier.com/blog/archives/2016/06/comparing_messa.html

Welcome Evergreenstreet! Now that you've joined Wikipedia, there are 41,016,419 registered editors!

Hello Evergreenstreet. Welcome to Wikipedia and thank you for your contributions!

I'm Sm8900, one of the other editors here, and I hope you decide to stay and help contribute to this amazing repository of knowledge. Alternatively, leave me a message at my talk page or type  here on your talk page and someone will try to help. To get some practice editing you can use a sandbox. You can [//en.wikipedia.org/w/index.php?title=Special:Mypage/sandbox&action=edit&preload=Template:User_Sandbox/preload create your own personal sandbox] for use any time. It's perfect for working on bigger projects. Then for easy access in the future, you can put  on your user page. By the way, seeing as you haven't created a user page yet, simply click here to start it.

Please remember to: The best way to learn about something is to experience it. Explore, learn, contribute, and don't forget to have some fun!
 * Always sign your posts on talk pages. You can do this either by clicking on the OOUI JS signature icon LTR.png button on the edit toolbar or by typing four tildes  at the end of your post. This will automatically insert your signature, a link to your talk page, and a timestamp.
 * Leave descriptive edit summaries for your edits. Doing so helps other editors understand what changes you have made and why you made them.

 Sincerely, Sm8900 (talk) 03:30, 24 February 2021 (UTC)   [//en.wikipedia.org/w/index.php?title=User_talk:Sm8900&action=edit&section=new&preload=Template:Welcome_to_Wikipedia/user-talk_preload (Leave me a message)]

Español

Deutsch

Français

Italiano

עברית

Русский

日本語

Polski

فارسی

Sm8900 (talk) 03:30, 24 February 2021 (UTC)