dxdt.blog: занимательный интернет-журнал

В марте довольно много писали про новую атаку на SHA-256, “с обнаружением коллизий”. Вообще, тут нужно отделять академические атаки от практики, условно говоря, всяких биткойнов: в исходной работе (“New Records in Collision Attacks on SHA-2”, Li, Liu, Wang) речь идёт про академические атаки на урезанную “функцию сжатия” (см. ниже) из состава SHA-2 (SHA-256 – это разновидность SHA-2), да ещё и со специально подобранным предыдущим состоянием. Это общепринятый подход к исследованию стойкости хеш-функций, результат существенно лучше предыдущих достижений, но нужно учитывать, что он не обязательно приводит к практической атаке на полную хеш-функцию. В статье сказано именно про “практическую атаку”, это верно, однако это разная “практика”.

Возьмём в качестве примера SHA-256 и одну из практических (в академическом смысле) атак, представленных в упомянутой выше работе. Ядром схемы хеш-функции SHA-256 являются преобразования, соответствующие симметричному шифру. Повторно выполняемые раунды преобразований шифра, внутри хеш-функции, и образуют так называемую “функцию сжатия” – это важнейший элемент. Входной текст для преобразования в SHA-256 разбивается на блоки. Блок – это последовательность байтов, соответствующая разрядности функции, здесь – 256 бит или 32 байта. Блоки обрабатываются функцией сжатия, внутри которой выполняется заданное количество раундов – то есть, повторное применение одних и тех же преобразований, в цикле, к обрабатываемому блоку. Далее речь будет идти только про один блок, а не про полный входной текст.

После каждого раунда, блок, в результате применения преобразований, изменяется и потом снова подвергается тем же преобразованиям, которые опять изменяют блок. Эта комбинаторная часть позволяет добиться нужного разрежения для отображения входных блоков в выходные значения. Штатная схема SHA-256 использует 64 раунда в функции сжатия. Атака, о которой идёт речь, работает для 39 раундов (обратите внимание: с подобранным начальным состоянием – это очень важный момент).

Что это означает? Это означает, что исследователи нашли и предъявили кортеж из трёх конкретных значений (чисел или массивов байтов – как хотите), которые, будучи подставленными в урезанную до 39 раундов сжатия версию хеш-функции SHA-256, дают одинаковый результат. Одно из этих значений – это начальное состояние, устанавливаемое перед вызовом функции сжатия внутри урезанной SHA-256. То есть, при штатной реализации SHA-256 – этим состоянием либо был бы предыдущий обработанный блок, либо начальные константы из спецификации SHA-256. Два других упомянутых значения – это различающиеся в некоторых байтах входные блоки. Обработка этих блоков при указанных, весьма строгих, условиях – даёт коллизию. То есть, академическая “практическая” демонстрация, с конкретными числами. Это вполне себе строгий и разумный способ анализа стойкости преобразований. В данной науке это называется SFS-коллизия (от Semi-Free-Start). Но, опять же, очень далеко от демонстрации реальной, практической, “уничтожающей” коллизии SHA-256, то есть, демонстрации двух различных входных текстов, дающих одинаковый результат хеш-функции. (Что, конечно, не отменяет заметного продвижения.)

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

Естественно, обнаружение точек совпадения для уменьшенного количества раундов нередко даёт инструменты для взлома всей хеш-функции целиком. Именно поэтому академические атаки на примитивы с урезанным количеством раундов – важнейший инструмент. Однако, является ли тот факт, что коллизия найдена для более чем половины количества раундов, автоматической гарантией успешного применения того же метода к, предположим, половине оставшейся половины? Нет, совсем не является. Методы тут развиваются, так сказать, полностью “нелинейно”, так что непреодолимое вычислительное препятствие может возникнуть хоть бы и на каждом следующем раунде – потребуется полностью переделать метод атаки. Собственно, это очередное улучшение атак на SHA-2 как раз построено на новых методах, если сравнивать с теми методами, которые использовали для атак на MD5 и пр.

Конкретный пример, взятый из исходной работы: для 39 раундов SHA-256, при заданном начальном состоянии, получаются совпадающие значения для разных входных блоков (выдача программы, прилагаемой к работе):

431cadcd ce6893bb d6c9689a 334854e8 3baae1ab 038a195a ccf54a19 1c40606d
431cadcd ce6893bb d6c9689a 334854e8 3baae1ab 038a195a ccf54a19 1c40606d

