Facebook испортил жизнь чат-приложениям

Социальная сеть Facebook в новой версии Facebook Messenger дала пользователям возможность использования приложения даже при отсутствии френдования в Facebook: достаточно наличия телефонов собеседников в записной книжке телефона.

Новая политика в отношении юзеров бьёт под дых мессенджерам без бустера в виде «родительской» социальной сети (к которым, разумеется, относится и Telegram Павла Дурова). Помимо этого приложение было доработано и в визуальной части: дизайнеры FB избавились от лишних галочек, используя стиль Windows Phone 8 и фон сообщений для информирования пользователя об его статусе.

С обновлением FB-chat конкурирующие приложения (WhatsApp, Telegram, Snapchat и т. д.) лишаются одного из своих плюсов — возможности расти за счёт отсуствия связности между всеми пользователями Facebook. Более того, они начинают проигрывать Facebook по пользовательской базе (в тех странах, где Facebook не забанен и популярен).

Утешаться можно тем, что для использования клиента FB всё ещё нужна регистрация в Facebook и в остальном техническая кривость чата Facebook не устранена: например, в версии клиента для Android приложение продолжает раздражать пользователей не закрывающимся уведомлением о недоставке сообщений. И, конечно, все те миллиарды пользователей, которые озабочены конфиденциальностью своей переписки, также должны будут предпочесть те приложения, создатели которых громче всего кричат о безопасности своего продукта.

