Что Facebook может узнать о браузере: результаты технического аудита
Для арбитражника браузер — это не просто окно с рекламным кабинетом. Пока пользователь открывает страницы, приложение взаимодействует с локальными хранилищами, запрашивает характеристики устройства, загружает ресурсы и обменивается данными с серверами.Чтобы разобраться в этих механизмах, автор исходного исследования провел аудит веб-сессии с помощью Frida и MITM-прокси. В логах были зафиксированы обращения к браузерным API, работа с хранилищами и сетевой обмен.
Основные показатели наблюдаемой сессии:
| Показатель | Зафиксированное значение |
|---|---|
| Сетевые запросы | 3 474 |
| Сторонние домены | 55 |
| Операции Web Storage в категории DET-050 | 1 895 |
| Вызовы IndexedDB | 10 |
| Вызовы Canvas getImageData() | 2 |
| Обращения к WebGPU requestAdapter() | Зафиксированы |
| Обращения к OfflineAudioContext | Зафиксированы |
| Обращения к WebRTC API | Зафиксированы |
Еще одно важное ограничение: аудит браузерной стороны показывает, какие интерфейсы вызывались и какие данные были доступны в наблюдаемой среде. Он не раскрывает внутренние алгоритмы Meta и сам по себе не доказывает, что каждый обнаруженный параметр участвует в принятии решения об ограничении рекламного аккаунта.
Разберем отдельные слои — от Cookies до графического процессора.
1. Cookies: что браузер хранит и отправляет серверу
Cookies — небольшие записи, которые сайт сохраняет в браузере. Они могут использоваться для поддержания сессии, хранения настроек и других задач, связанных с работой веб-приложения.Поведение Cookie зависит не только от ее значения, но и от атрибутов:
- Domain и Path определяют область действия записи.
- Expires и Max-Age задают срок хранения.
- Secure ограничивает передачу защищенным соединением HTTPS.
- HttpOnly запрещает доступ к Cookie через обычный JavaScript API.
- SameSite регулирует отправку Cookie в контекстах межсайтовых запросов.
Почему проверка только через JavaScript неполная
В аудите отмечались обращения к Cookie через привычный JavaScript API и через Cookie Store API, включая методы get(), getAll(), set() и delete().Но наличие этих вызовов не означает, что скрипт имеет доступ ко всем Cookie сайта.
Если запись помечена HttpOnly, страничный JavaScript не может прочитать ее через document.cookie. При этом браузер может автоматически прикладывать ее к подходящим HTTP-запросам, если соблюдены остальные условия отправки.
Отсюда следует практический вывод: данные, доступные скриптам, не обязательно совпадают с полным набором Cookie, которые браузер отправляет серверу.
Кроме того, очистка Cookie не равна полному сбросу состояния сайта. Отдельно могут существовать записи в localStorage, sessionStorage, IndexedDB, кэше и других механизмах хранения.
2. Web Storage: localStorage и sessionStorage
Web Storage позволяет веб-приложениям хранить пары «ключ — значение» непосредственно в браузере. Основные варианты — localStorage и sessionStorage.| Хранилище | Особенности | Типичный жизненный цикл |
|---|---|---|
| localStorage | Хранит строки по ключам в рамках origin | Обычно сохраняется после закрытия и повторного запуска браузера |
| sessionStorage | Отдельное хранилище для контекста вкладки | Обычно существует в пределах сессии страницы и очищается после ее завершения |
Обычный цикл выглядит так:
- Скрипт проверяет, есть ли нужное значение.
- Получает сохраненные данные.
- Обновляет состояние после действия пользователя или ответа сервера.
- Записывает новое значение.
- Повторно читает его при следующем обращении.
Для технического аудита важнее выяснить, какие ключи читаются и изменяются, в какой момент это происходит и как операции связаны с другими событиями сессии.
3. IndexedDB: локальная база данных браузера
Когда приложению нужно хранить более сложные структуры, оно может использовать IndexedDB — асинхронную браузерную базу данных.В исходном аудите зафиксировали десять вызовов, связанных с IndexedDB, включая:
- indexedDB.open() — открытие или создание базы;
- indexedDB.deleteDatabase() — удаление базы;
- indexedDB.databases() — получение списка баз, поддерживаемое современными браузерами.
Особого внимания заслуживает databases(): этот метод позволяет получить сведения о базах IndexedDB, существующих в доступном контексте. В зависимости от браузера и среды часть сведений может быть недоступна или ограничена.
При этом важно не делать лишний вывод. Наличие локальной базы данных не доказывает, что сайт сравнивает ее содержимое между рекламными аккаунтами. Чтобы подтвердить конкретный сценарий, нужно исследовать, какие базы и объекты затрагиваются и что происходит с ними в течение сессии.
Почему локальное состояние имеет значение
Два браузерных профиля с одинаковыми основными настройками могут различаться по истории хранения данных. Один использовался месяцами, другой только что создан.Это нормальное следствие работы браузера. Но само различие не означает автоматического ограничения аккаунта: для такого вывода потребовались бы дополнительные данные о серверной обработке и результатах проверок.
4. Сетевой слой: 3 474 запроса и 55 сторонних доменов
Современное веб-приложение продолжает обмениваться данными после первоначальной загрузки страницы. Браузер загружает изображения, скрипты, стили, шрифты и данные интерфейса, отправляет API-запросы и получает ответы.В рассматриваемой сессии было зафиксировано 3 474 сетевых запроса и 55 сторонних доменов.
Среди возможных причин обращения к сторонним доменам:
- доставка статических ресурсов через CDN;
- получение данных от API;
- аналитика и измерение производительности;
- работа встроенных компонентов и библиотек;
- загрузка других ресурсов, необходимых странице.
Что полезнее общего количества запросов
При анализе сетевого лога важно учитывать контекст:| Что анализировать | Зачем |
|---|---|
| Домен и endpoint | Понять, какой сервис принимает или возвращает данные |
| HTTP-метод | Различать чтение, отправку и другие типы операций |
| Время запроса | Сопоставить обмен с действием пользователя или загрузкой компонента |
| Заголовки | Увидеть передаваемые параметры и особенности запроса |
| Статус ответа | Проверить успешность запроса и возможные ошибки |
| Последовательность событий | Восстановить причинно-временную картину работы страницы |
Однако даже подробный лог показывает только наблюдаемый сетевой обмен. Он не позволяет без дополнительных доказательств утверждать, какие именно данные сервер использует для оценки аккаунта.
5. Client Hints: дополнительные характеристики браузера
User-Agent — строка, которая исторически использовалась для описания браузера и среды выполнения. Но современных сайтов нередко интересуют и дополнительные характеристики, передаваемые через механизм User-Agent Client Hints.В исходном исследовании среди наблюдаемых параметров упоминались:
| Параметр | Что описывает |
|---|---|
| Sec-CH-UA-Full-Version-List | Бренды и полные версии браузеров в поддерживаемом формате |
| Sec-CH-UA-Model | Модель устройства, когда параметр поддерживается и доступен |
| Sec-CH-UA-Platform-Version | Версию платформы |
| Sec-CH-Prefers-Color-Scheme | Предпочтение светлой или темной темы |
| DPR | Соотношение физических пикселей к CSS-пикселям |
| Viewport-Width | Ширину области просмотра в соответствующем формате |
Для анализа важно не только наличие каждого отдельного параметра, но и то, как он соотносится с остальными сведениями о браузере и устройстве.
Например, ширина области просмотра и DPR влияют на то, как веб-страница отображается на экране. При этом несовпадение двух значений не всегда свидетельствует о подмене: у них разные источники, и они могут законно меняться при масштабировании страницы, изменении окна или подключении другого дисплея.
Поэтому корректный технический вывод требует учитывать версию браузера, тип устройства и условия измерения, а не считать любую разницу доказательством фальсификации.
6. Canvas fingerprint: что можно узнать по графическому рендерингу
Canvas — это HTML-механизм для рисования графики в браузере. Он используется в интерфейсах, визуализациях, играх и других веб-приложениях.В аудите был зафиксирован вызов CanvasRenderingContext2D.getImageData(). Согласно описанию исследования, таких событий было два.
Метод позволяет получить массив пиксельных данных из области Canvas. Если сайт использует его в сценарии fingerprinting, результат может помочь различать среды выполнения.
На результат графического рендеринга влияют особенности реализации браузера, операционной системы и графического стека. В определенных условиях небольшие различия могут быть воспроизводимыми и пригодными для сравнения.
Но сам вызов getImageData() не доказывает, что страница вычисляла отпечаток. Метод также используется для обычных графических задач — например, обработки изображений или анализа цветов.
Чтобы определить назначение конкретного обращения, необходимо исследовать, что именно рисуется, какая область читается, как обрабатывается результат и куда затем передаются полученные данные.
7. Геометрия DOM: размеры элементов и отрисованный интерфейс
Браузер предоставляет API, с помощью которых скрипты могут измерять положение и размеры элементов страницы.В исследовании упоминались:
- getBoundingClientRect();
- getClientRects();
- offsetWidth;
- offsetHeight.
Они нужны для обычных интерфейсных задач: позиционирования всплывающих окон, адаптивной верстки, определения видимости контента и работы интерактивных компонентов.
В некоторых сценариях геометрия элементов может дополнять другие сигналы о среде браузера. Например, отрисовка текста зависит от доступных шрифтов и особенностей рендеринга.
Однако нельзя считать, что любой вызов этих API используется для идентификации устройства. Для такого вывода необходим контекст конкретного скрипта и обработка полученных измерений.
8. WebGPU: что браузер сообщает о графическом адаптере
WebGPU — современный API для графики и вычислений с использованием возможностей GPU. Он позволяет веб-приложениям обращаться к графическому адаптеру через браузер.В наблюдаемой сессии был зафиксирован вызов requestAdapter(). Этот метод используется для запроса доступного графического адаптера, после чего приложение может проверять поддерживаемые возможности и ограничения.
В зависимости от браузера и реализации доступная информация может включать характеристики возможностей адаптера. При этом вызов requestAdapter() сам по себе не означает, что страница получила точную модель видеокарты или полный набор аппаратных сведений.
Почему WebGPU интересен при исследовании fingerprinting
Графические возможности браузера зависят от нескольких факторов: операционной системы, драйверов, браузера, доступного GPU и политики ограничений самой среды.Если приложение намеренно использует WebGPU для построения отпечатка, сведения о доступных возможностях могут дополнять другие характеристики браузера.
Но есть важная оговорка: сам факт обращения к WebGPU не доказывает, что Facebook* использует его именно для антифрода. WebGPU также может применяться для графики и вычислений. Для подтверждения конкретного назначения нужно исследовать, какие данные запрашиваются и как они обрабатываются.
Практический вывод для аудитора прост: WebGPU стоит включать в перечень исследуемых интерфейсов, если задача — понять поверхность данных, доступных веб-приложению.
9. AudioContext: обработка звука без слышимого аудио
Web Audio API позволяет браузеру создавать, обрабатывать и анализировать звук. Он применяется в музыкальных сервисах, видеоредакторах, играх и других приложениях.В исходном аудите отмечались обращения к OfflineAudioContext. Этот интерфейс позволяет выполнять аудиообработку вне обычного воспроизведения в реальном времени, без вывода звука на устройство пользователя.
При использовании аудиоотпечатков приложение может обрабатывать сигнал и сравнивать результаты. В зависимости от сценария на результат способны влиять реализация браузера, особенности аудиостека и вычислений.
Но сам вызов OfflineAudioContext не подтверждает, что Facebook* строил отпечаток. Интерфейс может использоваться для обычной обработки звука.
В исходной публикации также приводилась оценка пула из 4 096 аудиоотпечатков для Windows. Без описания методики сбора, состава выборки, определения уникальности и способа подсчета эту цифру нельзя считать универсальной характеристикой всех Windows-устройств.
Для технического анализа надежнее фиксировать конкретный сценарий: какой контекст создан, какие узлы подключены, какие операции выполняются и как используется результат.
10. WebRTC: сетевые маршруты и ICE-кандидаты
WebRTC — набор технологий для передачи аудио, видео и данных в реальном времени. Он используется в видеозвонках, конференциях и приложениях с прямым обменом данными между устройствами.Для установления соединения WebRTC использует ICE-механизм, который помогает подобрать рабочий сетевой маршрут. В процессе могут формироваться ICE-кандидаты, содержащие сведения, необходимые для установления соединения.
В исходном аудите обращения к WebRTC API были зафиксированы, но данные самих ICE-кандидатов автор исключил из анализа. Поэтому по приведенным результатам нельзя назвать конкретный IP-адрес, который мог быть доступен странице, или подтвердить факт утечки адреса.
Что учитывать при проверке WebRTC
Настройки прокси и сетевое поведение браузера — не одно и то же. Прокси может обрабатывать часть HTTP- и HTTPS-трафика, тогда как WebRTC использует отдельные механизмы установления соединения. Конкретное поведение зависит от браузера, конфигурации, типа соединения и доступных сетевых маршрутов.Если задача заключается в проверке приватности собственного браузера, полезно отдельно исследовать сетевые интерфейсы, разрешения, поведение WebRTC и возможные прямые соединения. Сам факт обращения к API не является доказательством утечки: для этого нужно подтвердить, какие адреса и сведения действительно были раскрыты.
11. Как разные сигналы складываются в картину браузерной среды
Каждый из рассмотренных механизмов выполняет свою задачу. Cookies поддерживают состояние сайта, Web Storage и IndexedDB хранят данные, Client Hints описывают некоторые характеристики браузера, а Canvas, WebGPU и AudioContext предоставляют интерфейсы для работы с графикой и звуком.В некоторых сценариях разные данные могут дополнять друг друга. Именно поэтому технический аудит не должен ограничиваться одним User-Agent или одним результатом проверки Canvas.
Упрощенная схема работы веб-сессии выглядит так:
Браузер → локальное состояние → JavaScript → сетевой запрос → ответ сервера → обновленное состояние.
Параллельно браузер предоставляет странице интерфейсы для измерения размеров элементов, обработки графики, работы со звуком и взаимодействия с сетевыми возможностями.
Но важно различать три уровня утверждений:
- Наблюдение: API был вызван или запрос зафиксирован в логах.
- Интерпретация: вызов может быть связан с определенной функцией приложения.
- Вывод о серверном решении: данные действительно использовались системой антифрода для конкретного действия.
12. Сводная таблица технического аудита
| Слой | Что зафиксировано | Что можно заключить |
|---|---|---|
| Cookies | Обращения к Cookie API и Cookie Store API | Приложение работает с механизмами хранения Cookie |
| Web Storage | 1 895 операций в категории DET-050 | Локальное хранилище активно используется в наблюдаемой сессии |
| IndexedDB | 10 вызовов | Приложение обращается к браузерной базе данных |
| Сеть | 3 474 запроса и 55 сторонних доменов | Страница активно загружает ресурсы и обменивается данными |
| Client Hints | Наблюдались соответствующие параметры и Accept-CH | Браузер может предоставлять дополнительные сведения о среде |
| Canvas | Два вызова getImageData() | Скрипт читал пиксельные данные Canvas |
| Геометрия DOM | Измерительные API и свойства | Страница измеряла размеры или положение элементов |
| WebGPU | Вызов requestAdapter() | Скрипт запрашивал доступный графический адаптер |
| AudioContext | Вызовы OfflineAudioContext | Скрипт использовал API офлайн-аудиообработки |
| WebRTC | Обращения к API | В сессии присутствовал код, использующий WebRTC |
Что делать с результатами такого аудита
Для арбитражника технический аудит полезен прежде всего как способ понять, какие данные предоставляет браузер и какие события происходят во время работы сайта. Это помогает диагностировать ошибки, проверять приватность и исследовать поведение веб-приложений.Практический порядок работы:
- Зафиксировать версию браузера, операционную систему и конфигурацию исследуемой среды.
- Записать сетевые запросы и обращения к браузерным API в одной и той же сессии.
- Разделить наблюдения на хранилища, сетевой обмен, Client Hints, графические и аудиоинтерфейсы.
- Проверить временную последовательность событий и связь с действиями пользователя.
- Отделить подтвержденные факты от гипотез о назначении скриптов.
- Не делать вывод об ограничении аккаунта только по наличию определенного API.
- При проверке приватности исследовать реальные сетевые соединения и раскрываемые данные, а не только факт вызова API.
Вывод: браузер — это больше, чем User-Agent
Технический аудит показал, насколько насыщенной может быть одна веб-сессия: тысячи запросов, десятки сторонних доменов, обращения к локальным хранилищам и API, связанным с характеристиками браузера и возможностями устройства.Однако обнаружить механизм и доказать его использование для конкретной цели — разные задачи. Вызов Canvas не обязательно означает fingerprinting, запрос WebGPU не раскрывает автоматически точную модель GPU, а обращение к WebRTC не доказывает утечку IP-адреса.
Для грамотного анализа необходимо рассматривать не только отдельные API, но и контекст их использования, последовательность событий и реальные данные, переданные по сети.
Именно такой подход позволяет отделить технические факты от предположений и получить полезную картину работы веб-приложения без необоснованных выводов о внутренних алгоритмах платформы.
