Совсем недавно я увидел статью, где говорилось о внедрении самоуничтожающихся сообщений в мессенджере WhatsApp. Она будет иметь схожую с Telegram функциональность, но если в мессенджере Дурова удаление распространяется как на обычные сообщения (секретные чаты), также их можно использовать на фотках в обычных чатах. То есть после отправки предположим фотографии, собеседник сможет просмотреть ее ограниченное количество времени, а после, по идее, она будет удалена у обоих собеседников (желательно с сервера тоже), то в WhatsApp планируется внедрение удаления обычных сообщений(и сделано пока оно так себе).
Но, сегодня речь пойдет не о WhatsApp (ибо я им вообще не пользуюсь), а о Telegram. Сама идея самоуничтожающихся сообщений вряд ли пользуется большим спросом, но и есть те пользователи, которые пользуются ими, например, при отправке документов или же фотографий, которые можно увидеть лишь раз (кхм).
Для тех, кто ленится читать – самоуничтожающиеся сообщения в Telegram не безопасны и не конфиденциальны. Не думайте, что если вы таким способом отправите какому-нибудь собеседнику важный документ, он его не сможет сохранить (и я сейчас не про способ быстрого скриншота или же фотографий экранов телефона, боже упаси) – для этого используйте секретные чаты. А для тех кому интересна сама реализация этих сообщений, можете продолжить чтение.
Пользовался и я ими, правда не часто и скорее это были просто «развлечение» и за ними я особо не наблюдал. В июне месяце этого года я исследуя UserAPI Telegram, тестировал отправку фотографий и их получение. Развлекался, не более. И интерес появился в просмотре «вида» отправки сообщений, и как вообще они отображаются в ответе. Мне стало интересно как реализована эта функция «изнутри», удаляются ли файлы с сервера Telegram или может они как-то шифруются.
И на мое удивление, эти сообщения практически никак не отличаются от обычных. Прям совсем. У них присутствует такой же file_id как и обычных фотографий, с помощью которого, можно получить сам файл. И при этом даже если вы просмотрели сообщение, и оно исчезло в чате, вы спокойно можете его сохранить/отправить/переслать и сделать все то же самое, что вы могли сделать с обычными фотографиями/видео. То есть оно не удаляется с самого сервера Telegram.
Повторюсь, такие сообщения не относятся к секретным чатам, где переписка находится на двух устройствах, и с другого клиента я не могу получить к ним доступ. Эта функция разработана для обычных чатов и вроде бы как считалась «безопасной». Но и тут интересно, я нигде не нашел подробное описание этих самых самоуничтожающихся сообщений. То есть Telegram как бы и не говорит нам, что эти сообщения такие безопасные в плане доступа (если у вас есть доступ к самому аккаунту) как например те же самые секретные чаты. Единственное, что я видел, так это то что сам Telegram говорил что никакие сообщения, даже секретные чаты не имеют 100 процентной безопасности и что каждый отвечает сам за сообщения которые он отправляет, но…
Признаюсь, было бы это реализовано в каком нибудь WhatsApp/Viber/VK, я бы даже не обратил на это внимание, но Telegram является очень удобным мессенджером, который я сильно люблю, но вот что я ненавижу, так это его поддержка наполненная волонтерами.
В том же июне месяце я написал на почту support@telegram.org, где я составил целое письмо на двух языках. Где говорилось не только про самоуничтожающиеся сообщения, но так и про обычные и что Telegram не ставит никаких лимитов на пересылку, но об этом позже.
Спустя два месяца мне так и не ответили, поэтому пришлось писать в ту самую «поддержку» Telegram об разъяснении, что делать и куда писать при нахождении такого рода «Уязвимости».
Там мне на удивление ответили спустя три часа, где рассказали, что писать о серьезных уязвимостях в протоколе необходимо на security@telegram.org или же поделиться подробностями «тут». Прикладываю оригинальный текст ответа от поддержки:
Я решил написать в саму поддержку о «подробностях» уязвимостей, прикладывая видео, сам скрипт и варианты решения проблемы (ниже есть мое сообщение), но, до нынешнего момента мне так и не ответили, ни на почте, ни в самой поддержке. Видимо пока, это их не волнует.
Кроме варианта с самоуничтожающимися сообщениями, я так же заметил, что любое сообщение, которое было удалено, например, в личном чате, группе, канале, так же легко перехватить. Делается это при помощи обычного форварда всех сообщений, например, в отдельную группу, а после доставания их с помощью ID удаленного сообщения (сейчас библиотеки имеют хэндлеры на них).
Я так же описывал весь процесс в своем письме (хотя на деле он прост), с вариантом решения проблемы в виде ограничения форвардов самих сообщений. И если не полностью ограничивать, то запретить постоянный форвард всех сообщений. Думаю, команда разработчиков сможет сделать некий антифлуд от форвардов.
А с самоуничтожающимися – просто удалять их с сервера. Это не решит проблему, сообщения все так же можно будет перехватывать именно в момент их получения. Для полного устранения следует переработать весь алгоритм их прочтения. К примеру сделать ключ доступа к каждому сообщению и при использовании этого ключа, изображение/видео будет доступно только определенное время. Мне сложно сейчас придумать за команду разработчиков весь алгоритм, признаю, я сам не в состоянии продумать все аспекты и в любом случае, найдется способ их перехвата. Но в данный момент, они реализованы просто ужасно, разработчик(-и) которые занимались этой функцией должны более ответственно относиться к разработке такого рода функции. Ну или на крайний случай так и написать, прямо красными, жирными буквами, что самоуничтожающиеся сообщения легко перехватить и это не более чем игрушка.
Расскажу о себе, 15 летний школьник, недавно увлекающийся разработкой на Python, баловался с User API и нашел такого рода «недоработку/уязвимость». Большее что взбесило и вынудило написать все это сюда – ужаснейшая реализация поддержки Telegram, которая просто меня проигнорировала три раза в течение 4 месяцев.
Для кого-то эта функция не окажется полезной, он не найдет ничего страшного в плохой реализации таких сообщений, но думаю, раз сам Telegram не заинтересован в совершенствовании нынешних функций, будет полезно чтобы другие просто это приняли во внимание.
Пишу статьи первый раз, мог где-то оставить ошибки, но надеюсь, что меня поправят в комментариях, указывая. Или же вообще, расскажут мне, что все не так и игнорирование от поддержки было хорошим решением и я наконец успокоюсь. Также прикладываю свое сообщение:
Recently, I wrote a user experience for my project. At some point, I noticed how my friend sent me a self-removing photo. I looked at it on my Android client and it was removed as it should be after 10 seconds.
But I wondered how such messages are encrypted and how they are stored on the go. After all, it turns out that the telegram client first uploads the photo to the phone, and after reading it must remove it.
I wrote a small python script using the Pyrogram library and wanted to see how they came to the client.
I was surprised when I saw that these «self-deleting photos» look just like regular ones (what?).
That is, if I sent a regular photo, it was no different from the “self-deprecating”.
After that, I wrote a script that sends this photo on the file, and at that moment, the photo went to my test channel like a normal photo. And on the phone from which I sent this most «self-extracting» photo, it was not even read.
It also allowed me to view the photo on my desktop client. That is, this script bypasses the most important essence of the «Self-extracting» photo.
I consider it a vulnerability, and I consider it a solution to reconsider the method of sending «self-deleting» messages and process them on the server and not on the device.
Also, I found the second one (almost a vulnerability), which was created using the API's telegram itself and is not prohibited at all.
So, we are talking about ordinary messages.
I also wrote a regular script that sends (forward) all messages from the chat to my group and marks them by their ID.
I added a handler to this script that responds to all deleted messages and gives the ID of these deleted messages (hello pyrogram).
After that, I added a script and now, when the handler responds to all deleted messages, it checks them with the messages from the group (which contains all the messages) and looks for this message by ID.
On the one hand, this does not violate anything, because telegrams have an open code, everyone can write their userbots. but on the other hand (russian is good), in the last update you added the function of deleting your own and others' messages for the sake of security, but such simple scripts written by a 15-year-old schoolboy seem to bypass this very security.
I understand that everyone responds in response that he sends, but a person can send important files to an unnecessary person by mistake and at this moment he will delete the message (While the interlocutor has not read) without knowing that all these messages can be compromised and most importantly, that messages are not marked read.
The decision, I think, is to add limits on forward messages and review the way of “reading” messages.
In the second video I attached how can I save all deleted messages without reading them.
I attach the video and script that I wrote to clearly show how it works.
И как это выглядит в коде(использовал библиотеку Telethon, на Pyrogram то же самое почти):
@client.on(events.NewMessage(func=lambda e: e.is_private and getattr(e, 'photo')))
async def handler(event: message.Message):
# event.input_chat may be None, use event.get_input_chat()
chat: InputPeerUser = await event.get_input_chat()
sender: User = await event.get_sender()
photo: Photo = event.photo
await client.send_message(img_channel, file=MessageMediaPhoto(photo),
message=f'<code>{chat.user_id}</code>\n'
f'<code>{sender.first_name}</code>\n', parse_mode='HTML')Комментарии (64)
atbuhw
05.10.2019 16:35+1«Самоуничтожение» и «безопасность» — в любом случае взаимоисключающие понятия. Какой бы протокол взаимодействия с сервером мы ни придумали, никогда нельзя быть уверенным, что получатель, используя модифицированный клиент, в момент получения не сохранит сообщение куда-нибудь так или иначе.
Хотя, конечно, сохранение «самоуничтожающихся» сообщений на сервере телеграма — это полный мрак и подрывает доверие ещё сильнее.Doctor5772
06.10.2019 15:18Хотя, конечно, сохранение «самоуничтожающихся» сообщений на сервере телеграма — это полный мрак и подрывает доверие ещё сильнее.
Доверять любым мессенджерам не стоит. Всё что отправляется в интернет — остаётся в интернете, такого принципа лучше всегда придерживаться.
Телеграмму тем более тяжело доверять, неясно как он монетизируется, серверная часть закрыта от всех, мы не знаем как собираются бинарники для приложений и клиентов, т.к. даже собрав из исходников, крайне сомнительно что будет 1 в 1. Плюс нет никаких гарантий что у таких клиентов не отсылаются «скрытыми методами» ключи. Так же регистрация по номерам телефонов тоже не плюс к безопасности, а скорее минус. До ввода двухфакторной аутентификации некоторые лица могли спокойно перехватить смс и войти в учётку без ведома пользователя. Подобное верно для многих мессенджеров, т.к. многие требуют номер телефона.atbuhw
06.10.2019 15:24Всё что отправляется в интернет — остаётся в интернете, такого принципа лучше всегда придерживаться.
Есть мессенджеры с открытым кодом клиента, которые отправляют в интернет только сообщения, зашифрованные открытым ключом получателя. В расшифрованном виде они остаются только у получателя.
в, т.к. даже собрав из исходников, крайне сомнительно что будет 1 в 1
В дебиане будет, это часть их политики добавления пакетов в репозиторий.
у таких клиентов не отсылаются «скрытыми методами» ключи
Что вы имеете в виду?
Так же регистрация по номерам телефонов тоже не плюс к безопасности, а скорее минус.
С этим целиком и полностью согласен.Doctor5772
06.10.2019 15:41Что вы имеете в виду?
Я имею ввиду что изощрёнными способами, в теории, можно передать закрытую часть ключа на сервер прикрываясь запросами на сам сервер телеграмма, т.к. никто не даст гарантий что тоже приложение под Android собрано без дополнительных «патчей».
Есть мессенджеры с открытым кодом клиента, которые отправляют в интернет только сообщения, зашифрованные открытым ключом получателя. В расшифрованном виде они остаются только у получателя.
С этим можно поспорить, если собран бинарник не вами, а кем либо ещё. Тут скорее вопрос доверия. Я же лишь хочу отметить, что доверие проверенному и собранному лично вами софту, несколько больше, чем собранному на стороне. Это к вопросу о критических данных. Понятное дело, что досканально всё смотреть и пересобирать, плюс такие самосборки ставить своим контактам никто не будет, или будет весьма малое количество людей. Подход к безопасности нужно строить исходя из ценностей данных. А учитывая что люди умудряются пересылать даже паспортные данные (не говоря о других документах и вещах) через мессенджеры, типа Viber, вопрос о безопасности мессенджера может отойти на второй план на фоне информационной безграмотности пользователей.
В дебиане будет, это часть их политики добавления пакетов в репозиторий.
Но вопрос ведь не только про Debian, есть ещё Windows, OSx, Android. Есть веб.версия клиента.atbuhw
06.10.2019 15:57никто не даст гарантий что тоже приложение под Android собрано без дополнительных «патчей».
Это правда, если клиент закрытый, т. е. мы не видели его исходников или не знаем, что это исходники от него (тогда он может и ключи передать, и сами сообщения, и вообще всё, до чего сможет дотянуться). Но если мы самисобрав из исходников
то мы знаем, что он отправляет, а что нет.
Тут скорее вопрос доверия.
До некоторой степени да, но это доверие всё же имеет под собой основу. Пакет из исходников собрать в debian и дистрибутивах на его основе очень просто. Если репозиторий будет отдавать не то, что собирается из исходников, это (вероятно, рано или поздно) заметят и опубликуют, а мы таких публикаций не видим.
Но вопрос ведь не только про Debian, есть ещё Windows, OSx, Android. Есть веб.версия клиента.
Это правда, при работе с конфиденциальными данными нужно убедиться, что и отправитель, и получатель соблюдают информационную безопасность, если мы не доверяем получателю, то можно ему как угодно защищённо отправлять данные, он всё равно сможет их разболтать после получения, об этом и статья.iig
06.10.2019 22:05"собрав из исходников
то мы знаем, что он отправляет, а что нет."
Даже если функции sendprivatekeytoserver в исходниках нет? ;) А есть, к примеру, неочевидное на первый взгляд ослабление ключа?
atbuhw
07.10.2019 14:47Да, наличие некоторых угроз проверить сложнее, чем наличие других. Но реализация собственно основных криптографических алгоритмов уже написана в многократно проверенных стандартных библиотеках, а если какой-то мессенджер пишет свою реализацию, это сразу же привлекает внимание тысяч программистов, которые ищут уязвимости.
Пользовательский интерфейс у каждого мессенджера, как правило, свой, но и убедиться, что он не лезет, скажем, в файловую систему, куда его не просят, при открытых исходниках проще, чем обнаружить плохую реализацию криптографии.
dartraiden
05.10.2019 16:44Вы вообще не можете быть уверены, что у собеседника стоит сторонний клиент Telegram, в котором удаление сообщений реализовано. И это касается даже обычных сообщений, когда вы удаляете их с включённой опцией «удалить у собеседника тоже». К самоудаляющимся это тоже относится.
Да, конечно, условия использования API Telegram явно требуют от сторонних клиентов удалить сообщение локально, если от сервера пришла соответствующая команда. Но мне никто не мешает написать клиент, который это требование проигнорирует. Никто об этом не узнает и доступ мне не отключит, если я один буду этим клиентом тихонько пользоваться.NikitaNike
05.10.2019 19:44Насколько я помню, секретные чаты, в которых реализованны самоудаляющиейся сообщения поддерживаются только в официальных клиентах.
dartraiden
05.10.2019 19:51+2Если что-то не поддерживается в сторонних клиентах, то это потому, что эти функции там никто не захотел реализовать.
Например, если в Miranda завтра кто-то запилит поддержку Telegram, то там не будет редактирования и удаления сообщений. Не потому, что Telegram не даёт такой возможности, а потому что журналы чатов вообще ничего не знают о редактировании (они писались во времена, когда таких фич в мессенджерах не существовало), а удаление сообщений умеют только два из них, и то локально, т.е. никакого способа передать это событие протоколу тупо нет.
atbuhw
05.10.2019 22:06Стоп, самоудаляющиеся сообщения разве только в секретных чатах присутствуют? В статье вроде сказано
также их можно использовать на фотках в обычных чатах
tyomitch
05.10.2019 23:02Нет, в обычных тоже присутствуют.
nuclight
05.10.2019 23:55И какими параметрами API это делается? В core.telegram.org/method/messages.sendMessage (не-секретные) такого нет.
NikitaNike
06.10.2019 01:48-1Самоудаляющиейся сообщения есть только в секретных чатах. В обычных чатах есть возможность удалить свое сообщение с текстом/картинкой, так чтобы оно удалилось и у собеседника, про это и шла речь в статье в этом месте.
pyrk2142
05.10.2019 17:39Имхо, есть два главных вопроса:
1) Рассчитывать, что недоверенное устройство, работающее в недоверенной среде и использующее произвольный клиент, будет работать так, что данные точно будут удалены — сомнительная идея. Но то, что файл не удаляется с сервера — весьма плохо.
2) В целом, мне не очень понятно, почему люди с такой настойчивостью рассматривают Телеграм как что-то большее, чем просто ещё один мессенджер. Большая часть сообщений просто хранится на сервере, обнаруживались довольно критичные уязвимости, компания не сделала ничего для информирования потенциально пострадавших пользователей, часто возникают вопросы к качеству реализации модных функций. Выглядит как описание ещё одного мессенджера, а не безопасного (лол) и конфиденциального (двойной лол), над которым работает реальная команда профессионалов.atbuhw
05.10.2019 18:20+1рассматривают Телеграм как что-то большее, чем просто ещё один мессенджер
Он лучше многих существующих мессенджеров наличием работающего опенсорсного клиента, как минимум под debian. То есть можно посмотреть его исходник и убедиться, что он, например, не отправляет на сервер телеграм файлы, о которых его не просили, или не позволяет атакующим получить произвольный доступ к устройству, как whatsapp: habr.com/ru/news/t/451810.
По остальным параметрам безопасности он действительно не особо лучше других известных мессенджеров, типа whatsapp и viber, а некоторых, вроде jabber — хуже.
Groosha
05.10.2019 20:29+1Только вот Jabber сейчас (имхо) — живой труп. Куча ХЕРов, которые поддерживаются разными серверами в разных комбинациях, отсутствие достойных клиентских приложений, сложность первоначальной настройки.
atbuhw
05.10.2019 22:01Я зарегистрировался (несколько лет назад) на jabber.de, поставил psi с помощью apt-get install psi, подключил в нём openpgp, и всё заработало, и кзалось бы, до сих пор работает.
kick_starter
07.10.2019 18:04довольно критичные уязвимости
Приведите пример хотя бы одной «довольно критичной» уязвимости, пожалуйста. Все те, о которых лично я читал, носили весьма минорный характер, а некоторые из них и уязвимостями трудно назвать, вот как в данном случае. В основном эти «уязвимости» публиковали школьники, желающие похайпить на теме, опять же, как в данном случае.
Большая часть сообщений просто хранится на сервере
Во-первых, не «просто», а в зашифрованном виде. Во-вторых, у вас есть хоть один пример, когда бы эти денные выдавались третьей стороне по запросу? Нет. Тогда в чём претензии?atbuhw
08.10.2019 00:45Приведите пример хотя бы одной «довольно критичной» уязвимости, пожалуйста
Привязка аккаунта к номеру телефона и всё, что с этим связано. Изначально это был единственный метод авторизации, пароль поставить было вообще нельзя, их сделали только позже. Потом было определения присутствия в чате по номеру телефона, из-за чего китайское КГБ составило очень точный список оппозиционеров в Гонгконге. Это то, что я сразу вспомнил точно.
Ещё смутно помню какие-то проблемы со сбросом пароля хитрыми способами, имея только телефон, это приводило к неполному сбросу аккаунта, вроде тоже факт присутствия в чатах настоящего владельца можно было проверить.kick_starter
08.10.2019 01:02Привязка к номеру изначально была функциональной особенностью телеграма, никто не обещал в нём абсолютной анонимности. И он также никогда не затачивался под организацию массовых протестов, будучи всего лишь средством обеспечения конфиденциальности персональной переписки, и с этой задачей, на мой взгляд, вполне справляется.
Да и потом, любой продукт развивается, и все эти вопросы на сегодняшний день уже так или иначе решены. Так что не вижу поводов для паники.atbuhw
09.10.2019 20:56никто не обещал в нём абсолютной анонимности
Я не про анонимность сейчас, а про взломы с использованием чтения SMS спецслужбами, перевыпуска SIM-карт и уязвимости SS7.
средством обеспечения конфиденциальности персональной переписки
В моём китайском примере конфиденциальность именно что была нарушена, когда сецслужбы узнали, кто именно состоит в переписке. Да, сами сообщения никто не прочитал (вроде???), но последствия от полученных данных были такие же, как если бы прочитали. Единственное, что может вызвать доверие к телеграму, что он хранимые у себя на сервере сообщения никому не выдаст — отсутствие аналогичных (по последствиям) прецедентов в прошлом. И эти уязвимости это доверие как раз и подрывают.
Denai
05.10.2019 18:09т.е. вся проблема в том что уничтожающиеся сообщения остались сообщениями и можно не самыми стандартными методами получить их содержимое, верно?
По логике в секретных чатах нужно просто заблокировать весь функционал, связывающий их со внешним миром, тогда проблемы бы не было.
Как, кстати, телеграм запрещает скриншоты делать в этих чатах?
Tettel Автор
05.10.2019 18:12+1Средствами ведра. Естественно root + любое устройство и можно делать скриншоты чего угодно. Но все таки отметить сообщение прочитанным
Anton23
05.10.2019 19:26+1Так себе фича со скриншотами. Даже рут получать не надо, можно просто сфотографировать экран телефона.
kick_starter
07.10.2019 18:08От таких вещей никакой мессенджер не защитит. Это вообще проблема, высосанная из пальца.
dartraiden
05.10.2019 19:56По логике в секретных чатах нужно просто заблокировать весь функционал
И противодействовать созданию альтернативных клиентов, разработчики которых могут не запрещать функционал. А для этого придётся протокол обфусцировать и код официального клиента закрыть.
Вспомнилась история с DiscordИх TOS запрещает создание сторонних клиентов, но протокол не обфусцирован и к разработчикам сторонних клиентов претензий пока нет. Так вот, проводя обратный инжинеринг протокола, мы (в Miranda NG) нашли интересную фичу. В Discord можно сделать чат приватным, куда сможет войти только тот, кто явно одобрен владельцем. В официальном клиенте, вы не видите такие чаты вообще, если вам нельзя туда войти. А вот от сервера вам всё равно прилетает список приватных каналов и даже их топики. Просто оф. клиент это не отображает. А через сторонний клиент я это вижу, потому что у нас пользователю показывается всё, что прилетело со стороны сервера.
С разработчиками Dicord я связался, они не видят тут ничего страшного и ничего делать не будут.Denai
05.10.2019 19:58если это отдельная сущность будет, в которой есть только примитивные безопасные действия, то всё будет ок и на альтернативных клиентах. Только раньше надо было об этом думать)
h0w4rd
05.10.2019 20:54+2Да, отображается. Это не проблема от слова совсем, ну видит пользователь канал и что? Все-равно он не может прочитать сообщения там, что гораздо важнее. И проверка, должен ли человек видеть канал = бОльшая нагрузка на сервера.
nuclight
06.10.2019 00:01О, а расскажите, как у вас в Миранде работает ВКонтакте, если они с марта сторонним приложениям запретили?
Festelo
06.10.2019 02:02Старые приложения всё ещё имеют доступ к этому API, а новые приложения могут запросить его через поддержку, насколько я знаю. (конкретно о том, как это работает (или нет) в Миранде — не в курсе)
dartraiden
06.10.2019 19:30Не то чтобы запретили, просто нужно пройти модерацию. Разработчик мирандовского протокола её прошёл. Запрашивали планируемую функциональность приложения, список требуемых методов, идентификатор приложения, ну и ссылку, где можно скачать и пощупать само приложение.
Daddy_Cool
05.10.2019 22:31+2Ясное дело, что уничтожение сообщений на устройстве-клиенте — так себе затея и не надо думать, что это нечто большее чем просто избавление от необходимости стирать что-то ручками. Приходит сообщение — типа «Шеф, усё готово к уничтожению Вселенной», прочитали… и тут отвлекли — срочный звонок там, маски-шоу, и т.п… А не кому не надо знать — потом ррраз — и не прочитали.
id_potassium_chloride
06.10.2019 02:02+2Мне кажется, это в принципе никак нельзя реализовать: всегда будет способ просмотреть информацию большее число раз, чем задумывалось отправителем. Что в Телеграме, что в других системах обмена информацией
DerRotBaron
06.10.2019 03:17-1Онлайн-DRM (расшифровка по ключу с сервера) + HDCP + проверка через фронталку на предмет присутствия только одного (и того, которое нужно) лица (и никаких камер).
Вот только, надеюсь, реализовать и использовать это в здравом уме никто не будет.
A114n
06.10.2019 10:08Телеграму в принципе плевать на пожелания людей, и это в общем обычное дело для всех крупных современных проектов.
Например — миллионы людей спокойно выкладывают не то что какие-то там фото и документы, а интимные фото и сканы паспорта, и не в виде «удаляющихся сообщений», а просто так, даже на файлообменники.
Вот на этих людей и рассчитан что Телеграм, что Ватсап, что прочие «мессенджеры» и «социальные сети». А 1-2% или даже 5% людей, которым хочется чего-то более сложного, никого не волнуют: потерпят или могут уходить, они никому не интересны.
Darkhon
06.10.2019 15:57Всегда удивляло, почему в РФ так непопулярен мессенджер Signal, при том, что популярный WhatsApp сейчас использует алгоритм шифрования, взятый изначально из Signal. По сравнению с Telegram, опять же, Signal уделяет намного больше внимания вопросам безопасности. Когда-то его даже рекомендовал Сноуден.
Doctor5772
06.10.2019 16:05У нас так сложилось исторически. До появления телеграмма массово не было такого беспокойства за сохранность переписки. Кто беспокоился, ставил сторонние клиенты типа Jitrix или Bittorrent messenger с поддержкой асинхронного шифрования между пользователями. Притом помимо «волшебной кнопки старта защищённого чата», такие мессенджеры позволяли увидеть «отпечаток» ключа собеседника и сравнить его. У телеграмма и ему подобных такого нет, и на мой взгляд это ещё один минус в плане безопасности — труднее опознать MitM
atbuhw
06.10.2019 16:15Подозреваю, что ещё одна причина — требование номера телефона при регистрации. Тех, у кого требования к безопасности высокие, это остановит, а те, у кого низкие, будут пользоваться чем-нибудь более популярным по историческим причинам, да хоть контактом.
SlavikMIPT
06.10.2019 21:15Я нашел критическую уязвимость в телеграме!!!111
Если открыть приложение телеграма, будут видны все диалоги и сообщения. Кто-то их может увидеть кроме вас. Например в маршрутке другие люди могут подсмотреть в ваш телефон. Оказывается телеграм не анонимный? Дуров нас всех обманул!
Нужно срочно с этим что-то делать!Tettel Автор
06.10.2019 21:52Правда Дуров ведь не говорил, что телега анонимна. Безопасна — да, анонимно — маршрутка
SlavikMIPT
06.10.2019 21:59что Вы подразумеваете под безопасностью?
я вот, например, потерял деньги если купив «стопудовую схему обмана вулкана» — это как — безопасно по вашему?
или, например, мой ребенок увидел порнографию?
или, например, я обсуждал планы свержения Путина, а меня поймали и при помощи терморектального криптоанализа получили доступ к моим сообщениям — это безопасно?
что по вашему мнению должен обеспечивать разработчик мессенджера?Tettel Автор
06.10.2019 22:16Скорее акцент на безопасность самого протокола. А вот порнографию по правилам тележки — низзя, мы за безопасность, но удаление из магазинов гугл плея и эпла — не хотим
SlavikMIPT
06.10.2019 22:49Ну так что должен обеспечивать протокол по Вашему мнению?
Tettel Автор
07.10.2019 05:07+1Сам протокол критиковать — мне дела нет. Но добавление "фич" с косметическими функциями в телеграм — глупо и странно. СмысОл самоуничтожающихся сообщений, если по факту, они нигде совершенно не уничтожаются
ivanych
Кровь из глаз...
Tettel Автор
Перестарался с форматированием? Или «недостарался» с содержанием?)
ivanych
Не старались писать по-русски.
Tettel Автор
Прислали мне правки)
Стыдно