Добавить 17 комментариев

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    Я уже писал и ещё не раз напишу — если бы кому-то было не наплевать на безопасность, мы бы это узнали по исходу всех тех сервисов, которые сдал Сноуден. Исхода не наблюдается. То есть, всем наплевать.

  • Ответить

    > если бы кому-то было не наплевать на безопасность, мы бы это узнали по исходу всех тех сервисов Ну вы прям как маленький. Мгновенного исхода не будет, это вам не атомная бомба над Багдадом, а вот то что есть постоянный отток активности пользователя от gmail и иже с ними — факт.

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    В Facebook тоже можно писать не друзьям. Функция немного в другом: в чате появляются пользователи, с которыми ты не подружился на Facebook, но чьи телефоны есть у тебя в трубке. Ты даже мог не знать о том, что они зарегистрированы в Facebook. Тут, конечно, возможны сюрпризы. Если некий Иван Иваныч Иванов, руководитель сталепрокатного завода, которого ты знал только по номеру телефона, с какими-то целями сделал аккаунт в Фейсбуке с именем Анночка, и имел глупость привязать свой телефон к этому акку, то эта Анночка внезапно вылезет в истории переписки. Но, как говорит великий Сноуден, «who cares?»

  • Ответить
    Eli

    >то эта Анночка внезапно вылезет в истории переписки. Там вылезет именно Анночка, без связи с контактом-Иванычем. Нельзя определить к какому именно контакту привязан этот профиль.

  • Ответить

    > vladon, у telegram нет никакого преймущества в безопасности, только реклама со стороны Дурова. Убеждает хорошо, но ни от чего не спасает. Вы, как я посмотрю, специалист, чтобы подобное утверждать? Или можете привести ссылки на исследования исходного кода?

  • Ответить

    Ну раз просто специалист, то не мог бы он обосновать свои утверждения? Я не говорю, что я специалист, но ничего подозрительного в исходном коде не вижу, сообщения шифруются на стороне клиента. Что у него вызывает сомнения?

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    Отсутствие преимущества означает лишь то, что любой другой клиент может шифроваться не хуже Телеграма (раз) Меры безопасности в отношении передаваемой информации могут быть обойдены и не перехватом трафика, а, например, изготовлением скриншотов экрана зловредным приложением или перехватом клавиатуры (два)

  • Ответить

    > Отсутствие преимущества означает лишь то, что любой другой клиент может шифроваться не хуже Телеграма (раз) Меры безопасности в отношении передаваемой информации могут быть обойдены и не перехватом трафика, а, например, изготовлением скриншотов экрана зловредным приложением или перехватом клавиатуры (два) Ну это допусловия. И перехват трафика исключаем, уверен, что и у фейсбука не перехватишь т.к. https. Но у него сообщения потом хранятся на сервере в открытом для работников и автоанализаторов виде. Переписываться, зная, что все твои сообщения хранятся на серверах в открытом виде и к ним имеет доступ не то что какая-нибудь спецслужба, а обычный работник Фейсбука — ну хз.

  • Ответить

    Ну вообще-то да, специалист, одиннадцать лет опыта и всё такое это гораздо больше чем у вас или у 99% остальных. Судя по описанию протокола там простенькое шифрование, собраное из странноватых компонент и решающее только самые простые задачи, причем нигде не сказано какие именно. От подглядывания в кафе через WiFi спасет, но от этого и SSL/TLS спасает. Проблемы в исходниках могут сделать еще хуже, но не лучше. Вот копипаста с моим беглым анализом. Сообщение шифруется на ключе, порождаемом от фиксированной секретной части и SHA1 от самого сообщения. Коллизии в SHA1 научились делать еще в 2005 году, причем в полном, а не в младших 128 битах. Это не катастрофа, но если найдутся слабости в других уровнях — может получиться неприятность с подменой сообщений без знания ключа. Используется режим шифрования IGE, прямо скажем непопулярный. Придуман он был, чтобы дешево делать аутентификацию сообщений вместе с шифрованием. Вообще, на такие режимы в последние годы принято смотреть косо: в них часто встречаются неприятные дырки. IGE не исключение: некоторые модификации сообщений он отловить не может, и до кучи в описании протокола нигде не сказано, как его свойством аутентификации пользоваться. Ну и зачем было выпендриваться? Хранение ключа на устройстве… Я просто оставлю это здесь: «Для озабоченных безопасностью пользователей можно предлагать защитить авторизационный ключ паролем, примерно так же, как это делает ssh. Для этого к ключу спереди добавляется SHA1 от него, после чего все это шифруется AES в режиме CBC с помощью ключа, равного (текстовому) паролю пользователя.» Это совет по стрельбе себе в ногу. Из огнемета. Выработка ключей тоже необычная: по DH создается общий ключ в 2048 бит, после чего сервер использует из них только 1024, а из оставшихся 512 даже не хранит, «под честное слово» разумеется. И предлагается эти 512 бит использовать для шифрования локальных данных, тогда-де нельзя будет их расшифровать даже расковыряв сервер. А почему просто не взять случайный ключ для локальной копии? А зачем 2048 бит, если используется только половина? А сервер правда ничего лишнего не хранит? А история же хранится на сервере, причем в открытом виде, и что толку в шифровании локальной базы?

  • Ответить
    dil

    vladon> Вы, как я посмотрю, специалист, чтобы подобное утверждать? Или можете привести ссылки на исследования исходного кода? Я не верю в безопасность продукта, придуманного людьми, не видящими разницы между аутентификацией, авторизацией и криптографией: «Криптографическая (авторизационная) прослойка — определяет, каким образом сообщения шифруются перед передачей через транспортный протокол.» http://dev.stel.com/mtproto

  • Ответить
    kotehok Telegram LLC

    К сожалению, никаких конкретных претензий по поводу надёжности протокола и предлагаемых схем шифрования в нескольких комментариях выше не наблюдается. Видимо, знакомство с ними у авторов выше написанных комментариях действительно было слишком уж беглым. Претензии в основном сводятся к «кому-то лично не нравится используемый алгоритм» (правда, неизвестно, почему), «в документации есть одна опечатка, и поэтому я людям не верю» (о ужас!), «чисто теоретически в алгоритме могли бы оказаться дыры» (а могли бы и не оказаться, вообще-то такие утверждения нужно доказывать, сказать так можно про всё, что угодно). Конкретика отсутствует полностью. Кроме того, авторы комментариев совершенно игнорируют тот факт, что помимо облачной схемы (в которой решается, и успешно, одна задача — построение надёжной облачной схемы и надёжной передачи данных между клиентом и сервером) в Telegram есть ещё секретные чаты, решающие другую задачу (надёжность передачи данных от клиента к клиенту, независимо от надёжности сервера), в которых уровень надёжности ещё выше, в силу того, что сообщения, передаваемые через них, чисто теоретически не могут быть ни в каком виде расшифрованы сервером.

  • Ответить
    dil

    > «в документации есть одна опечатка, и поэтому я людям не верю» (о ужас!), Не опечатка, а смешение принципиально разных понятий, что свидетельствует о непонимании их авторами.