В конце февраля 2021 года выходит обновленный релиз клиента Telegram с заголовком: ‘Автоудаление, виджеты и временные ссылки для приглашений’.
На красивой, художественной обложке к пресс-релизу новой версии Tg-мессенджера пользователи видят корзину с таймером и уничтоженными данными, а также лицезреют главных героев из культового хакерского сериала Мистер Робот. Но действительно ли все так круто с зачисткой следов как и в сериале?
Telegram подготовил для пользователей что-то из security-области, а эти дотошные исследователи тут же навострили ручки. Подробная вербализация одной ‘bug bounty’ описана по тексту ниже...
Цитата из пресс-релиза:
Автоматическое удаление сообщений
Уже несколько лет пользователи Telegram могут бесследно удалять сообщения для всех участников беседы. В секретных чатах с 2013 года также есть таймер самоуничтожения, который позволяет не удалять сообщения вручную.
С сегодняшнего дня автоматическое удаление сообщений для всех участников доступно в любом чате. В этом режиме сообщения исчезают через 24 часа или 7 дней после отправки.
Так же информация о sec-функции упомянута тремя пунктами в официальном changelog-e Tg.
Установите автоматическое удаление сообщений для всех через 24 часа или 7 дней после отправки.
Управляйте настройками автоудаления в любом из ваших чатов, а также в группах и каналах, в которых вы являетесь администратором.
Чтобы включить автоматическое удаление, щелкните правой кнопкой мыши чат в списке чатов> Очистить историю> Включить автоматическое удаление.
Я протестировал нововведение в Telegram на Android и ничего подозрительного не обнаружил. Всё security-заявленное со стороны Tg работало так, как с обложки. Спустя только несколько суток (минимальный, честный срок автоудаления сообщений - 24ч.), проявив усердие, я добился того что искал: сообщения которые должны автоудаляться у участников личного и приватного групповых чатов <удалялись> только визуально (очистка окна сообщений), а в реальности сообщения-картинки оставались на устройствах в открытом кэше, который доступен любому пользователю по пути: /Storage/Emulated/0/Telegram/Telegram Image.
Сам тест на проверку очень прост: устанавливаем таймер автоудаления на 24ч. (в личке или групповых чатах); обмениваемся картинками. Ждем сутки. Проверяем путь /Storage/Emulated/0/Telegram/Telegram Image, картинки автоудалились. Отменяем автоудаление и снова ставим таймер на 24ч и повторяем первоначальные действия. Обычно автоудаление не срабатывает на 2..4 раз. Как только картинки остались в кэше (вышел баг с автоудалением сообщений), можно таймер на чате оставить в покое, все последующие дни будет очищаться только окно сообщений в мессенджере, а картинки будут оставаться в кэше (зачастую у получателя и отправителя, а не только у отправителя сообщений).
Протестированный на разных гаджетах Android 7-10 (Xiaomi; Samsung; Asus), найденный баг обесценивал функционал: автоудаление сообщений для пользователей, позволяя в будущем эксплуатировать уязвимость в своих личных и безобидных интересах.
Зная о негативном отношении компании Telegram к исследователям (в т.ч. на своем предыдущем опыте), а также найдя интересную информацию в СМИ, что за аналогичный баг Telegram выплатил исследователю 2,5к зеленых шуршунчиков, и в последствии: уязвимости был присвоен CVE-2019-16248 с высоким базовым рейтингом опасности 7.5 пунктов (upd: после публикации этой статьи, уязвимость была пересмотрена до 5.5 пунктов):
The "delete for" feature in Telegram before 5.11 on Android does not delete shared media files from the Telegram Images directory. In other words, there is a potentially misleading UI indication that a sender can remove a recipient's copy of a previously sent image (analogous to supported functionality in which a sender can remove a recipient's copy of a previously sent message),
я принял решение снова поработать с Telegram. Согласно программе bug bounty на Hackerone
5.03.21 я отправил отчет по уязвимости на security@telegram.org. К моему удивлению
7.03.21 я получил ответ (далее по тексту пунктуация и орфография сообщений полностью сохранены):
Hello,
Thank you for your email. We will send you an update soon.
All the best, Telegram Support
По истечению ~месяца тишины (вышло очередное обновление мессенджера, в котором уязвимость “автоудаление сообщений” все еще не была исправлена), и я снова напомнил Telegram о своем письме.
3.04.21 получил следующий ответ:
Hello,
Thank you for your email and sorry for the long wait. We will reply soon.
All the best, Telegram Support
Никакого в ближайшее время обновления я не получал (увидел, что Tg мессенджер снова обновился и проблема всё еще сохраняется) и спустя месяц снова напомнил Tg о своем релевантном отчете 2-х месячной давности.
9.05.21 получил ответ, примерно-который я уже получал:
Hello,
We are sorry for the long wait. We will send you an update soon.
All the best, Telegram Support
Подумав, что переписку ведет бот и до разработчиков мессенджера мне не удастся дописаться, отправил в ответном письме, что если они не против, то я выйду со статьей об уязвимости в СМИ. Такое письмо возымело эффект и через несколько часов
14.05.21 получил ответ:
Hello,
We don't have automatic responses here. Please wait, we will send you an update soon.
All the best, Telegram Support
Я согласился подождать, обычное дело. Через полтора месяца Tg снова обновился до новой версии и снова уязвимость не была исправлена. Я написал в Tg, что уязвимость в новой версии мессенджера все еще не исправлена и
29.06.21 получил ответ:
Hello,
I'm sorry for the delay. Thanks for the details.
Re: logs.
You can send the logs to Saved Messages, open the file and make sure that it does not contain any sensitive information.
All the best, Alex Telegram Support
7.07.21 Я создаю приватный, групповой чат и приглашаю для тестирования бага и наглядности представителя Tg присоединиться к нему.
8.07.21 получаю ответ:
Thanks for the details. There are two different files on your screenshots: they have different names and sizes, and they have been sent in two separate chats.
All the best, Telegram Support
В этот же день в чат заходит представитель Tg (в будущем изменив свое имя с ‘support’ на ‘Николай’) и предлагает в дальнейшем решать вопрос с багом на русском языке.
Тесты
Тестируем мессенджер по моему плану, по его плану. Наглядно показываю, что проблема не выдуманная, когда сообщения-картинки не автоудаляются у 2/3 участников группового чата в рандомном порядке и не автоудаляются в личных чатах. Спустя ~месяц тестирования мессенджера на разных клиентах/версий Android-Telegram (официальных и сторонних: Tg FOSS, Tg GP) Николай признает существование проблемы, и казалось бы развязка уже близка и косвенно затронута тема награды.
Обещанную в течение недели beta-версию Tg с исправлением так и не прислали, но позже
23.08.21 попросили еще немного подождать. Цитирую:
(Задерживаемся, но про вас помним.)
К началу сентября мне предоставили ссылку на beta-версию Telegram. Поработав с ней я снова сообщил о том, что проблема автоудаления сообщений все еще сохраняется. Ко всему прочему в ней было сломано: “ручное удаление сообщений”, после такой иллюзорной зачистки данных в чате (очистка окна сообщений клиента) все файлы не удалялись с гаджета пользователя и были доступны в кэше там же: /Storage/Emulated/0/Telegram/*. Также наблюдалась проблема с отправкой аудио-сообщений в форматах .wma/.aac. Забраковал. Прогнав следующую build beta-версию Tg, я согласился, что проблема автоудаления сообщений картинок наконец-то исправлена.
«Упс! Что-то пошло не так»
Оставалось решить вопрос с наградой и поставить галочку в своем послужном списке.
5.09.21 с security@telegram.org приходит письмо:
Hello,
Thank you for vert long wait. We would like to award you with a bounty of EUR 1,000 for your findings. Could you share the following info for the agreement please?
1. Your bank account details:
* your full name
* bank name
* account number or IBAN for payments in Euro
* SWIFT code
2. Your full address including the postal code.
3. Date of birth.
Much appreciated!
All the best,
Alex
Telegram Support
В ответном письме уточняю: могу ли я получить оплату на PayPal например? Получил ответ, что нет, нужен банковский мой счет в евро и персональные данные.
В ответном письме предоставил Telegram свои персональные данные и свой банковский счет в евро для зачисления награждения в 1к евро.
17.09.21 я получил письмо с security@telegram.org на русском языке:
Спасибо! Подпишите, пожалуйста, договор на двух последних страницах и пришлите, пожалуйста, весь документ как PDF. Можно использовать DocuSign, если неудобно печатать.
С уважением,
Alex
Обычно при обнаружении уязвимостей исследователи и разработчики руководствуются в программах подобных bug bounty пунктом о разумных сроках по ответственному раскрытию информации, чтобы у разработчиков было время на исправление, а у исследователя его слава. Например, когда я репортил уязвимость в Яндекс, срок молчания составлял 90 дней. А после окончания срока я всё равно уточнял у Яндекса о том, могу ли я раскрыть тех.детали в СМИ? И тогда сотрудники транснациональной корпорации мягко свели мою просьбу на ‘нет’. И в СМИ (тогда 2020 году) я не опубликовался, сохранив общение с командой Яндекса на позитивной ноте. В течении следующего 2021 года зарепортил еще одну уязвимость по Яндексу и без проблем получил вознаграждение, а также оставил за собой моральное право на публикацию материалов согласно положению об охоте за ошибками.
Но вот иногда компании с хорошей репутацией пытаются вести свои игры.
Изучив присланный на email договор представителем Telegram, обратил внимание на то, что Telegram требует не раскрывать никаких деталей сотрудничества/тех.подробностей по умолчанию без своего письменного одобрения, в т.ч. чеки, банковские выписки и публикации в СМИ с упоминанием имени компании и тд. Договор у Telegram (в моем случае) оказался расписан аж на 8 страницах (приложен в конце статьи), а сама публичная программа мягко говоря сокращена.
Договор я не подписал, а в ответном письме отправил вопросы по нему (цитата):
Здравствуйте представители и разработчики Telegram!
Некоторые вопросы по договору:
в договоре п1.2. “Confidential Information” сообщается, что к конфиденциальной информации относятся (в том числе и):: техническая информация; и даже уровни сборов и комиссий. И согласно п9.1::. "Консультант не должен ни в течение срока действия настоящего Соглашения, ни в любое другое время после его расторжения: 9.1.1. разглашать или передавать любую Конфиденциальную информацию любому лицу, компании, юридическому лицу или другой организации 9.3. Консультант не должен ссылаться на Компанию или любую Компанию Группы в каком-либо пресс-релизе, реклама или материалы без предварительного письменного согласия Компании."
По умолчанию получается, что Telegram "против" практически любого раскрытия информации без специального письменного запроса. Кроме того при получении гонорара я обязан отчитаться в налоговый орган и предоставить чек, в котором будет отражено получении гонорара (и этот чек также попадает под конфиденциальные данные, что является странным). Можем ли мы в договоре изменить сроки в п9.1 на разумные сроки о неразглашении каких-либо деталей?
Если все же об оказанных услугах/исследованиях не стоит нигде и никогда публично распространяться в СМИ и тд., (в любом случае) можете ли вы пересмотреть добросовестный, финансовый гонорар относительно аналогичной уязвимости, за которую исследователь получил вознаграждение в разы выше, чем предлагается в мою пользу по договору и учитывая мои настойчивые старания по усилению конфиденциальности мессенджера?
Спасибо вам! И на связи.
Выше был последний ping с представителями компании Telegram, после которого те перестали выходить на связь, оборвав общение.
27.09.21 и 28.09.21 Я написал на почту Telegram напоминание о письме без ответа и попросил в Tg Николая напомнить коллегам о переписке. Кроме того я добавил, что баги, которые я обнаружил в beta-версии Telegram (в т.ч. сломанное ‘ручное удаление сообщений’, тот баг за который исследователь в прошлом получил 2,5к $) перешли в официальный релиз (при переходе с beta на версию FOSS и далее на версию Tg с оф.сайта). Он прочитал, но промолчал. И (пару недель молчания) я принял решение обнародовать имеющиеся материалы в СМИ.
Выводы
Конфиденциальность пользователей Telegram снова осталась под угрозой. Пользователи надеются/надеялись на заявленный security-функционал: автоудаление сообщений (картинок), который не работал, как задумано на Android устройствах до версии v8+ (на других платформах баг не проверял) и который вводил их в заблуждение.
Помог разработчикам устранить уязвимость с автоудалением сообщений в мессенджере в период полугода: с 5 марта по 5 сентября 2021 года.
В официальных пресс-релизах новых версий Telegram не упоминалось ни разу о существовании и решении проблемы с автоудалением сообщений. https://desktop.telegram.org/changelog https://telegram.org/blog
Так как все мои чаты настроены на автоудаление сообщений, иногда эксплуатировал баг, чтобы восстановить данные, которые пользователи считали уничтоженными имея веру в Telegram и даже не знали о проблемах, и в будущем не могли повлиять на их ликвидацию, например, с помощью ручной очистки чата.
Обещанную награду от Telegram ни в 1000 евро ни какую другую я не получил, а по классике
палец вверх.
Неизвестно: сколько уязвимостей остается/останется ‘замятых’ из-за NDA-требований Telegram дешевых взяток за молчание, а не за вознаграждение за баги:: не распространяться и косвенно о проблемах мессенджера публично без письменного одобрения со стороны Telegram. Но при этом П. Дуров в СМИ призывает своих пользователей не верить на слово исследователям, а доверять только оф.информации компании, которая иногда чувствительная и скрывается/контролируется юридическими договорами заключенными с исследователями.
Мы рекомендуем пользователям не полагаться на СМИ и дожидаться официальных объявлений Telegram.
Мы не хотим платить журналистам и исследователям, чтобы они рассказывали о Telegram.
Прилагаю договор, который мог бы быть заключен между мной и Telegram, но так и остался не акцептованным (в нем изменены только мои персональные данные: ФИО и адрес).
Прилагаю, самое первое (от 5.03.21 года) и последнее (от 28.09.21 года) видео с воспроизведением проблемы в Tg: автоудалением/ручной очисткой чатов.
UPD: спустя несколько дней после публикации статьи
НКО MITRE уязвимости присвоен CVE-2021-41861.
UPD_2: Так как я работал с Tg по программе, размещенной на HackerOne (площадка является гарантом), попросил последних по возможности провести расследование в отношении Tg и их обфусцированной программы для исследователей на HackerOne. В ходе переписки представители HackerOne сообщили, что не могут помочь и привлечь Tg к ответственности, так как выложенная программа на HackerOne не связана с Telegram (еще один трюк от непорядочной компании Tg, который необходимо учитывать багхантерам при разборе багов).
Пример сравнения корректной и обфусцированной программ bug bounty на HackerOne
Ответ от HackerOne
Комментарии (202)
itsoft
29.09.2021 09:54+64Почему у многих такая беда с обратной связью и короной на голове?! Ведь корона не упадёт, если общаться с людьми с человеческим лицом, а не с чинушьим.
Alexey2005
29.09.2021 13:09+15Это не корона, а банальная оптимизация расходов. С целью снижения издержек всё взаимодействие — как компании с внешним миром, так и отдельных команд/подразделений внутри самой компании — сведено к небольшому количеству строго регламентированных кейсов (в программистских терминах их можно называть интерфейсами).
И как только попадается ситуация, выходящая за пределы прописанных интерфейсов, компания не может корректно обработать подобный случай, и начинается лютейший неадекват.
Проблема по-видимому не имеет решения, ведь чтобы её решить, нужно очень сильно поднимать расходы. Проще смириться с тем, что время от времени система будет выдавать Fatal Error, и придумать методы снижения финансового ущерба от подобных факапов.
Iamkaant
29.09.2021 14:55+8Грамотная эскалация на высшие уровни менеджмента должна эту проблему решать.
napa3um
29.09.2021 22:16DDoS
Iamkaant
30.09.2021 15:06+2...отсекается на нижних уровнях
Artyomcool
01.10.2021 20:08+3С периодическими ложными срабатываниями, как и у любой системы отсекания.
О чем собственно и говорит автор первого комментария)
itsoft
30.09.2021 00:26+4Так в статье же сказано, что зарегистрировали, изучили, признали проблему, ответили и пообещали исправить. То есть конкретно тут никакой проблемы. Проблема другая.
itsoft
29.09.2021 14:57+2И это можно озвучить гораздо короче, гораздо быстрее. И будет честно. И корона не слетит.
Это понятно, что нельзя объять необъятное. И можно даже с чем-то мириться. Только при этом надо быть честным и не обещать то, чего нет. А говорить, что все врут, и мы как-то плохо…
Но бывает часто, что дело не в ресурсах даже. Просто не хотят и нет ответственного человека. А на самом деле поправить ничего не стоит.
tendium
29.09.2021 19:25+8А еще часто в компаниях решение багов дело неблагодарное, и повышения закрытием багов не добьёшься. Поэтому проще сделать вид, что багов нет. А когда опубликуют какой-нибудь баг в паблик, потом это уже становится приоритетом для бизнеса, и тогда — наконец-то — можно решать и не бояться за KPI.
itsoft
29.09.2021 22:59+5И все 500 000 000 пишут? И все прям по багам?
Если сервис заявляет, что у него есть такая-то функция, но есть баг и про этот баг напишет 1000 человек, то надо всем ответить. При этом никто не мешает все 1000 обращений объединить в один кейс.
xenon
05.10.2021 12:40+1Я давно как-то думал, про какую-то систему с "деньгами" (очками) или "кармой". Если обращения человека в саппорт "по делу" (показывают его квалификацию, указывают на реальные проблемы) - его карма или счет растет. Если ему в самом деле помогает совет "перегрузите компьютер" - то падает. У любого хорошего спеца она будет скакать (все мы тупим иногда), но в целом расти. И вместо полумиллиарда пользователей останется 50 000, к сообщениям которых надо отнестись очень внимательно.
nuclight
14.10.2021 19:58Отличная идея. Да для новых соцсетей/мессенджеров и существующие системы кармы следовало бы исправить — например, версия хабра никуда не годится.
GDragon
01.10.2021 16:56+2Взгляните пожалуйста на Google.
Какая у них аудитория?
А ведь у них ещё и доходы не в пример Telegram.
При этом зачастую даже в сервисах непосредственно связанных с деньгами - том же ads.google при малейших проблемах тебя отправят читать справку и на этом их полномочия всё.
Про поддержку же Google в целом, разве что анекдоты не ходят.
AndreyHenneberg
05.10.2021 11:55Про поддержку же Google в целом, разве что анекдоты не ходят.
Плохо. Надо исправлять. Может, тогда зашевелятся, потому что это уже станет вопросом репутации в массах. Это разница между «я знаю, ты знаешь, он знает» и «все знают и все знают, что все знают». И анекдоты — как раз признак и способ показать всем, что «все знают».
bazzilic
06.10.2021 10:44+1Надо исправлять - а кому "надо"? У гугла краеугольный камень их бизнес-модели состоит в том, что у них нет поддержки и расходы на нее ноль целых ноль десятых. Дизайн их продуктов в целом и такие особенности как глубокая провязка любого продукта с подробной документацией - всё продиктовано отсутствием поддержки.
dartraiden
29.09.2021 09:57+54иногда эксплуатировал баг, чтобы восстановить данные, которые пользователи считали уничтоженными имея веру в Telegram
Только, наверное, не в Telegram, а в конкретную реализацию его у собеседника?
Потому что ничто не мешает добавить поддержку Telegram, скажем, в Miranda NG, которая вообще ничего не знает ни про какое удаление или изменение сообщений в своей локальной базе по команде протокола. Да, это нарушение ToS Telegram, но если я такое напишу сугубо для себя, кто об этом узнает?
Ну или банально — дописать в родной клиент функцию, которая будет делать скриншоты каждого сообщения.
Всё это удаление сообщений (чатов целиком и отдельных сообщений) держится лишь на том, что мы верим в то, что клиент собеседника это умеет и выполнит. То есть, верить этому нельзя и стоит сразу предполагать, что переписка сохранена на той стороне, независимо от нашего желания. А на своей стороне теперь известно, что стоит чистить кэш.
Такая же ситуация и с сохранением этой переписки на сервере. Он пользователю неподконтролен, проверить, удалилось ли там что-то реально — невозможно.
Areso
29.09.2021 10:00+5Потому что это официальный клиент?
Есть сервис и сервера Телеграм, есть официальные клиенты - Telegram и Telegram X, и есть все остальное, совместимое. Насколько велика совместимость это вопрос.
sets
29.09.2021 11:03+14А еще можно не уметь программировать, не уметь/желать ставить альтернативные клиенты и просто скринить все подряд имеющие смысл сообщения.
Телега многовато о себе думает в плане этого договора, но автор существенно переборщил с пафосом про нарушение конфиденциальности и угрозу пользователям.
ne555 Автор
29.09.2021 11:09+7автор существенно переборщил с пафосом про нарушение конфиденциальности и угрозу пользователям.
Я исходил от подобного: CVE-2019-16248
nuclight
30.09.2021 15:05Уже подмечено, что в CVE стали попадать спорные моменты, и не всегда именно на ту программу в комбинации из нескольких, приводящих к вызывающему вопросы поведению.
dartraiden
29.09.2021 12:04+5С другой стороны, а что вообще может сделать Telegram, кроме как грозить отключить от сервиса сторонние клиенты? При условии, что протокол открыт, палки в колёса создателям сторонних клиентов не ставятся (сравнить хоть бы с WhatsApp, который постоянно гоняет запросы, ожидая получить строго определенные ответы, единственной целью которых является обнаружение сторонних клиентов), наличие рута на устройстве не проверяется…
Кроме как грозить, ничего не остаётся.sets
29.09.2021 12:12+6Как-то по-меньше обещать удалять сообщения у всех участников беседы. Говорить о такой возможности, при условии что остальные участники беседы не предпримут контрмер. Стронние клиенты тоже слабая защита от логирования картинки на экране.
Но по здравому размышлению автор статьи все-таки прав, неудаление фото на телефоне отправителя — вот это точно уязвимость и угроза пользователям.dartraiden
29.09.2021 15:04Но по здравому размышлению автор статьи все-таки прав, неудаление фото на телефоне отправителя — вот это точно уязвимость и угроза пользователям.
Достать удалённый файл тоже можно. С ограничениями, т.к. это не HDD, но можно. Впрочем, от незатейливого атакующего, который ограничится просмотром существующих файлов, обычное стирание файла поможет. В конце концов, если заявляется удаление переписки, то надо удалять всё её содержимое, тут я согласен — это недоработка Telegram.
bgBrother
29.09.2021 14:12+9вообще может сделать Telegram, кроме как грозить отключить от сервиса сторонние клиенты
К примеру, переименовать авто-удаление в «Попросить программу собеседника всё удалить». Будет очевидно какой «друг» это сделает, а какой — нет.
johnfound
29.09.2021 21:11+1Будет очевидно какой «друг» это сделает, а какой — нет.
А это как? Как узнаете удалили или не удалили?
bgBrother
29.09.2021 23:30+3Благодаря доверию или недоверию к конкретному человеку и его софту.
siziyman
30.09.2021 15:59А как из доверия следует "сделает"/"не сделает"?
bgBrother
30.09.2021 16:02Я предполагал, что при наличии доверия сомнений в сказанном собеседником не будет. В связи с этим можно заранее спросить о его приложении — удалит ли оно автоматически указанные сообщения или нет.
siziyman
30.09.2021 16:08+1Как самый минимум, право человека добросовестно заблуждаться никто не отменял.
Как максимум, можно самому не сомневаться в собеседнике, но быть очень неправым: хорошо разбираться в людях умеют немногие.
johnfound
01.10.2021 11:00+2Какая-та наивность есть в вашем посте. Ведь вы написали: "Попросить программу собеседника всё удалить".
Попросили. Программа ответила "Хорошо, все удалено". И что??? Откуда вам знать, удалено ли все на самом деле или нет? Во первых программа может врать. Во вторых, даже если и не врет, то в ней может быть баг и на самом деле файлы были не удалены. А если все таки все удалила, нет никаких гарантии что нет копии. Они могут существовать несмотря на том знает об этом программа (владелец программы) или нет.
nuclight
30.09.2021 15:06А есть где-то пригодное к реализации описание протокола WhatsApp? Или они его меняют постоянно? Летом возникала мысль — попробовать разобрать то, как общается веб-версия, но не силён в JavaScript и его деобфускации.
dartraiden
30.09.2021 15:10+2nuclight
01.10.2021 00:03О, спасибо! Вижу, что оно не законченое, но дока хотя бы пишется, и питон наверное попроще JS будет для понимания...
zuek
29.09.2021 12:34+13Да можно банально, сказать OneDrive/GDisk/YaDisk бэкапить "/Storage/Emulated/0/Telegram/*" в облачное хранилище по расписанию, и всё - вместо удаления картинок получим тыкву. Так что критичность бага всё же несколько преувеличена...
elfukado
29.09.2021 16:09+5При чём тут вообще данная статья?
Если говорить о намеренном сохранении вашей переписки, то можно записать экран и всё, ничего не поможет.
Только к багу это не имеет никакого отношения. Если собеседник намеренно не сохранял вашу переписку - она должна была удалиться, но не удалялась. Не надо выдумывать миллион других вариантов, баг от этого не пропадёт.
zuek
29.09.2021 17:29Ещё раз - я не отрицаю наличие бага, я просто указываю на преувеличенность оценки его критичности - тут скорее не нарушение приватности, а "течёт локальный кэш картинок", что тоже неприятно (хранилище не резиновое), но к собственно приватности отношение имеет куда менее сильное.
У нас в фирме, например, почти все пользователи синхронизируют кэш картинок WhatsApp и Telegram в корпоративный OneDrive - в первую очередь из-за того, что картинки из переписок WhatsApp имеют противную тенденцию переставать открываться по прошествии некоторого времени, если запускались встроенные в систему инструменты очистки временных файлов (а служебные смартфоны имеют довольно скромные характеристики, и при активном обмене служебными "фотоотчётами", забиваются весьма быстро), да и доступ с рабочего места к архиву картинок в OneDrive обычно более быстрый, чем через десктопные клиенты.
solntsepek
29.09.2021 20:29В WhatsApp разве можно обмениваться картинками (документами)? Он же их все пережимает до непотребного размера?
elfukado
30.09.2021 06:10+3Большинство пользователей, услышав про автоматический бэкап кеша изображений в облако будут выглядеть примерно так:
Так что когда простые пользователи случайно отправляют не ту картинку и удаляют - она действительно удаляется, а если нет, то это серьёзная проблема. А вдруг у него потом будут проблемы из-за этой картинки, которую ему по ошибке отправили ночью и сразу удалили, а он её даже не видел и даже не смог бы задуматься об очистке кэша?
logran
01.10.2021 12:34+2Если начать бороться с тем, что вы описываете — выйдет копипаста про хакера и солонку…
В рамках работы клиента телеги данный баг есть и для клиента телеги это критичный баг. А нюансы безопасности Android и прочего стороннего окружения авторы телеги не со своей стороны решать должны — это должен андроид обеспечивать.
AndreyHenneberg
05.10.2021 12:10+1В первую очередь, это защита автора сообщений: если телефон захватили и взломали, восстановить сообщения и тем самым скомпрометировать владельца таким способом уже не получится. То есть эта функция как бы и не должна защищать от сохранения на другом конце, потому что это невозможно сделать при наличии у собеседника желания эти сообщения сохранить.
lunacyrcus
29.09.2021 22:14Ну вот да, это с различным поведением клиентов наиболее очевидное, далеко от тонкостей с кешами.
Думаю уже давно альтернативные клиенты которые не автоудаляют, да и даже в офф клиенте телеграмма под декстоп например, есть экспорт истории, который скорее всего тоже автоудаление игнорирует (если экспортировать до того как оно произойдет), да и что тут говорить если банальное копирование или скриншоты его обходят, тем более что собеседник знает когда автоудаление активируется.
Статья слишком громкая явно (увидев ее я подумал сначала уж правда что-то вот прямо вообще, посливали там телефоны или еще что, а тут на деле какие-то картиночки в кеше), такие вот моменты то очевидны обычно для тех кто реально как-то задумывается о конфиденциальности.
AndrewRo
29.09.2021 23:39+3А какой смысл в том, чтобы скринить сообщения? Это должен настраивать получатель, а ему-то это зачем? Они и так эти сообщения видел и читал. Удаление нужно для того, чтобы третье лицо, получившее доступ к телефону, не получило доступ к истории переписки, и больше ни для чего.
Ndochp
30.09.2021 07:55+1И для того, чтобы получатель не мог показать третьему лицу эти сообщения. Проскакивала же история, когда нечистоплотный мальчик пытался поссорить друга с его половинкой удалив половину сообщений так, чтобы оставшаяся выглядела изменой.
Ну типа1. Пап, можно я возьму 5к с друзьями погулять 2. Нет. 3. Ты сейчас что делаешь, футбол смотришь? 4. Да.Удаляем 2, 3
Мам, дай 5к, папа разрешил, смотри:
1. Пап, можно я возьму 5к с друзьями погулять 4. Да.ne555 Автор
02.10.2021 08:05+4А после этой истории разработчики могли сделать, подобное:
1. Пап, можно я возьму 5к с друзьями погулять
2.
Сообщение удалено/дата3.
Сообщение удалено/дата4. Да.
intelligentpotato
30.09.2021 03:25-3Дико бесят люди-снежинки, неспособные отвечать за свои слова и удаляющие свои сообщения. И Телеграм - тем, что потакает им, добавляя всё новую псевдоприватность, анимированные стикеры, шкурки для чатов и прочее-прочее-прочее, чтобы нравиться всё более и более широким массам.
Очень давно уже нахожусь в поисках клиента, который позволял бы по желанию включать/отключать "функции для снежинок". Если уж даже для проприетарного VK сделали VK Coffee, то для Телеграма, с учётом открытости кода, работы - всего ничего. Вопрос - такие клиенты есть, и о них просто не распространяется в силу запрещённости такого рода модификаций, или правда никто не сделал?
А так - способы сохранять в неизменном виде историю как обычных, так и приватных чатов, есть, ведь то, что ты послал клиенту, уже не твоё, и распоряжаться он этим может так, как хочет. Просто это неудобно, когда у тебя история не в приложеньке с поиском, а лежит логом на диске.
nuclight
30.09.2021 15:33Джва года "пишу" такой клиент (сырые логи в CBOR давно уже валятся на диск, конечно), но кроме юридического запрета в ToS телеги, упираюсь в техническую проблему проектирования базы. Ведь схема данных телеги постоянно меняется, а требование работы клиента у конечного простого юзера сводит выбор ровно к одной базе — SQLite. Но поскольку нужно хранить исторические данные, в том числе версии редактированных сообщений, нужно предусмотреть как диффы для экономии места, даже для не-сообщений, так и каким-то образом сделать по этому добру индексы для поиска (а еще бы желательно предусмотреть поддержку других похожих протоколов, не только телеги) — а как, если оно постоянно меняется? Что делать с NOT NULL? И т.д.
Просто свалить в JSON — ничем не будет отличаться от логов на диске по сути.
В "обычном" IT такую задачу решают примерно никогда потому что в норме схема базы под контролем, и к ней еще и администратор приставлен.
проприетарного VK сделали VK Coffee, то для Телеграма, с учётом открытости кода, работы
Так ведь всё равно наоборот. API VK довольно-таки несложный, открыт и сравнительно хорошо документирован. В то время, как протокол телеги сущий ужас, документация на API неполна, обновляется редко — это реверс-инжиниринг во многом практически, пусть и по коду открытых клиентов, но оного реально МНОГО. Поэтому все альтернативные клиенты телеги обычно заканчиваются на не очень большой либе, которая позволяет делать произвольные запросы — читай, только ботов.
Специально, чтобы было именно так, в телеге делают им подконтрольный tdlib, который берёт на себя базу и протокол — соответственно, и не хранит "по протухшей схеме", и не-удалять из базы он не даст.
dartraiden
01.10.2021 02:26но кроме юридического запрета в ToS телеги, упираюсь в техническую проблему проектирования базы
Мы (в Miranda NG) тоже в это неизбежно упрёмся, если таки найдётся время и силы прикрутить tdlib. Поскольку протокол это просто транспорт, он ничего не знает, как там хранятся сообщения в базе, это не его дело. За базу отвечает отдельный плагин (а он, в свою очередь, ничего не знает о протоколах, его дело — работать с базой определенного формата, в нашем случае — SQLite). И поддержки изменения существующих событий тупо нет (архитектура приложения закладывалась 20 лет назад, когда ни о каких редактированиях и серверной истории никто не помышлял), поэтому изменённое сообщение расценивается как новое сообщение и кладётся в базу отдельно.nuclight
04.10.2021 12:40А как у вас сейчас сделано в хранилище с разными протоколами и поиском/индексами? Только самые общие поля типа "кто", но без "где" ?
поэтому изменённое сообщение расценивается как новое сообщение и кладётся в базу отдельно.
Вообще-то, это плюс (и не только для сообщений, но и для других объектов, например, показывать имя/аватар юзера на тот исторический момент), я так и хочу сделать, чтобы иметь историю редактирований, это сугубо в интерфейсе их объединять надо — и разве что подумать насчет DoS частыми редактированиями.
nuclight
01.10.2021 01:04+1Выношу ответ на ответ из привата, т.к. человеку заминусовали карму, но мы тут никуда не спешим, думаю, на периодические ответы хватит.
Зачем изобретать велосипед с собственным хранилищем?
Ну прежде всего затем, что я хочу применить это не только для телеги, а и для других подобных протоколов, хоть того же VK, или вот в соседней ветке dartraiden ссылку на идущий реверс WhatsApp подкинул, а то может даже и Хабр с Опеннетом, чем черт не шутит. И желание добавить плагины тоже потребует чего-то своего в базе.Мне видится куда более топорный способ: просто отрезать обработчик удаления сообщений, а в обработчике изменений сообщений вызывать код, как будто бы пришло новое сообщение с ответом на изменяемое. Потребность в собственном хранилище и поиске отпадает, всё хранится и ищется штатными средствами клиента.
Ни один клиент не ищет — это делает сервер. Да, к TDLib приделан FTS5 для поиска по тексту, но и только (он даже падежи не сможет). Посмотрите, какая у них схема для сообщений github.com/tdlib/td/blob/bb36d97482e4a70d80235a0d87d5befba0305e1f/td/telegram/MessagesDb.cpp#L117:db.exec("CREATE TABLE IF NOT EXISTS messages (dialog_id INT8, message_id INT8, unique_message_id INT4, " "sender_user_id INT8, random_id INT8, data BLOB, ttl_expires_at INT4, index_mask INT4, search_id INT8, " "text STRING, notification_id INT4, top_thread_message_id INT8, PRIMARY KEY (dialog_id, message_id))"));
Вот в этом `data BLOB` лежат данные в TL. Как думаете, что произойдет, если схема обновилась, а в локальной базе оно лежит в блобе в старой TL-схеме и не смогло десериализоваться? Я не знаток C++, и по наличию в дереве только одной, самой свежей TL-схемы предполагаю, что это сообщение просто будет выкинуто и запрошено с сервера заново, если оно там еще есть.Очистку кэша, естественно, тоже отключить, а сам кэш дампить на диск. Об экономии места можно не париться. Те, кому нужны такие функции, готовы мириться с тем, чтобы отдать под это лишний гиг. По крайней мере, лично я готов.
Кэш сообщений есть только у мобильных клиентов и у TDLib. У Telegram Desktop его, например, нет (точнее, он там только для media). Ну и работают с ним они таки как с кэшом — выкидывая, если что не так. А для обсуждаемого хранилища так нельзя.Ведь схема данных телеги постоянно меняется
К слову, тот же VK Coffee построен на базе приложения VK 5, наверное, летней давности. Содержание важнее оболочки в данном случае.
Да, и поэтому оно будет на Tcl/Tk под ActivePerl 5.20 для Windows XP =)API VK
Есть задокументированный API для разработчиков, а есть API для официальных клиентов с куда более широким набором функций. Он не документируется, его только реверсить, что и было сделано в Coffee, если не изменяет память.
Слышал о таком, но сталкивался с такой разницей только на примере музыки пока. Той же Миранде вроде официального API хватает. А этот VK Coffee открыт, разработчики доступны?протокол телеги
Я как-то хотел на базе клиентского API телеги сделать парсер, открыл доку, увидел тайпскрипт, проблевался, расхотел. Прекрасно понимаю.
Не, тайпскрипт куда приличнее, чем TL.Специально, чтобы было именно так, в телеге делают им подконтрольный tdlib, который берёт на себя базу и протокол — соответственно, и не хранит «по протухшей схеме», и не-удалять из базы он не даст.
Получается, что всё. что я написал выше, из-за TDLib не реализуемо? А если отрезать функции непосредственно в нём? Сорс же тоже открыт.
Я не знаток C++ (и к тому же не люблю его), а объемы кода что в TDLib, что в Telegram Desktop — громадные (уточню на всякий, TDesktop сделае **не** на TDLib). Поддерживать такие патчи, возможно, окажется сложнее, чем написать клиент на скриптовом языке с нуля — ведь там код постоянно изменяется, его ж люди на зарплате пишут.
Если бы это было просто, это бы уже сделали, но пока что наблюдаются лишь проекты типа github.com/SpriteOvO/Telegram-Anti-Revoke (сработает только до рестарта клиента) — очень простые, без серьезных изменений.
dartraiden
01.10.2021 02:20+3Дико бесят люди-снежинки, неспособные отвечать за свои слова и удаляющие свои сообщения.
Да при чём тут снежинки. Вот мои последние случаи, когда требовалось удалить:
— промахнулся чатом, запостил картинку не туда
— промахнулся картинкой, отправил человеку два одинаковых скриншота подряд, а собирался два разных
— подруга скинула пароль от онлайн-аккаунта, я им воспользовался и стёр на обеих сторонах, зачем его хранить?
Это для меня возможность быстро поправить ошибку. Как и редактирование сообщений, когда я сначала быстро пишу, а затем после отправки замечаю, что написал слово с ошибкой. Не будь возможности что-то поменять, пришлось бы выбирать: либо позволить собеседнику усомниться в моей грамотности, либо писать второе сообщение, с исправлением ошибки. Оба варианта такие себе.logran
01.10.2021 12:41+2— промахнулся чатом, запостил картинку не туда
— промахнулся картинкой, отправил человеку два одинаковых скриншота подряд, а собирался два разных
Решаются разрешением на удаление у обеих сторон только при условии что вторая сторона не прочла. Ибо если вторая сторона уже прочла — удалять немного поздно. Можно оставить небольшой таймаут (1 минута) после отметки о прочтении, что позволит удалить левую картинку из общей группы, но не позволит фабриковать переписку вычищая сообщения за последние сутки не только у себя, но и у собеседника.ne555 Автор
02.10.2021 07:51+2Можно попробовать найти компромисс для обеих сторон: сторона которая не желает, чтобы их переписка была сохранена и другая сторона, которая не желает чтобы переписка была/казалась сфабрикованной.
После удаления сообщений, на это место помещать плашку: "
сообщение удалено/дата"Так реализовано, например, в element.
logran
02.10.2021 08:43+1Не эффективно для случаев когда один пользователь хочет напомнить другому что "ты же говорил" или пожаловаться на слова пользователя (за те же домогательства к несовершеннолетним например), а вместо пруфов "сообщение удалено" и ушедший в отказ отправитель "не было такого, там тортики обсуждали".
Если сообщение уже прочитано и истек отведенный (короткий) интервал на осознание что "отправлено что-то не то, надо удалить" - имхо удалять задним числом уже не стоит. Как минимум у прочитавшего и осознавшего получателя. Ибо в основном так делают с мутными либо мошенническими целями.
Исключение - секретные чаты с самоуничтожением, в которых сразу явно плашкой указано обеим сторонам что переписка будет уничтожена. Там получатель в курсе что "или скринь, или значимое не обсуждай", а отправитель в курсе если его скринят.
Am0ralist
02.10.2021 10:46+1А как можно быть в курсе того, что собеседник фоткает экран на другой телефон?
logran
02.10.2021 11:50Никак. Но от этого никакое удаление не спасет. Потому и говорю что удалять есть смысл лишь до тех пор пока от клиента получающей стороны не пришла отметка о прочтении + 1 мин таймер на случай общих чатов с кучей людей. Ибо дальше уже сообщение можно считать заскриненным/зафотканным/записаным/etc.
nuclight
04.10.2021 12:42Все эти случаи покрываются общим «быстро обнаружил», и в общем-то раньше в телеге и было такое, что отредактировать/удалить можно только в течение 2 суток (что, впрочем, многовато).
pehat
29.09.2021 10:05+41Вы ещё верите в то, что сообщение, отправленное другому человеку, можно стереть на его стороне? Это как в защиту дискет от копирования верить.
nerudo
29.09.2021 10:43+3Дискеты хотя бы от стирания можно было защитить!
ionicman
29.09.2021 10:56+16Это тоже заблуждение. Да, ключ там был, и даже распознавался, но на многих дисковводах можно было прямыми командами принудительно записать или стереть что угодно. Аналогичное потом было и у SD карточек - флаг "пользователь не хотел-бы чтобы что-то изменялось", а вот решать смотреть на этот флаг или нет - дело софтовое. Очень много картридеров даже соответствующего контакта для детекции этого флажка не имела)
nerudo
29.09.2021 10:57+12Вы разрушили мою вселенную!
Halt
29.09.2021 14:18+10Таки да, флажок на полноразмерной SD карте, который выглядел наподобие DIP выключателя, на самом деле не подключался электрически к микросхеме и не запрещал запись на аппаратном уровне. Это просто кусок пластика перекрывающий окно, так же как вырез или окошко на дискетах.
insolite
29.09.2021 20:17+3«Защита», использующаяся в SD-картах – это типичный пример применения общей концепции, которая называется Honor system.
zuek
29.09.2021 12:40+3Про дисководы с погнутым сенсором окна защиты от записи ещё в школе узнал. Про SD - ещё когда люто-китайский ридер сумел на мою флэшку 256МБ с cureit, "защищённую от записи", записать "автораннер", но вот зато была у меня USB-флэшка Transcend, правда всего на 32 МБ, с реальным переключателем RW/RO...
tmin10
29.09.2021 20:30+4Да, переключатель жаль, что не делают, у меня на самой первой флешке такое было, на 1 гигабайт. Вроде даже вполне ещё работает. Почему-то потом решили, что защита от записи пользователю не нужна вовсе.
nobodysu
30.09.2021 00:05+1eVtran, если не боитесь потенциальных китайских rubber ducky.
Иначе Silicon Power, но там USB2.
AllexIn
29.09.2021 11:04+2Защита на дискетах вполне себе существовала и была весьма эффективна. Помойму Бачило рассказывал о вариантах такой защиты. Да и на хабре что-то проскакивало.
UPD:
agmt
29.09.2021 16:37+2Заклей защиту от записи на VHS — почувствуй себя
взломщикомbug bounty hunter'ом.
balamutang
02.10.2021 09:27Обход этой защиты был в каждой инструкции к видеомагнитофонам и на каждой кассете нарисован.
lunacyrcus
29.09.2021 22:19+1По идее, то можно стереть) Если отправить ему сообщение, а потом стоя рядом с этим человеком в момент получения, удалить его на его телефоне...
Вот уж гениально.
alexgantera
30.09.2021 00:46Простите, но я вот что-то не понял о какой вере вы говорите. Человек написал мне, а потом удалил своё сообщение. В это не нужно верить, сообщение из беседы удалено. Всё, я его не вижу.
Ndochp
30.09.2021 07:48+1Это если вы не предприняли усилий по защите от таких удалений. (скриншоты, бэкапы, альтернативный клиент, получивший сообщение, сложивший его в кэш и не умеющий в команду удаления)
Yokushiro
30.09.2021 15:25Неужели информация поступившая от них и моментально удаленная НА СТОЛЬКО важна, чтобы я так сильно заморачивался? Ну скинула подруга не тому нюдсы, ну удалила… не проблема)
AlexanderS
29.09.2021 10:45+24Обещанную награду от Telegram ни в 1000 евро ни какую другую я не получил.
Зато сколько пафоса от руководства компании, в т.ч. лично его руководителя, в части заботе о пользователях, конфиденциальности и всё такое.
Судя по тому, что я о подобном читаю с регулярной периодичностью, складывается такое впечатление, что крупные фирмы из-за неумения или нежелания выстроить бюрократический механизм в части обеспечения безопасности (да, баги к этому относятся, так как априори неизвестно как найденные дыры можно использовать) и какой-то что ли жадности сами создают предпосылки для того, что складывается ощущение, что лучше продать баг на рынке, чем обращаться по баунти. Парадокс в том, что на этот путь толкают даже тех, кто хочет искренне улучшить продукт, так как складывается впечатление, что легальные механизмы работают чуть больше, чем никак.
Shiaju
29.09.2021 10:45+5Нередкий пример того, как некомпетентность ключевых исполнителей может привести к крупным, в данном случае репутационным, потерям для бизнеса.
Firz
29.09.2021 12:33Мы же не знаем(на сколько я понял) какое реально было ТЗ на фичу и видели ли его вообще те, кто занимался маркетингом и рекламированием этой фичи. То есть даже непонятно(со стороны) кто виноват в такой ситуации.
FedorovDimulya
29.09.2021 15:05Мне кажется, в данном случае не большой урон репутации будет, но если продолжат в том же духе, то все может быть
anonymous
00.00.0000 00:00
BoberMod
29.09.2021 13:20средствами ОС или ещё каких 3их приложений
Да без проблем, TDLib и огромное количество библиотек для работы с клиент апи телеграма позволяют сделать это очень быстро и просто
nuclight
30.09.2021 15:42В каком месте подконтрольный телеграму TDLib проигнорирует команду на удаление сообщения с сервера?
Isaac_ods
29.09.2021 13:22+4Дело в другом, включу мод параноика: удалил ты компрометирующие сообщения перед митингом, тебя поймали, а в нужной директории остался нужный фсб материал и вот, ты уже участник террористической организации
На самом деле ситуация с тимлидом из Епама в Беларуси показывает, что такое вполне возможно
esc
29.09.2021 20:16+3А не проще прислать вам какую-то нужную картинку уже после задержания и изъятия телефона? Или просто залить, если уж есть доступ к файловой системе.
Эксперт, если надо, подтвердит что там она была всегда.
Хотя, чтобы просто оправдать арест, в таких случаях, вряд ли нужен эксперт. На принтере напечатают, принесут в суд как протокол осмотра. А там и без этих бумажек знают какое решение нужно вынести.
SquareRootOfZero
30.09.2021 04:06+1Если логически продолжить построения «а зачем X, а не проще ли сразу Y», то довольно быстро становится непонятно, зачем делать хоть что-то вообще. А картинку зачем заливать? А арест зачем оправдывать? А производить этот арест зачем? Просто прийти да пристрелить — сказать потом, что сам первый с ножом кинулся. Опер-группа подтвердит: да, кинулся, да, с ножом, с тем самым, который нашли у него в спине. Перед смертью признался в терроризме и шатании устоев, сдал подельников, к ним уже выехали.
Однако ж, почему-то запариваются со всеми этими «приличиями» — где-то надо картинку найти на телефоне, где-то ее надо хотя бы залить, где-то хотя бы протокол на принтере напечатать. Видимо, психологическое что-то.esc
30.09.2021 14:33Не психологическое, а уголовно-процессуальный кодекс. Нужен он, чтобы уменьшить перегибы "на местах". "Менты" могут действовать не совсем по закону, но только в рамках сговора разных структур, а не по хотелке любого опера. Арест это ж ведь не инициатива одного лишь задержавшего мента. Его должен поддержать следователь, прокурор и потом одобрить судья. Каждому нужно чем-то подтвердить или обосновать свое согласие.
Соотвественно, беспределить можно либо по указке сверху либо в составе довольно крупной ОПГ в которую входят сотрудники разных ведомств (и где решение принимают не рядовые опера, а те, кто над ними) не мешая тем, кто сверху.
Такая организация позволяет полиции (и прочим службам) выполнять не только карательные функции и использовать должность для личного обогащения, но и поддерживать порядок в той или иной мере. И они поддерживают, можете не сомневаться. Даже в весьма отсталых государствах с полицией получается гораздо лучше, чем без нее. А страны СНГ тут далеко не самые отсталые.
Потому и фальсифицировать доказательства будут в установленном порядке;)
balamutang
02.10.2021 09:33Ситуация с тимлидом из Беларуси показывает что силовикам не нужен повод для того чтоб вломиться и застрелить любого. А раз уж до этого дошло, то файлы со схемами бомб дописать на смартфон уже мелочь.
Так что если у вас на дворе диктаторский режим, то телеграмм тут не виноват.
amarkevich
29.09.2021 14:32+3можно попробовать расчитать стоимость подобных багов по формуле
QA salary * QA count / found issues
думаю, что стоимость подобных "бажков" может значительно превышать затребованную сумму с учетом ЗП over 1k €. Поэтому экономически целесообразно серьезнее подходить к программе Bug Bounty.
inferrna
29.09.2021 10:54Дарю забесплатно идею разработчикам мессенджеров, в том числе тг:
Автоудаляемые сообщения и картинки шифруем отдельной парой ключей
При каждом запуске приложения обновляем ключи для такого рода сообщений с сервера (как вариант - запрашиваем ключ расшифровки у отправителя, если он оффлайн - сообщения не видно)
В кеше храним зашифрованную картинку
В час "Икс" перестаём отдавать ключ
От спецслужб и опытных хакеров это не убережёт, но большинство тыжпрограммистов, знающих, как достать данные из кеша, отсечёт.
stardust_kid
29.09.2021 11:24+1Что мешает кешировать ключ вместе с картинкой?
inferrna
29.09.2021 11:32-2Я же говорю, что для спецов это проблемой не будет. Но для рядовых пользователей оф-клиента - вполне. Сейчас, как я понимаю, картинки с интересным содержимым хранятся в папке кеша, куда можно слазить штатным файловым менеджером.
stardust_kid
29.09.2021 13:26+4«Замок от честных воров» — это просто трата времени разработчика на ненужную хрень.
inferrna
29.09.2021 13:38-3Соотнесите % пользователей, которые знают, как достать картинку из кеша с % могущих в кастомный клиент с кешированием ключа. Мне кажется, что первых - каждый первый студент/школьник, вторых же - не каждый студент-айтишник. Фича автоудаляемых сообщений изначально рассчитана на неискушённое в It большинство пользователей, но в текущей реализации это большинство не такое уж большое - вероятность того, что картинка отправленная случайному Васе будет сохранена, что-то около 10% - довольно много. Если уменьшить это значение до 1%, смысла в этой фиче будет больше.
stardust_kid
29.09.2021 14:58+2Даже самый тупой юзер нагуглит, как обойти защиту, чтобы сохранить фотки какой-нибудь горячей фифы для фапа. Это не работа в офисе на дядю, а первичный инстинкт, здесь люди думают и стараются.
Именно поэтому фича с самоуничтожающимися сообщения бесполезна в 100% случаев.
Am0ralist
29.09.2021 15:29+1Вывести на большой экран и сделать скриншот)
vikarti
29.09.2021 18:00getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE);
(в случае андроида)
А дальше либо не выведется на большой экран либо не даст сделать скриншот.
Правда можно сфотографировать. Или собрать клиент без этой фичи.
LaG1924
29.09.2021 13:16Ключ расшифровки - на серверах самого мессенджера, т.к. серверу верить можно (в нем точно не будет злого умысла).
Ещё есть TOTP. Я уверен, что его принципы работы здесь не применимы, но если все же был бы закрытый ключ, который будет действителен только указанное время, то было бы круто.
poige
29.09.2021 11:09+30Лично репортил в телеграм о том, что при звонке mute микрофона по факту не работал, и собеседник всё прекрасно слышал. Проблемой безопасности они это не посчитали. ;)
balamutang
29.09.2021 11:21+24Конфиденциальность любых мессенджеров нарушена всегда.
Пока вы не контролируете сервер и приложения мессенджера (самописного или опенсорсного) - нет никакой конфиденциальности.
Вся вера в конфиденциальность (телеги/вацапа/фейсбука и тд) - это просто вера на слово какому-то богатому парню.
deNULL
29.09.2021 18:47-1Конфиденциальность любых мессенджеров нарушена всегда.
Не всегда всё-таки, end-to-end шифрование вкупе с возможностью проверки соответствия клиентов их исходникам даёт некоторые гарантии конфиденциальности.
solntsepek
29.09.2021 20:35+1::ROFL::
https://www.ixbt.com/news/2021/09/08/facebook-2-whatsapp.html
Новое расследование ProPublica поставило под сомнение политику конфиденциальности Facebook и шифрование платформы обмена сообщениями WhatsApp. В статье освещаются несколько ключевых выводов, которые не раскрываются в явной форме для 2-миллиардной пользовательской базы.
Несмотря на то, что с 2016 года WhatsApp поддерживает сквозное шифрование, в некоторых случаях 1000 контрактных сотрудников, использующих специальное программное обеспечение Facebook, могут читать сообщения, отправленные от одного пользователя другому. Когда кто-то отправляет сообщение, даже в приватном чате, алгоритм ИИ ищет подозрительную активность, связанную с терроризмом, жестоким обращением с детьми и так далее. В случае обнаружения ИИ передаёт полученное сообщение вместе с четырьмя предыдущими сообщениями реальному человеку для рассмотрения.
Затем пользователя можно заблокировать или включить в список наблюдения. Незашифрованные сообщения от пользователей из «проактивного» списка могут быть прочитаны вместе с другими пользовательскими данными, такими как группы пользователей, номер телефона, уникальный идентификатор телефона, сообщение о состоянии подключения, уровень заряда батареи и мощность сигнала.
deNULL
30.09.2021 00:50+3Так это вопрос к конкретной реализации вотсапа.
Насколько я понял, когда кто-то жалуется на сообщения там, их содержимое отправляется на сервер в обход сквозного шифрования. Грубо говоря, кнопка «пожаловаться» эквивалентна «переслать модераторам».
Нет сквозного шифрования — нет конфиденциальности.
vsh797
30.09.2021 11:34Не всегда всё-таки, end-to-end шифрование вкупе с возможностью проверки соответствия клиентов их исходникам даёт некоторые гарантии конфиденциальности.
Интересно, а как ключи для шифрования между устройствами синхронизируются?
deNULL
30.09.2021 12:56По Диффи-Хеллману же
vsh797
30.09.2021 13:28По ссылке.
Предполагается, что злоумышленник может получить оба этих значения, но не модифицировать их (то есть, у него нет возможности вмешаться в процесс передачи).
Если обмен сообщениями происходит через сервера компании, то вмешиваться можно.
Я просто в целом не представляю, как можно производить все общение через единый сервер так, чтобы ему были принципиально недоступны пересылаемые данные.
deNULL
30.09.2021 14:50+1Если обмен сообщениями происходит через сервера компании, то вмешиваться можно.
Вмешаться (то есть модифицировать промежуточные значения A или B) конечно можно, но тогда у сторон получатся разные ключи на выходе (разные значения K), и они не смогут общаться.
Тут важно, что у каждой стороны (клиента) есть какое-то секретное число (a и b соответственно), которое знает только она. Ни сервер, ни другая сторона его не узнает, и повлиять на него не может.
nuclight
30.09.2021 15:54Так они всё равно общаются через тот же сервер, который и будет подставлять им нужное, делов-то.
Здесь можно только вывести отпечаток ключа (как делает телега в виде четырех эмодзи) и сверить его по другому каналу. И то это требует доверия к тому, что скомпилированный клиент выводит именно тот отпечаток, который на самом деле.
deNULL
30.09.2021 16:49Так они всё равно общаются через тот же сервер, который и будет подставлять им нужное, делов-то.
Мой ответ был про невозможность вмешательства в построение ключа — это обеспечивает сам принцип алгоритма. А защиту от того, что это построение произведено именно с собеседником (а не с сервером или ещё какой-то третьей стороной), да, обеспечивает сравнение отпечатков.
И то это требует доверия к тому, что скомпилированный клиент выводит именно тот отпечаток, который на самом деле.
Поэтому я в своем изначальном комменте и упомянул возможность проверки соответствия клиентов их исходникам. Знаю, что как минимум Телеграм такое предлагает: стянуть исходники с Гитхаба, собрать и проверить, что бинарник совпадает с тем, что выложен в магазинах.
При этом, понятно, Телеграм не лучший пример мессенджера со сквозным шифрованием (всё-таки там оно только на секретных чатиках), но, повторюсь, в теории сочетание этих вот факторов некоторые гарантии конфиденциальности таки дает.
nuclight
01.10.2021 00:08+1Вот я не специалист в мобильных интерфейсах, и мне про это "совпадает" всегда было интересно — как обеспечат нераскрытие api_id/api_hash? Ведь его нельзя раскрывать (утечки были, но щас о них не будем). То есть бинарники будут отличаться от официального как минимум в одном месте.
deNULL
01.10.2021 02:24+1Ну что значит «нельзя раскрывать»? Если они вшиты в клиенты (а иначе никак), то уже можно считать, что они всем известны. Выковырять их всегда можно было при должном желании и без всяких утечек. Полагаться на то, что не выковыряют, это security through obscurity.
Как минимум в исходниках Android-клиента они сейчас лежат прямо в открытом виде.
nuclight
04.10.2021 12:48Значит то, что как минимум юридически. Вот умельцы выковыривали/генерировали лицензионные ключи винды еще со времён Windows 95, но пиратом бы никто от этого "можно считать, что они всем известны" быть не перестал, правда?
Как минимум в исходниках Android-клиента они сейчас лежат прямо в открытом виде.
Так это там 4-й api_id, т.е. Public Android Beta — а у официального Distributed Android он 6-й.
Artyomcool
01.10.2021 20:19Сервер может выполнять роль клиента для каждого из клиентов. Т.е. он может честным образом таким же образом обмениваться ключами с каждой стороной. Именно для этого существуют всякие эмоджики, которые сверяются по независимому каналу, чтобы невелировать такую возможность.
TrashboxBobylev
30.09.2021 10:16В интернете её вообще нет, все и так о вас все знают, даже притворяться не надо.
MarkFish
29.09.2021 11:46Помню, когда пошла волна уголовных дел против тех же оппозиционеров, где доказательствами в деле являлись посты из ВК и люди начали выкладывать фото из дела, мягко говоря удивил тот факт, что бывшее детище Паши — ВК, оказывается хранил логи вообще всего.
Да, может изначально никто и не думал, что с ВК получится вот так вот, но в любом случае — для чего в соцсеть изначально был заложен функционал вечного хранения логов?
nidalee
29.09.2021 12:36+14для чего в соцсеть изначально был заложен функционал вечного хранения логов?
Потому что при больших объёмах данных и количестве серверов, данные проще пометить удаленными, чем удалить.
nuclight
30.09.2021 15:55Так-то оно так, но при нормальной работе это со временем приводит к реюзу места, помеченного удалённым — значит, реально должна оставаться лишь часть, и возможно, совсем небольшая.
WortexDaniel
29.09.2021 12:42-4Ну изначально ВК вообще был соц.сетью для местных студентов и только потом вырос до мирового уровня. Плюс, насколько мне известно, ВК под руководством Дурова тоже не всё подряд сохранял и выдавал
Телеграм же изначально был приватным мессенджером для личного использования, а затем вырос.inferrna
29.09.2021 13:44+3В этом плане ВК косплеил фейсбук, который к тому времени уже вышел за рамки только для студентов. Сначала студенты по инвайтам, подогреваем интерес, потом потихоньку все остальные. Тогда вообще в этом плане ралли было, социальные сети создавали все подряд, торопясь ухватить кусок рынка.
alexshy
29.09.2021 12:07"Мы, русские, не обманываем друг друга..."
Похоже, где бы мы ни были, что бы ни делали, у нас в конечном итоге все будет получаться "как всегда". Вопрос только времени. У кого-то сразу, у кого-то немного погодя.
olegryabkov
29.09.2021 12:55+3У меня в telegram не получается очистить контакты глобального поиска. Одноразовые контакты из удаленных переписок при поиске регулярно всплывают. В поддержке на мой вопрос не ответили.
Большие сомнения, что что-то на сервере telegram удаляется.
Polunochnik
29.09.2021 13:31+3не знаю, баг это или фича, однако присутствует такой момент-в семье несколько симок оформлены на одного человека. в том числе моя. когда у кого то из семьи в телеграмме приходит уведомление о том что их контакт появился в телеграмм, это уведомление приходит и мне , хотя контакта этого человека у меня нету. как будто у телеграмма база телефонов синхронизирована с базой владельцев данных номеров из операторов связи (судя по контактам вся наша основная тройка).то есть присутствует автоматический деанон? что скажете господа?
guglovich
29.09.2021 14:20Не расскачиваем лодку, главное эмодзи обновляют, темки тоже :)
А если серьёзно то увы обеспокоен как секьюрный мессенджер, выбранный мною в 2013 только из-за этого, превращается просто в зумерский проект. Такие изъяны как сохранение изображений в секретных чатах, скриншоты и запись как секрет чатов, так и изображений/видео отправленных таймером, продукцией от Эйпл, и вроде как говорят некоторыми андроид телефонами. И казалось бы возможно это не испраивть технически, но предупреждения и уведомления можно сделать, видел как в одном приложении чёрным по белому и было написано что "Телефоны с Root могут делать скриншоты". И помимо этого прикол с подменой автора поста используя Избранное.
И ключевое во всём мною написанном об этом тупо негде сообщить обычному домашнему хомяку, я обычный юзер а не куллхацкер, но я должен выискивать способ связать с саппортом, и также мне как обычному юзеру даже не оставить фидбек что мне не нравится ход развития Телеграмм. Некоторые скажут есть же GP, метрики и пр, приложение берёт популярность, на что я отвечу: 1) Что среди имеющихся мессенджеров это как сказать лучший среди худших; 2) Количественный показатель не всегда объективен учитывая базовую ИТ грамотность людей
Darkhon
29.09.2021 20:15+7Telegram никогда и не являлся каким-то особенно секьюрным мессенджером, особенно с учётом того, что E2E-шифрование чатов в нём опционально. Сравните с Signal, в котором шифрование данных и метаданных всегда было на первом месте. Другой подход изначально.
guglovich
30.09.2021 15:08Касательно реализации вы полностью правы, но я про 2013 год, тогда насколько мне помнится Сигнала не было и в помине. Да и в целом про позиционированию, ту рекламу, хайп, особенно критику Сигнала перед Телеграмом. Но можно отбросить техническую реализацию и вернуться к UX, на уровне UX секьюрность можно было сделать, исправив те проблемы что я перечислил ранее, но, не видно даже стараний, концепт и приоритеты сменились.
trimtomato
29.09.2021 14:43+5Много лет в Телеге сохраняется «фишка» позволяющая мне (пользователю Телеграма) точно знать есть ли мой номер в записной книжке любого другого пользователя Телеги.
Не то чтобы это супер уязвимость, но не очень-то приватно. Можно придумать сценарии эксплуатации.
Как-то я даже отправлял письмо в Телеграм с вопросом нормально ли это, мне никто не ответил.
illusionofchaos
29.09.2021 15:24Нет никаких препятствий к тому, чтобы форкнуть на GitHub код официального клиента для любой платформы и модифицировать его, добавив сохранение автоудаляемых медиа, убрав удаление локальных сообщений и чатов со стороны сервера, а также убрав отправку уведомлений о том, что сделан скриншот. Все это будет работать и с секретными чатами. В iOS, к примеру, на сервер отправляется подпись бинарника, добавляемая App Store. Но модифицированный клиент может отправлять оригинальную подпись, и сервер никак не отличит его от оригинального.
QuAzI
29.09.2021 16:30+4По итогу фича не только не безопасна, но и довольно бесполезна. Удобно было бы отмечать какие-то конкретно сообщения на автоудаление, например т.к. они перестают быть актуальными и могут вызвать бугурт у опоздавших. Или наоборот нужна возможность какие-то значимые сообщения не удалять из автоочищаемого хламовника
Ну а что касается безопасности - её нет, есть цена доступа к данным. Не верь никому и будет тебе счастье)
alliumnsk
29.09.2021 16:49Измените кликбэйтный заголовок, пожалуйста. Я аж испугался, что пароли и переписку могут читать третьи лица. А оказывается, всего лишь фича не работает, которой вообще быть и не должно.
eleoleeye
29.09.2021 17:11+2В телеграмме есть поиск чатов/по чатам, в этом разделе есть подкатегории: ссылки, медиа и тд. Так вот как бы я не чистил кеш в андроиде или в самом телеграмме, из поиска ничего не удаляется и можно найти какие файлы я просматривал и тд. Это очень печально.
denis-isaev
29.09.2021 23:50+1Пфф. Всего несколько месяцев :) Chrome три года не исправлял баг с куками, рассылая SameSite=Strict направо и налево :) А отраслевые издания в это время советовали переходить с csrf токенов на samesite :)
simplix
30.09.2021 00:11+1По части багов разработчики телеграма очень ленивые, мой багрепорт с уведомлениями о присоединении новых контактов при выключенной настройке висит уже давно, исправлять не хотят.
v1000
30.09.2021 08:49Неплохо бы в программы баг баунти добавить пункт о времени реагирования на найденный баг. В том смысле, что если компания не исправляет или не выплачивает вознаграждение за найденный баг, то исследователь может разглашать эту информацию, потому что де-факто компания этим признает, что баг незначительный.
ss-nopol
30.09.2021 12:51+2Договор я не подписал, а в ответном письме отправил вопросы по нему (цитата):
Надо было не замечания к договору писать, а удалить/вычеркнуть пункты по которым не согласен и подписать. Одно дело когда тебе приходит готовый подписанный, но модифицированный договор, а другое дело, когда вопросы и пожелания. Вопросы и пожелания предполагают дополнительную работу, которую никто делать не хочет.
froller
30.09.2021 16:00+1Я вообще перестал понимать откуда у широкой публики такое доверие к Tg?
Не хочу ударяться в конспирологию, но война между государством и корпорацией не может внезапно закончиться без победы одной из сторон. И тот факт, что победителя не называли в СМИ говорит лишь о том, что его имя очевидно. Какие после этого могут быть разговоры о конфиденциальности?ss-nopol
30.09.2021 17:34Телеграм лучше Вацапа тем, что у него хотя бы открытый клиент. Конечно, полностью открытые технологии, как у Матрикс или многочисленных XMPP серверов/клиентов это ещё лучше, но хотя бы так.
nuclight
01.10.2021 00:10+1"Доверие" тут может быть разве что у "совсем широкой" публики, которая во всём этом не разбирается, и даже нижесказанного не осознает. Дело в том, что работает https://ru.wikipedia.org/wiki/Закон_Меткалфа — и выбора попросту нет на практике. Ну, не считая того, чтобы "пользоваться, но не доверять ему ничего важного".
Neznayka_Phalcon_PHP
30.09.2021 18:39-1Павел Дуров позор вам, не цените труды людей.
Человек нашел баг и сообщил об этом в support вашей системе.
Человек этот изначально работал по всем правилам вашей системы, он вовремя понял насколько вы низкие и просите людей согласится с условиями "конфиденциальности" - не раскрывать в СМИ найденные баги.
Я с хохотом посмотрел на компанию которая за баги приготовила выплату в 1000 евро, этот человек который обнаружил баг он озолотится с вашими 1000 евро? - насмешили.
У Павла Дурова один перелет из Дубаи в Египет обходится куда больше чем 1000 евро. Очнитесь люди!
Привыкли людей использовать как стадо, но спасибо тебе человек за найденный баг и за публичные упоминания об этом.
Lambasruchei
05.10.2021 16:59+2Люблю читать, про мочилово телеграма. Почему-то он мне сразу не понравился, нет доверия. И чем дальше, тем больше статей вот таких интересных появляется. И тем больше я радуюсь - "а я же сразу все знал!"
Меня наверно напрягло вот это - телеграм сразу стал успешным проектом, но он до сих пор не монетезируется (или уже монетезируется?). То есть разработчики, на свои деньги содержат проект с многомиллионой аудиторией? Это же бред, какой человек будет выкидывать свои миллионы, вместо того, чтобы наоборот их собирать.
Значит, телеграм приносит денежки владельцам как-то иначе...
SADKO
Телега изначально была и есть подставой, её запреты, промой, и нет ничего удивительного что они не хотят чистить/гадить в кэш, ведь туда в первую очередь заглядывают программно-аппаратные комплексы для изучения телефонов.
Так что енто не баг, а фича, для копов стран где из людей не выбивают показания, а просто подбрасывают ЦП или чего по хуже, если требуется экстрадиция из не дружественной страны.
acc0unt
Я не фанат занимательной конспирологии для детей от 4 годиков. Поэтому спрошу сразу: подтверждение сказанному хоть какое-то есть?
Moskus
Хотя я тоже не фанат занимательной конспирологии, отмечу, что есть встречный вопрос, который с точки зрения риторики задавать куда лучше, чем "какие ваши доказательства". Это вопрос о том, почему, по мнению автора, утверждения о намеренном внесении такого бага, его гипотеза, лучше (более правдоподнобна), чем гипотеза о раздолбайстве и лени, например.
Потому что если требующего доказательств в подобном случае спросить, а какие доказательства его бы реально устроили, очень часто выясняется, что свойства ситуации таковы, что предоставить удовлетворительные доказательства практически невозможно, даже если утверждение - правда. Требуя прямых доказательств, вы себя же, в принципе, ставите в худшее положение.
Revertis
Не стоит искать злой умысел там, где можно объяснить всё обычной глупостью.
Moskus
Это хороший принцип только при условии того, что вы, тем не менее, допускаете возможность злого умысла и готовы объективно её оценивать. Ситуации, где нечто делается умышленно, вполне существуют. Корысть, например, ни чуть не менее реальная причина человеческих действий, чем глупость.
worldmind
Вы думаете что это закон природы или как?
nuclight
Это давно известная http://ru.wikipedia.org/wiki/Бритва_Хэнлона
worldmind
Я не спрашивал про известность, я спрашивал про истинность.
Даже если это утверждение статистически верно, т е истинно в большинстве случаев (хотя и это надо доказать), это не означает истинности в данном конкретном случае.
siziyman
Зайдём с другой стороны: высказывание о наличии умысла и осознанности таких действий - более сильное, чем "так случилось". Более сильное/конкретное высказывание требует больше (более точных) доказательств, чтобы его можно было признать верным. Этих доказательств не привели.
Притом это, конечно, не отменяет того, что Телеграм в данной ситуации ведут себя ну очень непорядочно в моих глазах (особенно с вопросом о вознаграждении).
P.S. То, что версию "они специально гадят" не стоит по умолчанию считать верной, ещё не значит, что не нужно, если вы считаете нужным, действовать самим так, как будто бы они специально гадят. Готовиться к худшему - не то же самое, что считать, что худшее произошло. :)
worldmind
Не хочется тратить время на выяснение того, что по вашему есть более сильное утверждение и как вы сделали вывод, что это утверждение таковое.
Скажу лишь, что я ничего и не доказывал, я лишь утверждал, что шуточные поговорки ничего не доказывают.
siziyman
Утверждение "действие Х было произведено с умыслом, а именно Y" в случае своей истинности даёт больше информации, чем утверждение "действие Х было произведено". Эту разницу в информации из воздуха родить проблемно, доказать её надо.
А никто и не говорил, что они что-то доказывают. Они скорее просто наглядный способ демонстрировать в речи, что делать более сильные утверждения безосновательно - ну, несколько нелепо.
worldmind
Ничего не понимаю. Есть факт - баг связанный с прайваси. Из доступной информации о нём, только очень длительный процесс исправления и попытка скрыть его существование. И речь идёт о проекте с особым акцентом на приватность и безопасность.
Мы конечно не знаем ничего о том как он был добавлен, но при таких вводных обе версии выглядят вполне вероятными.
Хотя, очевидно, что из тысячи случайно выбранных багов в случайно выбранных проектах, абсолютное большинство будет непреднамеренными, но у нас речь о конкретном случае.
worldmind
Может ведь оказаться, что и https://habr.com/ru/post/472970/ не плохокод олимпиадников, а сознательная обфускация.
nuclight
Может. Хотя я всё-таки работал по безопасности, и вероятность этого (обфускации) для разных частей оцениваю по-разному.
nuclight
"Истинность" в плане "законов природы" к подобным вещам вообще неприменима. Более того, здесь явная путаница про "данный конкретный случай" между собственно бритвой и утверждениями "тут истинна глупость" vs "тут истинен умысел" — формулировка бритвы не про это и не утверждает ни то, ни другое.
RTFM13
Раздолбайство и глупость одних (даже если они имеют место) не исключают злой умысел других.
Презумпция виновности (презумпция умысла) для заинтересованных лиц в ряде случаев вполне оправдана и практикуется в юриспруденции.
erty3
Раздолбайством и ленью можно объяснить проблемы безопасности в асечке или зуме.
Телега изначально позиционировалась как приложение с ориентацией на безопасность, и раздолбайство в ключевом постулате компании ничуть не приятней звучит, чем злой умысел.
Revertis
А я и не говорил, что это как-то лучше, чем умышленное оставление багов.
Moskus
Ничего, что это был пример одного из вариантов? А вам сразу хочется кого-нибудь обвинить.
leok
Бритва Оккама.
Moskus
А мне ещё тут говорят, что "верующих в науку" не бывает. Ещё как бывает - выучат про бритву и поминают ее где можно и где нельзя. Не в данном случае, но вообще, самое простое объяснение - далеко не всегда верное.
leok
Бритва Оккама не про то, какая гипотеза верная, а про то, какую следует считать рабочей. Вы спросили, чем гипотеза лучше, я ответил - она лучше тем, что она проще.
mammuthus
Как вы определили, что она проще?
leok
С одной стороны у нас хорошо изученное явление человеческой глупости и наличия багов в софте. С другой стороны - сговор спецслужб с создателями телеграма, про который неизвестно ничего, кроме того, что спецслужбы хотели бы его иметь. Первая теория проще, потому что она не требует вообще никаких неустановленных явлений.
Это не значит, что не следует учитывать или изучать вторую гипотезу. Но принимать ее на веру без дополнительных фактов неправильно.
mammuthus
Не совсем понял вашу позицию. Верно ли то, что вы считаете, будто многочисленных фактов сотрудничества властей с производителями софта с целью сбора информации никогда не было?
xenon
Так исследование любого нового явления начинается с того, что оно должно быть отрезано бритвой оккама, так как ему нет достаточных твердых подтверждений (исследование и нужно чтобы их собрать, найти). В общем, в пользу версии, что явления нет говорит и бритва и имеющиеся(отсутствующие) факты. А в пользу версии, что явление есть - только смутное и ненаучное ощущение "попой чую, что-то тут неладное" у исследователя.
И затем, если он не сдается, не пользуется бритвой, старательно работает и имеет немного везения - удача ему улыбается и он получает какие-то слабенькие и немного сомнительные доказательства, которые уже могут убеждать чуть сильнее и дальше привести к более надежным доказательствам.
nuclight
… или попадает в дурку с паранойей.
SlimShaggy
Хэнлона же
z0ic
В любом отделе СК или МВД есть маленькая комната с компьютерами, там вам всё расскажут и покажут. Это не конспирология, а статистика использования, уж больно часто информация из телеграмма фигурирует в качестве вещественных доказательств.
mrBarabas
Достоверно знаю о том, что все известные мне случаи (выборка очень маленькая если что, но другой информации у меня нет) фигурирования информации из ТГ объясняются добровольно-принудительной передачей этой информации непосредственно участниками чатов. Происходит это примерно так (со слов очевидца) приходят дяди в погонах и говорят что посадят (и есть за что зачастую или просто «на понт» берут), но могут на это закрыть глаза или человек отделается штрафом, и человек соглашается и люди в погонах просят взамен доступ к ТГ и т.п. и полное взаимодействие. Но я полагаю, что все же могут быть и технические способы, о которых стараются молчать или использовать только тогда, когда «стандартные» способы не работают (а они судя по всему работают в 90% случаев) и риск раскрыть эти способы оправдан, то есть, это очень редкоиспользуемые способы. А если вспомнить фильм Игра в имитацию, то вполне возможно что не все так просто - но домыслы, это конспирология, до тех пор, пока не будут найдены доказательства, но подозревать при этом всегда разумно, потому что все забывают, что гораздо раньше принципов обоих «бритв» использовали принцип «кому выгодно» и тут оказывается, что вполне выгодно это ТГ (доверяют люди - большая аудитория, а раз имеются секретные функции - значит будут скрывать переписку с «секретаршей от жены» и имея такую информацию можно ее использовать против участников этой информации, а раз монетизация проекта мутная, а расходы большие, то есть вопросы). В общем, понятно, что кто во что верит, тот о том и говорит…
Norno
А знаете, бываешь проще (пример из жизни родственников, там, правда, в качестве свидетеля), приходят с обыском и конфискацией, и говорят, еще мы забираем телефон на непонятно сколько, или вы его разблокируете для нас, и мы вам его вернем через неделю. И человек может согласиться, он не виноват, скрывать ему нечего, а с телефоном расставаться не хочется. Понятно что ни через неделю, ни через месяц, и даже год, телефон ему никто не вернул, но он сам дал к нему доступ.