Раскрытие Скрытого Отслеживания: Как Meta и Яндекс Использовали Localhost на Android

Шокирующие данные о методах, связывающих вашу веб-активность с профилями в приложениях, даже в режиме инкогнито.

Ключевые Выводы

Скрытое Отслеживание: Meta (Facebook, Instagram) и Яндекс использовали localhost-сокеты на Android для тайной связи между веб-сайтами и нативными приложениями, обходя традиционные меры защиты конфиденциальности.
Деанонимизация Пользователей: Этот метод позволял связывать временные веб-идентификаторы (как файлы cookie) с долгосрочными идентификаторами мобильных приложений (например, AAID), деанонимизируя пользователей даже без их согласия или в режиме инкогнито.
Реакция и Защита: После раскрытия, Meta значительно сократила использование этой практики, а разработчики браузеров, таких как Chrome и Brave, внедрили меры по блокировке и ограничению подобного поведения, повышая уровень приватности пользователей.

Введение в Механизмы Скрытого Отслеживания

Недавнее исследование выявило сложный и неочевидный метод отслеживания пользователей Android, используемый Meta (владельцами Facebook и Instagram) и Яндекс. Этот метод потенциально затронул миллиарды пользователей, поскольку он позволяет этим компаниям собирать и связывать данные о вашей веб-активности с вашими профилями в нативных приложениях, даже когда вы используете режим инкогнито или очищаете файлы cookie.

Суть проблемы заключается в использовании "localhost" — внутреннего сетевого интерфейса, который позволяет приложениям на одном устройстве обмениваться данными. Нативные Android-приложения, такие как Facebook, Instagram, а также несколько приложений Яндекса (включая Карты и Браузер), тайно прослушивали фиксированные локальные порты для целей отслеживания. Скрипты Meta Pixel и Яндекс.Метрика, встроенные в тысячи веб-сайтов, загружались в мобильных браузерах пользователей и незаметно соединялись с этими нативными приложениями, работающими на том же устройстве, через сокеты localhost.

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

Это исследование подчеркивает критическую уязвимость в архитектуре конфиденциальности мобильных устройств и вызывает серьезные вопросы о том, как крупные технологические компании собирают и используют пользовательские данные.

Принципы Работы Localhost Отслеживания

Операционная система Android предоставляет любому установленному приложению с разрешением INTERNET возможность открывать прослушивающий сокет на интерфейсе обратной связи (127.0.0.1). Что критически важно, мобильные браузеры, работающие на том же устройстве, также имеют доступ к этому интерфейсу без какого-либо дополнительного согласия пользователя или посредничества платформы. Это позволяет JavaScript, встроенному в веб-страницы, обмениваться данными с нативными Android-приложениями и передавать идентификаторы и привычки просмотра, связывая временные веб-идентификаторы с долгосрочными идентификаторами мобильных приложений с помощью стандартных веб-API.

Методология Meta/Facebook Pixel

Когда скрипт Meta (Facebook) Pixel загружается в мобильном браузере Android, он использует технологию WebRTC для передачи файла cookie первой стороны _fbp на UDP-порты в диапазоне 12580–12585. Было обнаружено, что приложения Facebook и Instagram (включая версии 515.0.0.23.90 и 382.0.0.43.84 соответственно) активно прослушивали этот диапазон портов.

До недавнего времени Meta Pixel использовал технику, известную как SDP Munging, для вставки содержимого файла cookie _fbp в поле SDP "ice-ufrag", что приводило к отправке сообщения STUN Binding Request на адрес обратной связи. Это позволяло данным передаваться от веб-браузера к нативному приложению, а затем на сервер. Приложения Facebook или Instagram получали файл cookie _fbp от JavaScript Meta Pixel, работающего в браузере, и передавали его как GraphQL-мутацию на https://graph.facebook.com/graphql вместе с другими постоянными пользовательскими идентификаторами, связывая _fbp ID пользователя (веб-посещение) с его учетной записью Facebook или Instagram.