Можно было бы предположить, что раз точка совпадения найдена, то и дальнейшие раунды дадут одинаковые результаты. Но это далеко не так – состояние хеш-функции шире, чем конкретный результат преобразования блока. Так, если в той же программе указать 42 раунда (всего на три раунда больше), то значения уже заметно разойдутся:

d33c0cff 17c9de13 21f528f0 3362e217 563f1779 521a1b9c df062e86 19fb5973 
105d6c34 43ceb0ad 120ba1a0 3362e217 d6dd86e0 7da567b5 cf1ca736 19fb5973

Это, ещё раз, никак не уменьшает ценности результата для 39 раундов, но показывает, что для полной SHA-256 всё, – пока что, – хорошо.

Криптографические хеш-функции отображают сообщения произвольной длины в блоки фиксированной длины, так что, математически, коллизии там есть по определению. Другое дело, что если хеш-функция хорошо отображает множество входных текстов в, скажем, 2^256 выходных значений, то о коллизиях “на полном переборе” можно не особенно задумываться: мало кто может создать и записать даже 2^128 текстов. Атаки с обнаружением точек совпадения в функции сжатия как раз, потенциально, выявляют дефекты отображения, которые могут позволить найти коллизии без необходимости полного перебора. А возможно, что и позволят найти способы решения гораздо более сложной задачи вычисления прообраза, – то есть, подбора входного текста по значению хеш-функции.

Касательно свежей истории с обнаружением закладки/бэкдора (CVE-2024-3094) в пакете xz (liblzma), которая на системах с systemd/glibc, потенциально, протягивалась в sshd: понятно, что такого может быть ещё много в уже массово используемых библиотеках, но всё равно это весьма неплохая и практическая демонстрация того, что подобное удаётся быстро обнаружить силами сообщества. По этой теме я не так давно писал, что, во-первых, добавление закладок и прочего вредоносного кода – это совсем не какая-то особенность Open Source; во-вторых – доступность исходников связана с возможностями по добавлению и обнаружению вредоносного кода, но вовсе не так прямо, как часто говорят и пишут.

В продолжение предыдущей записки. Различные “аппаратурные” атаки, типа разновидностей Spectre/Meltdown, которые преодолевают механизмы разграничения доступа современных процессоров, имеют интересную связь с концепцией “диагонализации”: то есть, такие атаки всегда возможны, если только процессор пытается оптимизировать использование вычислительных ресурсов достаточно сложным способом. Под “достаточно сложным” тут подразумевается наличие механизмов вида “предикторов” (упреждающего анализа потока команд), задействованных на уровне над “межпотоковым” взаимодействием.

Вообще, в x86 “префетчинг” (предварительное извлечение) кодов команд появился ещё в микропроцессоре 8086. Но тогда соответствующая схема считалась просто конвейером команд. Это был отдельный компонент, со своими регистрами и системой счётчиков, который асинхронно считывал коды команд с внешней шины, когда та была свободна, что существенно ускоряло работу процессора. Понятно, что в 8086 не было ни каких-то особых механизмов аппаратного разграничения потоков команд и адресного пространства, ни обособленных полноценных ядер, исполняющих код, так что и проблем с побочными эффектами от работы схем конвейера тоже быть ещё не могло. Однако состояние этого конвейера, вмещавшего всего несколько кодов (четыре 8-битных регистра), изменяло состояние процессора вне зависимости от исполняемой основным “протоядром” команды, поскольку конвейер содержал пару указателей, несколько флагов и т.д. Впрочем, технические детали устройства исторического микропроцессора тут не важны – важно, что, во-первых, этот простой конвейер работал только на уровне последовательности кодов команд (не со свойствами самих команд); во-вторых, не было потоков и общих элементов, совместно используемых этими потоками.

Отличие “уязвимых” схем современных процессоров в том, что здесь добавляется новый уровень – те самые “предикторы”, оснащённые логикой, которая учитывает уже не порядок кодов команд, а свойства этих команд и состояние процессора, а кроме того, добавляются общие для нескольких потоков элементы (схемы кэширования и пр.) на работу которых прямо влияют предикторы. И, конечно, возникает аппаратное разграничение доступа, которое и предлагается преодолевать при помощи атак, использующих аппаратные уязвимости.

