Comments 203
Телега изначально была и есть подставой, её запреты, промой, и нет ничего удивительного что они не хотят чистить/гадить в кэш, ведь туда в первую очередь заглядывают программно-аппаратные комплексы для изучения телефонов.
Так что енто не баг, а фича, для копов стран где из людей не выбивают показания, а просто подбрасывают ЦП или чего по хуже, если требуется экстрадиция из не дружественной страны.
Я не фанат занимательной конспирологии для детей от 4 годиков. Поэтому спрошу сразу: подтверждение сказанному хоть какое-то есть?
Хотя я тоже не фанат занимательной конспирологии, отмечу, что есть встречный вопрос, который с точки зрения риторики задавать куда лучше, чем "какие ваши доказательства". Это вопрос о том, почему, по мнению автора, утверждения о намеренном внесении такого бага, его гипотеза, лучше (более правдоподнобна), чем гипотеза о раздолбайстве и лени, например.
Потому что если требующего доказательств в подобном случае спросить, а какие доказательства его бы реально устроили, очень часто выясняется, что свойства ситуации таковы, что предоставить удовлетворительные доказательства практически невозможно, даже если утверждение - правда. Требуя прямых доказательств, вы себя же, в принципе, ставите в худшее положение.
Не стоит искать злой умысел там, где можно объяснить всё обычной глупостью.
Это хороший принцип только при условии того, что вы, тем не менее, допускаете возможность злого умысла и готовы объективно её оценивать. Ситуации, где нечто делается умышленно, вполне существуют. Корысть, например, ни чуть не менее реальная причина человеческих действий, чем глупость.
Вы думаете что это закон природы или как?
Это давно известная http://ru.wikipedia.org/wiki/Бритва_Хэнлона
Я не спрашивал про известность, я спрашивал про истинность.
Даже если это утверждение статистически верно, т е истинно в большинстве случаев (хотя и это надо доказать), это не означает истинности в данном конкретном случае.
Зайдём с другой стороны: высказывание о наличии умысла и осознанности таких действий - более сильное, чем "так случилось". Более сильное/конкретное высказывание требует больше (более точных) доказательств, чтобы его можно было признать верным. Этих доказательств не привели.
Притом это, конечно, не отменяет того, что Телеграм в данной ситуации ведут себя ну очень непорядочно в моих глазах (особенно с вопросом о вознаграждении).
P.S. То, что версию "они специально гадят" не стоит по умолчанию считать верной, ещё не значит, что не нужно, если вы считаете нужным, действовать самим так, как будто бы они специально гадят. Готовиться к худшему - не то же самое, что считать, что худшее произошло. :)
Не хочется тратить время на выяснение того, что по вашему есть более сильное утверждение и как вы сделали вывод, что это утверждение таковое.
Скажу лишь, что я ничего и не доказывал, я лишь утверждал, что шуточные поговорки ничего не доказывают.
Утверждение "действие Х было произведено с умыслом, а именно Y" в случае своей истинности даёт больше информации, чем утверждение "действие Х было произведено". Эту разницу в информации из воздуха родить проблемно, доказать её надо.
А никто и не говорил, что они что-то доказывают. Они скорее просто наглядный способ демонстрировать в речи, что делать более сильные утверждения безосновательно - ну, несколько нелепо.
Ничего не понимаю. Есть факт - баг связанный с прайваси. Из доступной информации о нём, только очень длительный процесс исправления и попытка скрыть его существование. И речь идёт о проекте с особым акцентом на приватность и безопасность.
Мы конечно не знаем ничего о том как он был добавлен, но при таких вводных обе версии выглядят вполне вероятными.
Хотя, очевидно, что из тысячи случайно выбранных багов в случайно выбранных проектах, абсолютное большинство будет непреднамеренными, но у нас речь о конкретном случае.
Может ведь оказаться, что и https://habr.com/ru/post/472970/ не плохокод олимпиадников, а сознательная обфускация.
"Истинность" в плане "законов природы" к подобным вещам вообще неприменима. Более того, здесь явная путаница про "данный конкретный случай" между собственно бритвой и утверждениями "тут истинна глупость" vs "тут истинен умысел" — формулировка бритвы не про это и не утверждает ни то, ни другое.
Раздолбайство и глупость одних (даже если они имеют место) не исключают злой умысел других.
Презумпция виновности (презумпция умысла) для заинтересованных лиц в ряде случаев вполне оправдана и практикуется в юриспруденции.
Раздолбайством и ленью можно объяснить проблемы безопасности в асечке или зуме.
Телега изначально позиционировалась как приложение с ориентацией на безопасность, и раздолбайство в ключевом постулате компании ничуть не приятней звучит, чем злой умысел.
Бритва Оккама.
А мне ещё тут говорят, что "верующих в науку" не бывает. Ещё как бывает - выучат про бритву и поминают ее где можно и где нельзя. Не в данном случае, но вообще, самое простое объяснение - далеко не всегда верное.
Бритва Оккама не про то, какая гипотеза верная, а про то, какую следует считать рабочей. Вы спросили, чем гипотеза лучше, я ответил - она лучше тем, что она проще.
С одной стороны у нас хорошо изученное явление человеческой глупости и наличия багов в софте. С другой стороны - сговор спецслужб с создателями телеграма, про который неизвестно ничего, кроме того, что спецслужбы хотели бы его иметь. Первая теория проще, потому что она не требует вообще никаких неустановленных явлений.
Это не значит, что не следует учитывать или изучать вторую гипотезу. Но принимать ее на веру без дополнительных фактов неправильно.
Так исследование любого нового явления начинается с того, что оно должно быть отрезано бритвой оккама, так как ему нет достаточных твердых подтверждений (исследование и нужно чтобы их собрать, найти). В общем, в пользу версии, что явления нет говорит и бритва и имеющиеся(отсутствующие) факты. А в пользу версии, что явление есть - только смутное и ненаучное ощущение "попой чую, что-то тут неладное" у исследователя.
И затем, если он не сдается, не пользуется бритвой, старательно работает и имеет немного везения - удача ему улыбается и он получает какие-то слабенькие и немного сомнительные доказательства, которые уже могут убеждать чуть сильнее и дальше привести к более надежным доказательствам.
Хэнлона же
В любом отделе СК или МВД есть маленькая комната с компьютерами, там вам всё расскажут и покажут. Это не конспирология, а статистика использования, уж больно часто информация из телеграмма фигурирует в качестве вещественных доказательств.
Достоверно знаю о том, что все известные мне случаи (выборка очень маленькая если что, но другой информации у меня нет) фигурирования информации из ТГ объясняются добровольно-принудительной передачей этой информации непосредственно участниками чатов. Происходит это примерно так (со слов очевидца) приходят дяди в погонах и говорят что посадят (и есть за что зачастую или просто «на понт» берут), но могут на это закрыть глаза или человек отделается штрафом, и человек соглашается и люди в погонах просят взамен доступ к ТГ и т.п. и полное взаимодействие. Но я полагаю, что все же могут быть и технические способы, о которых стараются молчать или использовать только тогда, когда «стандартные» способы не работают (а они судя по всему работают в 90% случаев) и риск раскрыть эти способы оправдан, то есть, это очень редкоиспользуемые способы. А если вспомнить фильм Игра в имитацию, то вполне возможно что не все так просто - но домыслы, это конспирология, до тех пор, пока не будут найдены доказательства, но подозревать при этом всегда разумно, потому что все забывают, что гораздо раньше принципов обоих «бритв» использовали принцип «кому выгодно» и тут оказывается, что вполне выгодно это ТГ (доверяют люди - большая аудитория, а раз имеются секретные функции - значит будут скрывать переписку с «секретаршей от жены» и имея такую информацию можно ее использовать против участников этой информации, а раз монетизация проекта мутная, а расходы большие, то есть вопросы). В общем, понятно, что кто во что верит, тот о том и говорит…
А знаете, бываешь проще (пример из жизни родственников, там, правда, в качестве свидетеля), приходят с обыском и конфискацией, и говорят, еще мы забираем телефон на непонятно сколько, или вы его разблокируете для нас, и мы вам его вернем через неделю. И человек может согласиться, он не виноват, скрывать ему нечего, а с телефоном расставаться не хочется. Понятно что ни через неделю, ни через месяц, и даже год, телефон ему никто не вернул, но он сам дал к нему доступ.
Поэтому спрошу сразу: подтверждение сказанному хоть какое-то есть?
Да, прецеденты потихоньку всплывают.
Почему у многих такая беда с обратной связью и короной на голове?! Ведь корона не упадёт, если общаться с людьми с человеческим лицом, а не с чинушьим.
И как только попадается ситуация, выходящая за пределы прописанных интерфейсов, компания не может корректно обработать подобный случай, и начинается лютейший неадекват.
Проблема по-видимому не имеет решения, ведь чтобы её решить, нужно очень сильно поднимать расходы. Проще смириться с тем, что время от времени система будет выдавать Fatal Error, и придумать методы снижения финансового ущерба от подобных факапов.
Грамотная эскалация на высшие уровни менеджмента должна эту проблему решать.
Это понятно, что нельзя объять необъятное. И можно даже с чем-то мириться. Только при этом надо быть честным и не обещать то, чего нет. А говорить, что все врут, и мы как-то плохо…
Но бывает часто, что дело не в ресурсах даже. Просто не хотят и нет ответственного человека. А на самом деле поправить ничего не стоит.
А еще часто в компаниях решение багов дело неблагодарное, и повышения закрытием багов не добьёшься. Поэтому проще сделать вид, что багов нет. А когда опубликуют какой-нибудь баг в паблик, потом это уже становится приоритетом для бизнеса, и тогда — наконец-то — можно решать и не бояться за KPI.
Если сервис заявляет, что у него есть такая-то функция, но есть баг и про этот баг напишет 1000 человек, то надо всем ответить. При этом никто не мешает все 1000 обращений объединить в один кейс.
Я давно как-то думал, про какую-то систему с "деньгами" (очками) или "кармой". Если обращения человека в саппорт "по делу" (показывают его квалификацию, указывают на реальные проблемы) - его карма или счет растет. Если ему в самом деле помогает совет "перегрузите компьютер" - то падает. У любого хорошего спеца она будет скакать (все мы тупим иногда), но в целом расти. И вместо полумиллиарда пользователей останется 50 000, к сообщениям которых надо отнестись очень внимательно.
Взгляните пожалуйста на Google.
Какая у них аудитория?
А ведь у них ещё и доходы не в пример Telegram.
При этом зачастую даже в сервисах непосредственно связанных с деньгами - том же ads.google при малейших проблемах тебя отправят читать справку и на этом их полномочия всё.
Про поддержку же Google в целом, разве что анекдоты не ходят.
Про поддержку же Google в целом, разве что анекдоты не ходят.Плохо. Надо исправлять. Может, тогда зашевелятся, потому что это уже станет вопросом репутации в массах. Это разница между «я знаю, ты знаешь, он знает» и «все знают и все знают, что все знают». И анекдоты — как раз признак и способ показать всем, что «все знают».
Надо исправлять - а кому "надо"? У гугла краеугольный камень их бизнес-модели состоит в том, что у них нет поддержки и расходы на нее ноль целых ноль десятых. Дизайн их продуктов в целом и такие особенности как глубокая провязка любого продукта с подробной документацией - всё продиктовано отсутствием поддержки.
А как их репутация влияет на их бизнес? Монополисты же.
Спасибо за интересную статью.
иногда эксплуатировал баг, чтобы восстановить данные, которые пользователи считали уничтоженными имея веру в TelegramТолько, наверное, не в Telegram, а в конкретную реализацию его у собеседника?
Потому что ничто не мешает добавить поддержку Telegram, скажем, в Miranda NG, которая вообще ничего не знает ни про какое удаление или изменение сообщений в своей локальной базе по команде протокола. Да, это нарушение ToS Telegram, но если я такое напишу сугубо для себя, кто об этом узнает?
Ну или банально — дописать в родной клиент функцию, которая будет делать скриншоты каждого сообщения.
Всё это удаление сообщений (чатов целиком и отдельных сообщений) держится лишь на том, что мы верим в то, что клиент собеседника это умеет и выполнит. То есть, верить этому нельзя и стоит сразу предполагать, что переписка сохранена на той стороне, независимо от нашего желания. А на своей стороне теперь известно, что стоит чистить кэш.
Такая же ситуация и с сохранением этой переписки на сервере. Он пользователю неподконтролен, проверить, удалилось ли там что-то реально — невозможно.
Потому что это официальный клиент?
Есть сервис и сервера Телеграм, есть официальные клиенты - Telegram и Telegram X, и есть все остальное, совместимое. Насколько велика совместимость это вопрос.
Телега многовато о себе думает в плане этого договора, но автор существенно переборщил с пафосом про нарушение конфиденциальности и угрозу пользователям.
автор существенно переборщил с пафосом про нарушение конфиденциальности и угрозу пользователям.
Я исходил от подобного: CVE-2019-16248
Кроме как грозить, ничего не остаётся.
Но по здравому размышлению автор статьи все-таки прав, неудаление фото на телефоне отправителя — вот это точно уязвимость и угроза пользователям.
Но по здравому размышлению автор статьи все-таки прав, неудаление фото на телефоне отправителя — вот это точно уязвимость и угроза пользователям.Достать удалённый файл тоже можно. С ограничениями, т.к. это не HDD, но можно. Впрочем, от незатейливого атакующего, который ограничится просмотром существующих файлов, обычное стирание файла поможет. В конце концов, если заявляется удаление переписки, то надо удалять всё её содержимое, тут я согласен — это недоработка Telegram.
вообще может сделать Telegram, кроме как грозить отключить от сервиса сторонние клиентыК примеру, переименовать авто-удаление в «Попросить программу собеседника всё удалить». Будет очевидно какой «друг» это сделает, а какой — нет.
Будет очевидно какой «друг» это сделает, а какой — нет.
А это как? Как узнаете удалили или не удалили?
А как из доверия следует "сделает"/"не сделает"?
Какая-та наивность есть в вашем посте. Ведь вы написали: "Попросить программу собеседника всё удалить".
Попросили. Программа ответила "Хорошо, все удалено". И что??? Откуда вам знать, удалено ли все на самом деле или нет? Во первых программа может врать. Во вторых, даже если и не врет, то в ней может быть баг и на самом деле файлы были не удалены. А если все таки все удалила, нет никаких гарантии что нет копии. Они могут существовать несмотря на том знает об этом программа (владелец программы) или нет.
А есть где-то пригодное к реализации описание протокола WhatsApp? Или они его меняют постоянно? Летом возникала мысль — попробовать разобрать то, как общается веб-версия, но не силён в JavaScript и его деобфускации.
Да можно банально, сказать OneDrive/GDisk/YaDisk бэкапить "/Storage/Emulated/0/Telegram/*" в облачное хранилище по расписанию, и всё - вместо удаления картинок получим тыкву. Так что критичность бага всё же несколько преувеличена...
При чём тут вообще данная статья?
Если говорить о намеренном сохранении вашей переписки, то можно записать экран и всё, ничего не поможет.
Только к багу это не имеет никакого отношения. Если собеседник намеренно не сохранял вашу переписку - она должна была удалиться, но не удалялась. Не надо выдумывать миллион других вариантов, баг от этого не пропадёт.
Ещё раз - я не отрицаю наличие бага, я просто указываю на преувеличенность оценки его критичности - тут скорее не нарушение приватности, а "течёт локальный кэш картинок", что тоже неприятно (хранилище не резиновое), но к собственно приватности отношение имеет куда менее сильное.
У нас в фирме, например, почти все пользователи синхронизируют кэш картинок WhatsApp и Telegram в корпоративный OneDrive - в первую очередь из-за того, что картинки из переписок WhatsApp имеют противную тенденцию переставать открываться по прошествии некоторого времени, если запускались встроенные в систему инструменты очистки временных файлов (а служебные смартфоны имеют довольно скромные характеристики, и при активном обмене служебными "фотоотчётами", забиваются весьма быстро), да и доступ с рабочего места к архиву картинок в OneDrive обычно более быстрый, чем через десктопные клиенты.
В WhatsApp разве можно обмениваться картинками (документами)? Он же их все пережимает до непотребного размера?
Большинство пользователей, услышав про автоматический бэкап кеша изображений в облако будут выглядеть примерно так:
Так что когда простые пользователи случайно отправляют не ту картинку и удаляют - она действительно удаляется, а если нет, то это серьёзная проблема. А вдруг у него потом будут проблемы из-за этой картинки, которую ему по ошибке отправили ночью и сразу удалили, а он её даже не видел и даже не смог бы задуматься об очистке кэша?
В рамках работы клиента телеги данный баг есть и для клиента телеги это критичный баг. А нюансы безопасности Android и прочего стороннего окружения авторы телеги не со своей стороны решать должны — это должен андроид обеспечивать.
Более того, удаление чата вас на спасёт, если телефон вашего собеседника уже захватили злоумышленники и отключили его от сети. Так что все эти удаления — это театр чистой воды.
А какой смысл в том, чтобы скринить сообщения? Это должен настраивать получатель, а ему-то это зачем? Они и так эти сообщения видел и читал. Удаление нужно для того, чтобы третье лицо, получившее доступ к телефону, не получило доступ к истории переписки, и больше ни для чего.
И для того, чтобы получатель не мог показать третьему лицу эти сообщения. Проскакивала же история, когда нечистоплотный мальчик пытался поссорить друга с его половинкой удалив половину сообщений так, чтобы оставшаяся выглядела изменой.
Ну типа
1. Пап, можно я возьму 5к с друзьями погулять
2. Нет.
3. Ты сейчас что делаешь, футбол смотришь?
4. Да.Удаляем 2, 3
Мам, дай 5к, папа разрешил, смотри:
1. Пап, можно я возьму 5к с друзьями погулять
4. Да.
Дико бесят люди-снежинки, неспособные отвечать за свои слова и удаляющие свои сообщения. И Телеграм - тем, что потакает им, добавляя всё новую псевдоприватность, анимированные стикеры, шкурки для чатов и прочее-прочее-прочее, чтобы нравиться всё более и более широким массам.
Очень давно уже нахожусь в поисках клиента, который позволял бы по желанию включать/отключать "функции для снежинок". Если уж даже для проприетарного VK сделали VK Coffee, то для Телеграма, с учётом открытости кода, работы - всего ничего. Вопрос - такие клиенты есть, и о них просто не распространяется в силу запрещённости такого рода модификаций, или правда никто не сделал?
А так - способы сохранять в неизменном виде историю как обычных, так и приватных чатов, есть, ведь то, что ты послал клиенту, уже не твоё, и распоряжаться он этим может так, как хочет. Просто это неудобно, когда у тебя история не в приложеньке с поиском, а лежит логом на диске.
Джва года "пишу" такой клиент (сырые логи в CBOR давно уже валятся на диск, конечно), но кроме юридического запрета в ToS телеги, упираюсь в техническую проблему проектирования базы. Ведь схема данных телеги постоянно меняется, а требование работы клиента у конечного простого юзера сводит выбор ровно к одной базе — SQLite. Но поскольку нужно хранить исторические данные, в том числе версии редактированных сообщений, нужно предусмотреть как диффы для экономии места, даже для не-сообщений, так и каким-то образом сделать по этому добру индексы для поиска (а еще бы желательно предусмотреть поддержку других похожих протоколов, не только телеги) — а как, если оно постоянно меняется? Что делать с NOT NULL? И т.д.
Просто свалить в JSON — ничем не будет отличаться от логов на диске по сути.
В "обычном" IT такую задачу решают примерно никогда потому что в норме схема базы под контролем, и к ней еще и администратор приставлен.
проприетарного VK сделали VK Coffee, то для Телеграма, с учётом открытости кода, работы
Так ведь всё равно наоборот. API VK довольно-таки несложный, открыт и сравнительно хорошо документирован. В то время, как протокол телеги сущий ужас, документация на API неполна, обновляется редко — это реверс-инжиниринг во многом практически, пусть и по коду открытых клиентов, но оного реально МНОГО. Поэтому все альтернативные клиенты телеги обычно заканчиваются на не очень большой либе, которая позволяет делать произвольные запросы — читай, только ботов.
Специально, чтобы было именно так, в телеге делают им подконтрольный tdlib, который берёт на себя базу и протокол — соответственно, и не хранит "по протухшей схеме", и не-удалять из базы он не даст.
но кроме юридического запрета в ToS телеги, упираюсь в техническую проблему проектирования базы
Мы (в Miranda NG) тоже в это неизбежно упрёмся, если таки найдётся время и силы прикрутить tdlib. Поскольку протокол это просто транспорт, он ничего не знает, как там хранятся сообщения в базе, это не его дело. За базу отвечает отдельный плагин (а он, в свою очередь, ничего не знает о протоколах, его дело — работать с базой определенного формата, в нашем случае — SQLite). И поддержки изменения существующих событий тупо нет (архитектура приложения закладывалась 20 лет назад, когда ни о каких редактированиях и серверной истории никто не помышлял), поэтому изменённое сообщение расценивается как новое сообщение и кладётся в базу отдельно.
А как у вас сейчас сделано в хранилище с разными протоколами и поиском/индексами? Только самые общие поля типа "кто", но без "где" ?
поэтому изменённое сообщение расценивается как новое сообщение и кладётся в базу отдельно.
Вообще-то, это плюс (и не только для сообщений, но и для других объектов, например, показывать имя/аватар юзера на тот исторический момент), я так и хочу сделать, чтобы иметь историю редактирований, это сугубо в интерфейсе их объединять надо — и разве что подумать насчет DoS частыми редактированиями.
Зачем изобретать велосипед с собственным хранилищем?
Ну прежде всего затем, что я хочу применить это не только для телеги, а и для других подобных протоколов, хоть того же 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 (сработает только до рестарта клиента) — очень простые, без серьезных изменений.
Дико бесят люди-снежинки, неспособные отвечать за свои слова и удаляющие свои сообщения.Да при чём тут снежинки. Вот мои последние случаи, когда требовалось удалить:
— промахнулся чатом, запостил картинку не туда
— промахнулся картинкой, отправил человеку два одинаковых скриншота подряд, а собирался два разных
— подруга скинула пароль от онлайн-аккаунта, я им воспользовался и стёр на обеих сторонах, зачем его хранить?
Это для меня возможность быстро поправить ошибку. Как и редактирование сообщений, когда я сначала быстро пишу, а затем после отправки замечаю, что написал слово с ошибкой. Не будь возможности что-то поменять, пришлось бы выбирать: либо позволить собеседнику усомниться в моей грамотности, либо писать второе сообщение, с исправлением ошибки. Оба варианта такие себе.
— промахнулся чатом, запостил картинку не туда
— промахнулся картинкой, отправил человеку два одинаковых скриншота подряд, а собирался два разных
Решаются разрешением на удаление у обеих сторон только при условии что вторая сторона не прочла. Ибо если вторая сторона уже прочла — удалять немного поздно. Можно оставить небольшой таймаут (1 минута) после отметки о прочтении, что позволит удалить левую картинку из общей группы, но не позволит фабриковать переписку вычищая сообщения за последние сутки не только у себя, но и у собеседника.
Можно попробовать найти компромисс для обеих сторон: сторона которая не желает, чтобы их переписка была сохранена и другая сторона, которая не желает чтобы переписка была/казалась сфабрикованной.
После удаления сообщений, на это место помещать плашку: "сообщение удалено/дата"
Так реализовано, например, в element.
Не эффективно для случаев когда один пользователь хочет напомнить другому что "ты же говорил" или пожаловаться на слова пользователя (за те же домогательства к несовершеннолетним например), а вместо пруфов "сообщение удалено" и ушедший в отказ отправитель "не было такого, там тортики обсуждали".
Если сообщение уже прочитано и истек отведенный (короткий) интервал на осознание что "отправлено что-то не то, надо удалить" - имхо удалять задним числом уже не стоит. Как минимум у прочитавшего и осознавшего получателя. Ибо в основном так делают с мутными либо мошенническими целями.
Исключение - секретные чаты с самоуничтожением, в которых сразу явно плашкой указано обеим сторонам что переписка будет уничтожена. Там получатель в курсе что "или скринь, или значимое не обсуждай", а отправитель в курсе если его скринят.
Это тоже заблуждение. Да, ключ там был, и даже распознавался, но на многих дисковводах можно было прямыми командами принудительно записать или стереть что угодно. Аналогичное потом было и у SD карточек - флаг "пользователь не хотел-бы чтобы что-то изменялось", а вот решать смотреть на этот флаг или нет - дело софтовое. Очень много картридеров даже соответствующего контакта для детекции этого флажка не имела)
Таки да, флажок на полноразмерной SD карте, который выглядел наподобие DIP выключателя, на самом деле не подключался электрически к микросхеме и не запрещал запись на аппаратном уровне. Это просто кусок пластика перекрывающий окно, так же как вырез или окошко на дискетах.
Про дисководы с погнутым сенсором окна защиты от записи ещё в школе узнал. Про SD - ещё когда люто-китайский ридер сумел на мою флэшку 256МБ с cureit, "защищённую от записи", записать "автораннер", но вот зато была у меня USB-флэшка Transcend, правда всего на 32 МБ, с реальным переключателем RW/RO...
Защита на дискетах вполне себе существовала и была весьма эффективна. Помойму Бачило рассказывал о вариантах такой защиты. Да и на хабре что-то проскакивало.
UPD:
Простите, но я вот что-то не понял о какой вере вы говорите. Человек написал мне, а потом удалил своё сообщение. В это не нужно верить, сообщение из беседы удалено. Всё, я его не вижу.
Обещанную награду от Telegram ни в 1000 евро ни какую другую я не получил.
Зато сколько пафоса от руководства компании, в т.ч. лично его руководителя, в части заботе о пользователях, конфиденциальности и всё такое.
Судя по тому, что я о подобном читаю с регулярной периодичностью, складывается такое впечатление, что крупные фирмы из-за неумения или нежелания выстроить бюрократический механизм в части обеспечения безопасности (да, баги к этому относятся, так как априори неизвестно как найденные дыры можно использовать) и какой-то что ли жадности сами создают предпосылки для того, что складывается ощущение, что лучше продать баг на рынке, чем обращаться по баунти. Парадокс в том, что на этот путь толкают даже тех, кто хочет искренне улучшить продукт, так как складывается впечатление, что легальные механизмы работают чуть больше, чем никак.
Нередкий пример того, как некомпетентность ключевых исполнителей может привести к крупным, в данном случае репутационным, потерям для бизнеса.
Мне кажется, в данном случае не большой урон репутации будет, но если продолжат в том же духе, то все может быть
средствами ОС или ещё каких 3их приложений
Да без проблем, TDLib и огромное количество библиотек для работы с клиент апи телеграма позволяют сделать это очень быстро и просто
Дело в другом, включу мод параноика: удалил ты компрометирующие сообщения перед митингом, тебя поймали, а в нужной директории остался нужный фсб материал и вот, ты уже участник террористической организации
На самом деле ситуация с тимлидом из Епама в Беларуси показывает, что такое вполне возможно
А не проще прислать вам какую-то нужную картинку уже после задержания и изъятия телефона? Или просто залить, если уж есть доступ к файловой системе.
Эксперт, если надо, подтвердит что там она была всегда.
Хотя, чтобы просто оправдать арест, в таких случаях, вряд ли нужен эксперт. На принтере напечатают, принесут в суд как протокол осмотра. А там и без этих бумажек знают какое решение нужно вынести.
Однако ж, почему-то запариваются со всеми этими «приличиями» — где-то надо картинку найти на телефоне, где-то ее надо хотя бы залить, где-то хотя бы протокол на принтере напечатать. Видимо, психологическое что-то.
Не психологическое, а уголовно-процессуальный кодекс. Нужен он, чтобы уменьшить перегибы "на местах". "Менты" могут действовать не совсем по закону, но только в рамках сговора разных структур, а не по хотелке любого опера. Арест это ж ведь не инициатива одного лишь задержавшего мента. Его должен поддержать следователь, прокурор и потом одобрить судья. Каждому нужно чем-то подтвердить или обосновать свое согласие.
Соотвественно, беспределить можно либо по указке сверху либо в составе довольно крупной ОПГ в которую входят сотрудники разных ведомств (и где решение принимают не рядовые опера, а те, кто над ними) не мешая тем, кто сверху.
Такая организация позволяет полиции (и прочим службам) выполнять не только карательные функции и использовать должность для личного обогащения, но и поддерживать порядок в той или иной мере. И они поддерживают, можете не сомневаться. Даже в весьма отсталых государствах с полицией получается гораздо лучше, чем без нее. А страны СНГ тут далеко не самые отсталые.
Потому и фальсифицировать доказательства будут в установленном порядке;)
Ситуация с тимлидом из Беларуси показывает что силовикам не нужен повод для того чтоб вломиться и застрелить любого. А раз уж до этого дошло, то файлы со схемами бомб дописать на смартфон уже мелочь.
Так что если у вас на дворе диктаторский режим, то телеграмм тут не виноват.
можно попробовать расчитать стоимость подобных багов по формуле
QA salary * QA count / found issues
думаю, что стоимость подобных "бажков" может значительно превышать затребованную сумму с учетом ЗП over 1k €. Поэтому экономически целесообразно серьезнее подходить к программе Bug Bounty.
Дарю забесплатно идею разработчикам мессенджеров, в том числе тг:
Автоудаляемые сообщения и картинки шифруем отдельной парой ключей
При каждом запуске приложения обновляем ключи для такого рода сообщений с сервера (как вариант - запрашиваем ключ расшифровки у отправителя, если он оффлайн - сообщения не видно)
В кеше храним зашифрованную картинку
В час "Икс" перестаём отдавать ключ
От спецслужб и опытных хакеров это не убережёт, но большинство тыжпрограммистов, знающих, как достать данные из кеша, отсечёт.
Я же говорю, что для спецов это проблемой не будет. Но для рядовых пользователей оф-клиента - вполне. Сейчас, как я понимаю, картинки с интересным содержимым хранятся в папке кеша, куда можно слазить штатным файловым менеджером.
Соотнесите % пользователей, которые знают, как достать картинку из кеша с % могущих в кастомный клиент с кешированием ключа. Мне кажется, что первых - каждый первый студент/школьник, вторых же - не каждый студент-айтишник. Фича автоудаляемых сообщений изначально рассчитана на неискушённое в It большинство пользователей, но в текущей реализации это большинство не такое уж большое - вероятность того, что картинка отправленная случайному Васе будет сохранена, что-то около 10% - довольно много. Если уменьшить это значение до 1%, смысла в этой фиче будет больше.
Ну, можно чуть сложнее делать, чтобы каждый раз загружался новый ключ.
Ключ расшифровки - на серверах самого мессенджера, т.к. серверу верить можно (в нем точно не будет злого умысла).
Ещё есть TOTP. Я уверен, что его принципы работы здесь не применимы, но если все же был бы закрытый ключ, который будет действителен только указанное время, то было бы круто.
Лично репортил в телеграм о том, что при звонке mute микрофона по факту не работал, и собеседник всё прекрасно слышал. Проблемой безопасности они это не посчитали. ;)
Конфиденциальность любых мессенджеров нарушена всегда.
Пока вы не контролируете сервер и приложения мессенджера (самописного или опенсорсного) - нет никакой конфиденциальности.
Вся вера в конфиденциальность (телеги/вацапа/фейсбука и тд) - это просто вера на слово какому-то богатому парню.
у которого всё могут отобрать
Конфиденциальность любых мессенджеров нарушена всегда.
Не всегда всё-таки, end-to-end шифрование вкупе с возможностью проверки соответствия клиентов их исходникам даёт некоторые гарантии конфиденциальности.
::ROFL::
https://www.ixbt.com/news/2021/09/08/facebook-2-whatsapp.html
Новое расследование ProPublica поставило под сомнение политику конфиденциальности Facebook и шифрование платформы обмена сообщениями WhatsApp. В статье освещаются несколько ключевых выводов, которые не раскрываются в явной форме для 2-миллиардной пользовательской базы.
Несмотря на то, что с 2016 года WhatsApp поддерживает сквозное шифрование, в некоторых случаях 1000 контрактных сотрудников, использующих специальное программное обеспечение Facebook, могут читать сообщения, отправленные от одного пользователя другому. Когда кто-то отправляет сообщение, даже в приватном чате, алгоритм ИИ ищет подозрительную активность, связанную с терроризмом, жестоким обращением с детьми и так далее. В случае обнаружения ИИ передаёт полученное сообщение вместе с четырьмя предыдущими сообщениями реальному человеку для рассмотрения.
Затем пользователя можно заблокировать или включить в список наблюдения. Незашифрованные сообщения от пользователей из «проактивного» списка могут быть прочитаны вместе с другими пользовательскими данными, такими как группы пользователей, номер телефона, уникальный идентификатор телефона, сообщение о состоянии подключения, уровень заряда батареи и мощность сигнала.
Не всегда всё-таки, end-to-end шифрование вкупе с возможностью проверки соответствия клиентов их исходникам даёт некоторые гарантии конфиденциальности.
Интересно, а как ключи для шифрования между устройствами синхронизируются?
По Диффи-Хеллману же
По ссылке.
Предполагается, что злоумышленник может получить оба этих значения, но не модифицировать их (то есть, у него нет возможности вмешаться в процесс передачи).
Если обмен сообщениями происходит через сервера компании, то вмешиваться можно.
Я просто в целом не представляю, как можно производить все общение через единый сервер так, чтобы ему были принципиально недоступны пересылаемые данные.
Если обмен сообщениями происходит через сервера компании, то вмешиваться можно.
Вмешаться (то есть модифицировать промежуточные значения A или B) конечно можно, но тогда у сторон получатся разные ключи на выходе (разные значения K), и они не смогут общаться.
Тут важно, что у каждой стороны (клиента) есть какое-то секретное число (a и b соответственно), которое знает только она. Ни сервер, ни другая сторона его не узнает, и повлиять на него не может.
Так они всё равно общаются через тот же сервер, который и будет подставлять им нужное, делов-то.
Здесь можно только вывести отпечаток ключа (как делает телега в виде четырех эмодзи) и сверить его по другому каналу. И то это требует доверия к тому, что скомпилированный клиент выводит именно тот отпечаток, который на самом деле.
Так они всё равно общаются через тот же сервер, который и будет подставлять им нужное, делов-то.
Мой ответ был про невозможность вмешательства в построение ключа — это обеспечивает сам принцип алгоритма. А защиту от того, что это построение произведено именно с собеседником (а не с сервером или ещё какой-то третьей стороной), да, обеспечивает сравнение отпечатков.
И то это требует доверия к тому, что скомпилированный клиент выводит именно тот отпечаток, который на самом деле.
Поэтому я в своем изначальном комменте и упомянул возможность проверки соответствия клиентов их исходникам. Знаю, что как минимум Телеграм такое предлагает: стянуть исходники с Гитхаба, собрать и проверить, что бинарник совпадает с тем, что выложен в магазинах.
При этом, понятно, Телеграм не лучший пример мессенджера со сквозным шифрованием (всё-таки там оно только на секретных чатиках), но, повторюсь, в теории сочетание этих вот факторов некоторые гарантии конфиденциальности таки дает.
Вот я не специалист в мобильных интерфейсах, и мне про это "совпадает" всегда было интересно — как обеспечат нераскрытие api_id/api_hash? Ведь его нельзя раскрывать (утечки были, но щас о них не будем). То есть бинарники будут отличаться от официального как минимум в одном месте.
Ну что значит «нельзя раскрывать»? Если они вшиты в клиенты (а иначе никак), то уже можно считать, что они всем известны. Выковырять их всегда можно было при должном желании и без всяких утечек. Полагаться на то, что не выковыряют, это security through obscurity.
Как минимум в исходниках Android-клиента они сейчас лежат прямо в открытом виде.
Значит то, что как минимум юридически. Вот умельцы выковыривали/генерировали лицензионные ключи винды еще со времён Windows 95, но пиратом бы никто от этого "можно считать, что они всем известны" быть не перестал, правда?
Как минимум в исходниках Android-клиента они сейчас лежат прямо в открытом виде.
Так это там 4-й api_id, т.е. Public Android Beta — а у официального Distributed Android он 6-й.
Сервер может выполнять роль клиента для каждого из клиентов. Т.е. он может честным образом таким же образом обмениваться ключами с каждой стороной. Именно для этого существуют всякие эмоджики, которые сверяются по независимому каналу, чтобы невелировать такую возможность.
для чего в соцсеть изначально был заложен функционал вечного хранения логов?
Потому что при больших объёмах данных и количестве серверов, данные проще пометить удаленными, чем удалить.
Ну изначально ВК вообще был соц.сетью для местных студентов и только потом вырос до мирового уровня. Плюс, насколько мне известно, ВК под руководством Дурова тоже не всё подряд сохранял и выдавал
Телеграм же изначально был приватным мессенджером для личного использования, а затем вырос.
"Мы, русские, не обманываем друг друга..."
Похоже, где бы мы ни были, что бы ни делали, у нас в конечном итоге все будет получаться "как всегда". Вопрос только времени. У кого-то сразу, у кого-то немного погодя.
У меня в telegram не получается очистить контакты глобального поиска. Одноразовые контакты из удаленных переписок при поиске регулярно всплывают. В поддержке на мой вопрос не ответили.
Большие сомнения, что что-то на сервере telegram удаляется.
не знаю, баг это или фича, однако присутствует такой момент-в семье несколько симок оформлены на одного человека. в том числе моя. когда у кого то из семьи в телеграмме приходит уведомление о том что их контакт появился в телеграмм, это уведомление приходит и мне , хотя контакта этого человека у меня нету. как будто у телеграмма база телефонов синхронизирована с базой владельцев данных номеров из операторов связи (судя по контактам вся наша основная тройка).то есть присутствует автоматический деанон? что скажете господа?
Не расскачиваем лодку, главное эмодзи обновляют, темки тоже :)
А если серьёзно то увы обеспокоен как секьюрный мессенджер, выбранный мною в 2013 только из-за этого, превращается просто в зумерский проект. Такие изъяны как сохранение изображений в секретных чатах, скриншоты и запись как секрет чатов, так и изображений/видео отправленных таймером, продукцией от Эйпл, и вроде как говорят некоторыми андроид телефонами. И казалось бы возможно это не испраивть технически, но предупреждения и уведомления можно сделать, видел как в одном приложении чёрным по белому и было написано что "Телефоны с Root могут делать скриншоты". И помимо этого прикол с подменой автора поста используя Избранное.
И ключевое во всём мною написанном об этом тупо негде сообщить обычному домашнему хомяку, я обычный юзер а не куллхацкер, но я должен выискивать способ связать с саппортом, и также мне как обычному юзеру даже не оставить фидбек что мне не нравится ход развития Телеграмм. Некоторые скажут есть же GP, метрики и пр, приложение берёт популярность, на что я отвечу: 1) Что среди имеющихся мессенджеров это как сказать лучший среди худших; 2) Количественный показатель не всегда объективен учитывая базовую ИТ грамотность людей
Telegram никогда и не являлся каким-то особенно секьюрным мессенджером, особенно с учётом того, что E2E-шифрование чатов в нём опционально. Сравните с Signal, в котором шифрование данных и метаданных всегда было на первом месте. Другой подход изначально.
Касательно реализации вы полностью правы, но я про 2013 год, тогда насколько мне помнится Сигнала не было и в помине. Да и в целом про позиционированию, ту рекламу, хайп, особенно критику Сигнала перед Телеграмом. Но можно отбросить техническую реализацию и вернуться к UX, на уровне UX секьюрность можно было сделать, исправив те проблемы что я перечислил ранее, но, не видно даже стараний, концепт и приоритеты сменились.
Много лет в Телеге сохраняется «фишка» позволяющая мне (пользователю Телеграма) точно знать есть ли мой номер в записной книжке любого другого пользователя Телеги.
Не то чтобы это супер уязвимость, но не очень-то приватно. Можно придумать сценарии эксплуатации.
Как-то я даже отправлял письмо в Телеграм с вопросом нормально ли это, мне никто не ответил.
Не показывайте автору "уязвимости" это:
Нет никаких препятствий к тому, чтобы форкнуть на GitHub код официального клиента для любой платформы и модифицировать его, добавив сохранение автоудаляемых медиа, убрав удаление локальных сообщений и чатов со стороны сервера, а также убрав отправку уведомлений о том, что сделан скриншот. Все это будет работать и с секретными чатами. В iOS, к примеру, на сервер отправляется подпись бинарника, добавляемая App Store. Но модифицированный клиент может отправлять оригинальную подпись, и сервер никак не отличит его от оригинального.
По итогу фича не только не безопасна, но и довольно бесполезна. Удобно было бы отмечать какие-то конкретно сообщения на автоудаление, например т.к. они перестают быть актуальными и могут вызвать бугурт у опоздавших. Или наоборот нужна возможность какие-то значимые сообщения не удалять из автоочищаемого хламовника
Ну а что касается безопасности - её нет, есть цена доступа к данным. Не верь никому и будет тебе счастье)
Измените кликбэйтный заголовок, пожалуйста. Я аж испугался, что пароли и переписку могут читать третьи лица. А оказывается, всего лишь фича не работает, которой вообще быть и не должно.
В телеграмме есть поиск чатов/по чатам, в этом разделе есть подкатегории: ссылки, медиа и тд. Так вот как бы я не чистил кеш в андроиде или в самом телеграмме, из поиска ничего не удаляется и можно найти какие файлы я просматривал и тд. Это очень печально.
Паша подвёл получается, закрысил 1к евро
Пфф. Всего несколько месяцев :) Chrome три года не исправлял баг с куками, рассылая SameSite=Strict направо и налево :) А отраслевые издания в это время советовали переходить с csrf токенов на samesite :)
Неплохо бы в программы баг баунти добавить пункт о времени реагирования на найденный баг. В том смысле, что если компания не исправляет или не выплачивает вознаграждение за найденный баг, то исследователь может разглашать эту информацию, потому что де-факто компания этим признает, что баг незначительный.
@ne555, а чего вы так с ними церемонились (5 месяцев ожидания, 100500 напоминаний) ?
нашли - опубликовали.... или вас именно награда интересовала ?
Договор я не подписал, а в ответном письме отправил вопросы по нему (цитата):
Надо было не замечания к договору писать, а удалить/вычеркнуть пункты по которым не согласен и подписать. Одно дело когда тебе приходит готовый подписанный, но модифицированный договор, а другое дело, когда вопросы и пожелания. Вопросы и пожелания предполагают дополнительную работу, которую никто делать не хочет.
Я вообще перестал понимать откуда у широкой публики такое доверие к Tg?
Не хочу ударяться в конспирологию, но война между государством и корпорацией не может внезапно закончиться без победы одной из сторон. И тот факт, что победителя не называли в СМИ говорит лишь о том, что его имя очевидно. Какие после этого могут быть разговоры о конфиденциальности?
Телеграм лучше Вацапа тем, что у него хотя бы открытый клиент. Конечно, полностью открытые технологии, как у Матрикс или многочисленных XMPP серверов/клиентов это ещё лучше, но хотя бы так.
"Доверие" тут может быть разве что у "совсем широкой" публики, которая во всём этом не разбирается, и даже нижесказанного не осознает. Дело в том, что работает https://ru.wikipedia.org/wiki/Закон_Меткалфа — и выбора попросту нет на практике. Ну, не считая того, чтобы "пользоваться, но не доверять ему ничего важного".
Павел Дуров позор вам, не цените труды людей.
Человек нашел баг и сообщил об этом в support вашей системе.
Человек этот изначально работал по всем правилам вашей системы, он вовремя понял насколько вы низкие и просите людей согласится с условиями "конфиденциальности" - не раскрывать в СМИ найденные баги.
Я с хохотом посмотрел на компанию которая за баги приготовила выплату в 1000 евро, этот человек который обнаружил баг он озолотится с вашими 1000 евро? - насмешили.
У Павла Дурова один перелет из Дубаи в Египет обходится куда больше чем 1000 евро. Очнитесь люди!
Привыкли людей использовать как стадо, но спасибо тебе человек за найденный баг и за публичные упоминания об этом.
Хотим, чтобы все работало идеально, не заплатив за сервис. Размечтались!!!
Люблю читать, про мочилово телеграма. Почему-то он мне сразу не понравился, нет доверия. И чем дальше, тем больше статей вот таких интересных появляется. И тем больше я радуюсь - "а я же сразу все знал!"
Меня наверно напрягло вот это - телеграм сразу стал успешным проектом, но он до сих пор не монетезируется (или уже монетезируется?). То есть разработчики, на свои деньги содержат проект с многомиллионой аудиторией? Это же бред, какой человек будет выкидывать свои миллионы, вместо того, чтобы наоборот их собирать.
Значит, телеграм приносит денежки владельцам как-то иначе...
Или его спонсируют спецслужбы, например.
Люблю читать, про мочилово телеграма
Возможно, вам зайдет моя предыдущая статья по серым фактам Tg, которую я восстановил из своих закладок.
Конфиденциальность пользователей Telegram снова нарушена. Представители мессенджера требуют не раскрывать подробностей