Приблизительно 17 мая 2025 года Meta Pixel добавил новый метод, который отправляет файл cookie _fbp с использованием WebRTC TURN вместо STUN, чтобы избежать SDP Munging. Однако, по состоянию на 2 июня 2025 года, приложения Facebook или Instagram не были замечены активно прослушивающими эти новые порты. Важно отметить, что файл cookie _fbp предназначен для идентификации браузеров в целях предоставления рекламных и аналитических услуг и имеет срок действия 90 дней, присутствуя примерно на 25% из миллиона самых популярных веб-сайтов.

Диаграмма, показывающая, как Meta Pixel обменивается данными с приложением Facebook через localhost.

Схематическое изображение процесса обмена данными между Meta Pixel и приложением Facebook через localhost.

Подход Яндекс.Метрики

Скрипт Яндекс.Метрики использовал иной подход, инициируя HTTP-запросы с длинными и непрозрачными параметрами на localhost через определенные TCP-порты: 29009, 29010, 30102 и 30103. Приложения Яндекс, такие как Яндекс.Карты, Яндекс.Навигатор, Яндекс.Поиск и Яндекс.Браузер, активно прослушивали эти порты.

Для скрытия трафика, домен yandexmetrica.com разрешался в адрес обратной связи 127.0.0.1, и скрипт Яндекс.Метрики передавал данные по HTTPS на локальные порты 29010 и 30103, что значительно затрудняло обнаружение. Приложения Яндекс связывались с доменом Яндекс (например, startup.mobile.yandex.net) для получения списка портов для прослушивания, а также параметра first_delay_seconds, который, вероятно, использовался для задержки запуска службы.

После получения HTTP-запросов localhost от скрипта Яндекс.Метрики мобильное приложение отвечало бинарной полезной нагрузкой, закодированной в Base64, которая содержала рекламный идентификатор Android (AAID) и другие идентификаторы. В случае с Яндекс, нативное приложение действовало как прокси для сбора идентификаторов, специфичных для Android, и их передачи в контекст браузера через сокеты localhost.

Диаграмма, демонстрирующая, как Яндекс.Метрика передает данные приложению Яндекс через localhost.

Схематическое представление передачи данных Яндекс.Метрикой в приложение Яндекс.

Обход Защитных Механизмов Приватности

Этот метод обмена идентификаторами между веб-приложениями и нативными приложениями представляет собой серьезную проблему, поскольку он обходит типичные средства защиты конфиденциальности, на которые полагаются пользователи. К таким средствам относятся:

Очистка файлов cookie: Даже после удаления файлов cookie из браузера, связь через localhost позволяла восстанавливать или связывать новые сессии с существующими идентификаторами в приложениях.
Режим инкогнито: Традиционно, режим инкогнито предотвращает сохранение истории просмотров и файлов cookie. Однако, localhost-связь происходила независимо от этого режима.
Контроль разрешений Android: Пользователи могли быть уверены, что, не предоставляя явных разрешений, их данные останутся конфиденциальными. Но разрешение INTERNET, которое является общим для большинства приложений, было достаточным для использования localhost-сокетов.

Более того, такая уязвимость открывает двери для потенциально вредоносных приложений, которые могут перехватывать веб-активность пользователей. Использование HTTP-запросов для обмена идентификаторами между веб-приложениями и нативными приложениями (в отличие от WebRTC STUN или TURN) может привести к утечке истории просмотров пользователей третьим лицам. Вредоносное стороннее Android-приложение, прослушивающее упомянутые порты, могло перехватывать HTTP-запросы, отправляемые скриптом Яндекс.Метрики, и первую, ныне неиспользуемую, реализацию канала связи Meta, отслеживая заголовок Origin HTTP.

Масштабы Проблемы и Затронутые Сайты

Исследование показало, что масштабы использования этих скриптов впечатляют. Согласно данным BuiltWith, Meta Pixel встроен более чем в 5,8 миллиона веб-сайтов, а Яндекс.Метрика присутствует почти на 3 миллионах веб-сайтов. По данным HTTP Archive, Meta Pixel и Яндекс.Метрика присутствуют на 2,4 миллиона и 575 448 веб-сайтах соответственно. Эти цифры указывают на огромную потенциальную аудиторию, затронутую этим методом отслеживания.

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

Сравнение распространенности использования методов отслеживания Meta Pixel и Яндекс.Метрики без согласия пользователя в США и Европе. Оси радара представляют относительную долю сайтов, на которых наблюдалось отслеживание.