Базовая логика таких атак – использование “оракулов”, сигналы которых пробивают границы, устанавливаемые (формально) аппаратной архитектурой процессора для фрагментов программного кода. Тут нужно учитывать, что границы эти только декларируются, а в реальности – сигналы через них проходят (иначе тут не было бы предмета), потому что процессору необходимо оптимизировать исполнение кода и доступ к памяти. Эти сигналы обязательно будут возникать именно потому, что в процессоре появился уровень, исполняющий “программу над программой”: упреждающий анализ команд работает по собственной программе (пусть и записанной непосредственно в аппаратуре); эта программа не только использует все потоки и фрагменты кода в качестве входных данных, но и влияет на состояние общих для изолируемых фрагментов кода элементов (кэш и очереди команд). То есть, схема аппаратной оптимизации тут всегда будет сквозной, можно сказать, что неустранимой. Вопрос в том, нужно ли считать такую архитектурную черту уязвимостью. Получается, что общая программа смотрит на команды в разных потоках и переключает состояние общих элементов, чтобы оптимизировать процесс. Изолируемые процессы находят способ измерения времени переключения состояний и – строится очередная уязвимость.

Если попробовать бороться с возникающими по описанным только что принципам сигналами, но попытаться сохранять общие элементы процессора, то каждый новый слой просто будет приводить к появлению более хитрых способов измерения: многими “атакующими” потоками, по накопленной статистике, ещё как-то. Если в архитектуру процессора, предположим, введут некоторое зашумление переключений кеша и предикторов, то носителем сигнала окажется схема, реализующая зашумление. Всякое подобное усложнение, добавление новых уровней, приводит к тому, что появляются и носители новых сигналов (это и есть “диагонализация”). При этом защита от “уязвимостей” программными методами, снижающими общее быстродействие, выглядит несколько странно, потому что предлагается прилагать дополнительные усилия для создания затруднений в работе оптимизирующих схем, которые и в процессоре уже встроены (то есть, потрачена площадь подложки и элементарные логические узлы), и само ПО при этом всё равно работает на общей аппаратуре.

Радикальное решение предполагает либо полную и точную аппаратную изоляцию уровней и ядер, когда все компоненты продублированы и работают независимо, либо полную замену системы команд (не стоит списывать со счетов, что в x86 уже и некоторые отдельные команды обладают тьюринг-полной реализацией). Однако это противоречит самой идее аппаратурной оптимизации на границе между логическим представлением команд процессора и машинным микрокодом. Да и приведёт внедрение таких методов только к тому, что очередной “пробой изоляции” между потоками выявят на стороне шин и контроллеров, взаимодействующих с ОЗУ и периферийными устройствами.

Почему-то много где громко пишут, что “обнаружена критическая неустранимая уязвимость процессоров Apple M1, раскрывающая криптографические ключи”, при этом имеется в виду новая “брендированная” атака Gofetch. Вообще, если почитать исходную работу, то речь там об очередном аппаратном “оракуле”, который использует, – опять же, очередной, – оптимизирующий компонент процессора: DMP (Data Memory-dependent Prefetcher), направленный на опережающее извлечение данных из памяти на основе косвенных “указателей” – то есть, значений, которые процессор считает записью адреса данных. Это популярное направление. Очень давно известно, что всякий подобный упреждающий механизм исполнения команд или извлечения данных порождает как минимум два побочных канала утечек (по записи и по чтению).

Подход Gofetch использует измеримые локально отличия в обработке тех “указателей”, которые схемы DMP смогли интерпретировать как “полезные” (то есть, показывающие на подходящие для упреждающего извлечения области адресного пространства), и “указателей”, которые получили статус “недоступных”. Это, конечно, выглядит занятно. Но нужно всё же учитывать и прочие параметры. Так, для успешного вычисления секретных ключей, атака должна проводиться из соседнего процесса и требует прямых вызовов функций атакуемого ПО. То есть программа уже должна работать в той же системе, на том же процессоре, где исполняется и полностью программный атакуемый “криптопровайдер”. Более того, атака требует штатного взаимодействия атакующей программы с этим “криптопровайдером” в течение длительного времени (ну и чтобы никакой другой процесс не помешал). Сложно придумать сценарий, где такая конфигурация будет действительно “неустранимой”.

В свежих версиях веб-сервера Nginx есть полезная (и довольно экзотическая) опция для настройки TLS: ssl_reject_handshake (on | off), о которой, оказывается, мало кто знает. Опция позволяет управлять прерыванием процесса установления TLS-соединения (“хендшейка”) на стороне сервера. С помощью “ssl_reject_handshake on;” можно отклонить TLS-соединение, если в клиентском ClientHello указано имя хоста (поле SNI), которого нет на стороне сервера.

Почему это удобно. Штатная работа веб-сервера по HTTPS подразумевает, что при установлении TLS-соединения клиент передаёт имя хоста, соответствующее DNS-имени веб-узла; например, для https://test.ru/ это будет test.ru. Однако никто не запрещает клиенту обратиться с другим именем хоста в SNI. Более того, на тот же самый IP-адрес, который соответствует веб-узлу под именем test.ru, может быть направлено другое DNS-имя (другой домен). Веб-браузеры, обращающиеся по такому имени, будут указывать его в SNI, а сервер, при прочих равных, не сможет найти не только соответствующий “виртуальный хост” в конфигурации, но и подобрать корректный TLS-сертификат. Однако какой-то TLS-сертификат для установления TLS-соединения серверу нужен и, без дополнительных мер, это приводит к тому, что сервер отвечает с “первым попавшимся” (буквально) серверным TLS-сертификатом из сконфигурированных.

Если на сервере всего один виртуальный хост/веб-узел (или настроены отдельные IP-адреса для отдельных веб-узлов), то ничего нового клиент не узнаёт. Однако если виртуальных хостов много, то ответ с произвольным сертификатом приводит к нежелательным утечкам имён: клиент получит сертификат, в котором будет указано имя другого сервиса, доступного на этом же узле (или несколько имён). Администраторы и даже DevOps об этом постоянно забывают.

Сделать тут что-то корректное на уровне HTTP невозможно в принципе, так как TLS-соединение устанавливается раньше, а для каждого HTTP-ответа (403 и пр.) потребуется подходящий по имени доверенный сертификат. Да, возможны различные “костыли”, вроде использования заведомо несовпадающего сертификата-заглушки, но все они подразумевают некорректный ответ.

Указание “ssl_reject_handshake on;” для default_server (для имени хоста по умолчанию) позволяет побороть только что описанную проблему: Nginx будет прерывать именно TLS-соединение, если клиент обращается с неверным именем хоста в SNI – это, что называется, технически строгий способ. Браузер, в таком случае, выведет сообщение о недоступности узла, а не предупреждение о несовпадении имён, которое пользователи привыкли преодолевать при помощи кнопки “Всё равно продолжить”.

В свежих версиях браузера Chrome на сторону серверов Google предлагается передавать информацию о запрашиваемых URL в реальном времени – это такое “улучшение для безопасности”, развитие давно работающей технологии Safe Browsing, но с некоторыми занимательными особенностями.

Так, для сохранения “приватности”, во-первых, сведения передаются в виде части значения хеш-функции, полученной от URL (с некоторыми преобразованиями); во-вторых, передавать запросы планируется через прокси-серверы, которые будут удалять информацию об IP-адресах; в-третьих, сервер будет возвращать набор полных значений, совпавших по короткому префиксу запроса, а точное совпадение уже будет определять браузер локально. То есть, схема передачи данных напоминает onion-маршрутизацию: содержательная часть зашифровывается при помощи открытого ключа сервера, поэтому промежуточный узел-прокси полезных данных не видит; а сервер – не видит IP-адреса источника запроса, потому что его удалил прокси. В теории. Так как конкретному URL соответствует только часть значения хеш-функции, короткий префикс, то ответов, потенциально, может поступить много разных (это все значения, для которых совпал начальный префикс, предположим, 32 бита). Такой расклад дополнительно маскирует исходный URL из браузера. В описании есть даже картинка – см. ниже, – однако ничего не сказано о том, какой ключ используется для зашифрования данных ответа.

(Image: Google.)

Если данные зашифровываются с использованием ключа, присланного браузером, то сервер видит индивидуальные ключи (которые, понятно, можно генерировать новые каждый раз, и тогда сервер видит ещё и историю генерирования). Если зашифрование не используется, то прокси видит историю просмотров страниц, пусть и взятую по срезам многих ответов. Очевидно, что значения хеш-функций, даже урезанные, можно сопоставлять с исходными URL, сгенерировав заранее. Полезную дополнительную информацию даёт учёт статистики запросов и построение пересечений по выборкам.