Хронология и Реакция Отрасли

Отслеживание через localhost не является новым явлением. Яндекс использует localhost-связь с февраля 2017 года (HTTP) и мая 2018 года (HTTPS). Meta же начала использовать HTTP-связь в сентябре-октябре 2024 года, Websocket в ноябре 2024 - январе 2025 года, и WebRTC STUN (с SDP Munging) с ноября 2024 года. С мая 2025 года используется WebRTC TURN.

После раскрытия этой информации разработчики браузеров (Chrome, Mozilla, DuckDuckGo и Brave) были уведомлены, что привело к внедрению некоторых патчей. Например, Chrome (версия 137, выпущенная 26 мая 2025 г.) внедрил меры по блокировке используемых портов и отключению конкретной формы SDP Munging, используемой Meta Pixel. Браузер Brave не был затронут этой проблемой, так как требует согласия пользователя для связи по localhost с 2022 года и имеет список блокировки.

Особенно значимым является тот факт, что по состоянию на 3 июня 2025 года скрипт Meta/Facebook Pixel больше не отправляет пакеты или запросы на localhost. Код, отвечающий за отправку файла cookie _fbp, был почти полностью удален. Владельцы веб-сайтов, использующие Meta Pixel, выражали недоумение по поводу того, почему скрипт связывается с localhost, но не получали официальных объяснений от Meta.

Конечные пользователи, вероятно, не осведомлены об этом поведении, так как оно происходит, даже если пользователь не вошел в Facebook, Instagram или Яндекс, использует режим инкогнито, или очищает свои файлы cookie и другие данные просмотра.

Меры Защиты в Браузерах

Различные браузеры по-разному реагировали на эту проблему. Ниже представлена таблица, суммирующая их статус и принятые меры:

Браузер	Версия	Затронутость	Меры защиты
Chrome	136.0.7103	Затронут обеими методами	Версия 137 блокирует основные атаки
Microsoft Edge	136.0.3240	Затронут	Неизвестно
Firefox	138.0.2	Яндекс затронут, Meta нет	Защита в разработке
DuckDuckGo	5.233.0	Минимально затронут	Обновленный блоклист
Brave	1.78.102	Нет	Блокировка localhost без согласия пользователя

Расширенные Риски и Будущие Вызовы

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

Проблема конфиденциальности в цифровом мире постоянно развивается, и обнаружение таких скрытых методов отслеживания подчеркивает необходимость постоянной бдительности как со стороны исследователей, так и со стороны пользователей. Разработчикам и владельцам сайтов рекомендуется пересмотреть использование Meta Pixel и Yandex Metrica с учётом этих рисков, а пользователям — использовать браузеры, активно защищающие от localhost-отслеживания.

Изображение, символизирующее важность конфиденциальности в цифровом пространстве.

Символ приватности в контексте современных цифровых угроз.

Понимание Взаимодействия Localhost

Для лучшего понимания того, как работают эти механизмы и какие риски они несут, ниже представлена mindmap-диаграмма. Она иллюстрирует ключевые компоненты и их взаимосвязи в контексте localhost-отслеживания.