Но главное тут в том, что схему можно развивать: первый шаг – отправка информации об URL в реальном времени на “разрешающий” сервер, для определения статуса блокирования; на следующих шагах – можно передавать больше данных.

В конце 2022 года я добавил в DNS для dxdt.ru HTTPS-запись, которая тогда была описана в черновике RFC. В ноябре 2023 года черновик стал RFC 9460, где определяется способ публикации в DNS дополнительной информации о параметрах подключения к сервисам, связанным с данным именем. Например, это могут быть параметры для TLS/HTTPS, в том числе, ключи (см. ECH). Особенность использования DNS тут в том, что параметры можно получить до подключения, это, в свою очередь, позволяет устанавливать скрытые подключения.

The New York Times рассказывает (там много букв), как в Штатах водители современных “подключенных” автомобилей (то есть, автомобилей, у которых есть привязанное приложение с интернет-подключением) внезапно обнаружили, что очень подробные данные об их поездках передаются “скоринговым агентствам”, а статистика потом прямо влияет на стоимость страховки (“опасное вождение” и тому подобные эффекты). Данные, при этом, передаются через производителей автомобилей.

Удивительно, конечно, что это опять преподносится как нечто неожиданное: должно быть понятно, что использование некоторого, потенциально “облачного”, сервиса “помощи водителю” приводит к тому, что полезные данные передаются разным третьим компаниям. Вообще, в качестве основной функции “подключенного автомобиля” будущего намечается полное управление этим автомобилем с центральных серверов, дистанционно, начиная с открытия замков. Это, несомненно, делает использование “оцифрованного” транспортного средства “гораздо более удобным и безопасным”. Потому что используется это транспортное средство в качестве элемента большей схемы.

(via)

Нередко можно услышать или прочитать, что вероятность совпадения биометрических показателей у разных людей “исчезающе мала”, а поэтому совпадений не может быть на практике. Вообще, при оценке подобных статистических показателей обязательно нужно учитывать то, как показатели измеряются, преобразуются и что именно сравнивается, что именно считается за “совпадение”, а что – за “различие”.

Например, венозный рисунок ладони, считываемый некоторой аппаратурой, – он, может, разный у каждого человека, но сравнение-то будет выполняться после обработки “картинки” этого рисунка по некоторому алгоритму. Алгоритм, предположим, “сжимает” геометрический рисунок до 64 битов идентификатора, используя именно важные элементы (пересечения, фрагменты сетки, углы и пр., это тут не так важно). Получается что-то вроде хеш-функции или “функции сжатия”. В идеальной ситуации даже одно минимальное отличие рисунков должно давать другой код. При этом, конечно, возникает идея сделать не просто хеш-функцию, а такую хеш-функцию, которая ещё и обладает нужной локализацией, то есть, “близкие” рисунки дадут “близкие” значения. Кстати, такие функции сжатия или хеш-функции называются Locality-Sensitive Hash (LSH). Они удобны далеко не только в обработке биометрии. Однако есть побочные эффекты. С одной стороны, подходящая локализация поможет добавить ещё один слой устойчивости к ошибкам считывания, но, с другой стороны, может выдавать ложное положительное срабатывание.

В любом случае, сжатие какой-то исходной биометрии в некоторые коэффициенты может приводить к нежелательным эффектам: например, функция преобразования будет терять какие-то важные отличия. Если используется массив коэффициентов, то ошибка может распространяться по каким-то из них, по самым “слабым”, так как на следующих этапах сранивать будут уже подмножества. Всё это относится не только к упомянутым венозным рисункам, но и к биометрии в целом. В данной области любое преобразование должно быть устроено надёжным и, главное, однозначным способом, сохраняющим избирательность на нужном уровне, гарантированно превышающем вариативность в реальной биологической выборке, представителей которой предлагается различать. Потому что если биометрический показатель хорошо отображается в 64 бита, то это, вроде, достаточно много. Однако, если реально возможно попадание только, предположим, в 16 бит, – пусть и по максимально “далёким”, в смысле привычной двоичной системы, значениям, – то это уже несравнимо хуже: в случае массовой системы, из-за парадокса дней рождения, проблемы с совпадением измерений проявятся очень быстро.

Насколько вообще должны отличаться результаты считывания венозного рисунка, чтобы признать, что это были показатели разных людей? Обратите внимание: для самого идеального рисунка – более или менее понятно, что даже “минимальные” отличия будут означать, что это другой человек. Но сравниваются-то изображения. И ввести тут корректное, для решаемой задачи, понятие “минимальности” отличий очень и очень сложно.

Поэтому-то применение непонятных и непрозрачных алгоритмов “нейросетей” в подобной автоматизированной биометрии не к месту. Процесс взвешивания коэффициентов в процессе “обучения” может оптимизировать фильтры относительно совсем не тех показателей, которые обеспечивают различимость на настоящей выборке. Тем более, что в нейросетевые системы можно вносить бекдоры. Эти бекдоры используются как раз для того, чтобы совершенно непохожий, но специально подготовленный, биометрический объект “свернулся”, после преобразования, в какой-то другой, являющийся универсальным.

Использование биометрии в разных типах систем контроля тоже сильно различается. Одно дело, если это обособленная система доступа в помещения (классическая СКУД). В такой системе, оператор, когда создаёт учётную запись нового сотрудника с допуском, может обнаружить, что считывание, предположим ладони, приводит к коду, который уже есть в базе данных. Так что случайное (или не случайное) совпадение тут же будет выявлено. (Биометрия вообще должна бы использоваться только при участии оператора-человека, но сейчас от этого элемента постоянно отступают.) Другое дело, когда биометрический показатель, поступивший из внешней системы, используется для поиска по “неопределённой выборке”. Тут проблемы возникают вовсе не в области, где, якобы, “вероятность совпадения биометрии почти нулевая”, а в области качества сжатия параметров перед реальным сравнением – и вероятность совпадения значений функции сжатия (хеш-функции) уже может быть совсем не нулевой. Тем более, когда это не криптографическая хеш-функция, а не ясно как подкрученная “нейросеть” с анализом изображений.

Когда оценивают влияние отключения тех или иных магистральных кабелей на связность Интернета, нередко забывают о паре важных факторов: во-первых, сам момент переключения путей доставки трафика может создать дополнительные проблемы – уже и разнообразное “мигание” связности мешает нормальной работе коммутаторов/маршрутизаторов, а неожиданно большие затраты на передачу изменений маршрутов могут привести к тому, что и резервные пути окажутся недоступны; во-вторых, с резервированием в “этих интернетах” регулярно случается так, что после поступления действительно большого потока на резервные схемы – схемы эти падают, так как резервными они являлись не в “тёмном” режиме stand-by, а лишь резервировали некоторую полосу, доступную сверх типичной загрузки.

Оба этих фактора едва ли не гарантируют, что в момент каких-то пиковых изменений распространение информации о самих изменениях приводит к возникновению задержек, которые, в свою очередь, с необходимостью вызывают новые изменения, информация о которых тоже должна передаваться, что увеличивает задержки, ну и, в общем, понятно, что происходит далее. Подобные каскадные “штормы” периодически случаются более или менее “локально”, разработаны методы борьбы, но, всё же, умело нанесённый удар по кабелям может обрушить почти всё.

А так-то, да, конечно, в Интернете были задуманы механизмы самоорганизации межсетевого взаимодействия, на случай “глобальных проблем”. Вот только было это сорок лет назад, отчасти являлось прикрытием для других задач, нуждавшихся в финансировании, да и вообще предлагалось для одного конкретного и небольшого сегмента межсетевых соединений, где пытались сохранять связность – времена несколько поменялись.

У рассылки SMS с устройств пользователей, которую, как пишут, предлагает Telegram, есть ценный “идейный” аспект: распределённую сеть, составленную из абонентских устройств, можно использовать куда как интереснее, чем просто в роли инструмента бесплатных SMS-рассылок. Смартфон, с работающим приложением, может обнаруживать другие устройства: WiFi, Bluetooth разных видов, акустика (это особенный метод, не только совместимый с “умными” колонками, но и вообще – кроссплатформенный и эффективно работающий в обе стороны).

Поэтому, в обмен на “премиум-доступ”, можно построить активную сенсорную сеть, с привязкой к точному времени и координатам, которая будет видеть перемещение не только различных пользователей приложения-мессенджера, но и прочих носителей смартфонов, равно как и выявлять устройства типа ноутбуков, беспроводных наушников, браслетов, часов с “картами и GPS”, “умных” (не менее, чем колонки) телевизоров, специальных “маячков”, а также и других подобных – тут есть где развернуться.