mindmap root["Скрытое Отслеживание через Localhost на Android"] Localhost_Mechanism["Как это работает"] Android_Permissions["Разрешение INTERNET"] Loopback_Interface["127.0.0.1 (Loopback)"] Browser_Access["Доступ браузеров"] JavaScript_Web_APIs["Использование Web APIs"] Meta_Pixel_Tracking["Метод Meta/Facebook Pixel"] FBP_Cookie["_fbp Cookie"] WebRTC_UDP["WebRTC (UDP порты 12580-12585)"] SDP_Munging["SDP Munging (старый метод)"] WebRTC_TURN["WebRTC TURN (новый метод)"] Native_Apps_Listen["Facebook/Instagram слушают"] GraphQL_Mutation["Передача на graph.facebook.com/graphql"] Yandex_Metrica_Tracking["Метод Яндекс.Метрики"] HTTP_Requests["HTTP/HTTPS запросы"] TCP_Ports["TCP порты (29009, 29010, 30102, 30103)"] Yandex_Domain_Resolution["yandexmetrica.com -> 127.0.0.1"] Native_Apps_Listen_Yandex["Яндекс.Карты, Навигатор, Браузер слушают"] AAID_Data["Передача AAID и других идентификаторов"] App_as_Proxy["Приложение как прокси"] Privacy_Bypass["Обход Защит Конфиденциальности"] Cookie_Clearing["Очистка cookie"] Incognito_Mode["Режим инкогнито"] Android_Permissions_Control["Контроль разрешений Android"] Additional_Risks["Дополнительные Риски"] Browser_History_Leakage["Утечка истории просмотров"] Malicious_Apps["Вредоносные сторонние приложения"] Affected_Scale["Масштабы Затронутости"] Meta_Pixel_Websites["5.8 млн+ сайтов (BuiltWith)"] Yandex_Metrica_Websites["3 млн+ сайтов (BuiltWith)"] No_Consent_Tracking["Отслеживание без согласия"] Industry_Response["Реакция Отрасли"] Browser_Patches["Патчи браузеров"] Chrome_Measures["Меры Chrome (v137)"] Brave_Security["Brave (блокировка с 2022)"] Meta_Pixel_Changes["Изменения в Meta Pixel (удаление кода)"] Future_Recommendations["Будущие Рекомендации"] User_Controls["Пользовательские элементы управления"] Platform_Policy["Политика платформы"] Android_IPC_Security["Безопасность межпроцессного взаимодействия Android"]

Mindmap, демонстрирующая ключевые аспекты и взаимосвязи скрытого отслеживания через localhost.

Часто Задаваемые Вопросы (FAQ)

Что такое localhost-отслеживание?

Localhost-отслеживание — это метод, при котором веб-сайты взаимодействуют с нативными приложениями на одном и том же устройстве через внутренние сетевые порты (localhost). Это позволяет передавать идентификаторы и данные о просмотре между веб-браузером и приложением, даже если пользователь не предоставил явного согласия.

Какие компании использовали этот метод?

Исследование показало, что Meta (через Meta Pixel для Facebook и Instagram) и Яндекс (через Яндекс.Метрику для своих приложений, таких как Карты, Браузер) активно использовали этот метод для связывания веб-активности с профилями пользователей в приложениях.

Как этот метод обходит защиту конфиденциальности?

Localhost-отслеживание обходит такие традиционные меры защиты, как очистка файлов cookie, использование режима инкогнито и настройки разрешений Android. Это происходит потому, что связь осуществляется внутри устройства, используя общее разрешение INTERNET, без необходимости дополнительных пользовательских подтверждений.

Что было сделано для предотвращения такого отслеживания?

После публичного раскрытия этой проблемы, Meta значительно сократила использование данного метода, удалив соответствующий код из Meta Pixel. Разработчики браузеров, таких как Chrome (начиная с версии 137) и Brave, внедрили меры по блокировке портов и конкретных техник, используемых для этого отслеживания. Brave уже давно требовал согласия пользователя для такого рода обмена данными.

Как пользователи могут защитить себя?

Пользователям рекомендуется использовать браузеры, которые активно защищают от localhost-отслеживания, такие как Brave или обновленные версии Chrome. Также следует быть внимательными к разрешениям, которые вы даете приложениям, и регулярно проверять настройки конфиденциальности на своих устройствах.

Заключение

Открытие скрытого localhost-отслеживания Meta и Яндекс на Android ярко демонстрирует постоянно меняющуюся и часто неочевидную природу цифровой конфиденциальности. Этот метод, обходящий стандартные меры защиты и работающий даже без явного согласия пользователя, подрывает доверие к тому, как крупные технологические компании обрабатывают личные данные. Хотя немедленная реакция отрасли, включая изменения со стороны Meta и патчи в браузерах, является шагом в правильном направлении, она также подчеркивает необходимость постоянной бдительности. Для полного решения подобных угроз потребуются системные изменения, включая более строгие политики платформ, улучшенные механизмы межпроцессного взаимодействия и, что наиболее важно, усиление пользовательских элементов управления и прозрачности в отношении того, как приложения и веб-сайты взаимодействуют на устройстве. Только через коллективные усилия исследователей, разработчиков и регуляторов мы можем стремиться к более безопасной и приватной цифровой среде.