Как работает отслеживание цифрового отпечатка изнутри

Каждое устройство, подключающееся к интернету, оставляет след из технических артефактов — цифровой отпечаток. В tracio.ai мы восстанавливаем этот отпечаток по более чем 130 пассивным сигналам, собранным за одну загрузку страницы, не полагаясь на cookie, localStorage или любую форму постоянного хранилища на стороне клиента. Эта статья подробно объясняет, как именно устроен этот процесс.

Слой сбора сигналов

Когда наш JavaScript-агент загружается в браузере посетителя, он начинает собирать сигналы сразу по нескольким категориям одновременно. Рендеринг canvas, запросы параметров WebGL, обработка через AudioContext, перечисление шрифтов и чтение свойств navigator — всё выполняется параллельно. Весь процесс сбора завершается менее чем за 50 миллисекунд на современном оборудовании.

Ключевая идея в том, что каждый сигнал фиксирует свой аспект аппаратного и программного стека устройства. Рендеринг canvas отражает GPU, драйвер и движок отрисовки шрифтов. Параметры WebGL раскрывают модель и возможности видеокарты. AudioContext выявляет различия в том, как аудио-DSP обрабатывает операции с плавающей точкой. Свойства navigator сообщают число ядер CPU, объём памяти, платформу и языковые настройки.

Наша команда измерила это на 2 миллиардах событий за прошлый месяц: медианное время сбора составило 38 мс, а 99-й перцентиль — 52 мс. Сначала мы действительно попробовали наивный подход — собирать сигналы последовательно. Он оказался в 40 раз медленнее. Параллельный сбор с ограничением по таймауту стал одним из первых архитектурных решений, которое мы приняли правильно.

TLS-фингерпринтинг: первый слой

Ещё до того, как наш JavaScript вообще выполнится, браузер уже раскрыл значимую информацию через TLS-рукопожатие. Сообщение Client Hello содержит наборы шифров, которые поддерживает браузер, используемые им TLS-расширения, предпочитаемые эллиптические кривые и принимаемые алгоритмы подписи. Эта информация определяется TLS-библиотекой браузера и существенно различается между семействами браузеров, версиями и операционными системами.

Мы снимаем этот TLS-отпечаток с помощью хеширования JA4 — современной замены JA3, дающей лучшую детализацию и стабильность между версиями. Один только хеш JA4 способен отличить Chrome от Firefox и Safari, а часто сужает идентификацию до конкретного диапазона версий браузера. В сочетании с нашими клиентскими сигналами он даёт слой перекрёстной проверки, который крайне трудно подделать.

Фингерпринтинг canvas и GPU

Фингерпринтинг canvas использует тот факт, что разные GPU отрисовывают одни и те же инструкции с едва заметными различиями на уровне пикселей. Canvas API позволяет нам отрисовать тщательно спроектированную сцену — конкретные текстовые строки в нескольких шрифтах, геометрические фигуры с определёнными координатами и градиенты с точными цветовыми переходами — а затем вычислить хеш от полученных пиксельных данных.

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

Аппаратное профилирование через WebGL

WebGL API

раскрывает подробную информацию о графической подсистеме, выходящую далеко за пределы строк renderer и vendor. Мы запрашиваем максимальные размеры текстур, форматы точности шейдеров, поддерживаемые расширения, размеры вьюпорта и десятки других параметров, которые различаются у разных моделей GPU и конфигураций драйверов.

Сочетание этих параметров создаёт подробный аппаратный профиль. Устройство с NVIDIA RTX 4070, например, сообщит иные максимальные размеры текстур, иную точность шейдеров и иную поддержку расширений, чем устройство с AMD RX 7800 XT. Этот аппаратный профиль по своей природе стабилен — он не меняется при обновлениях браузера, только при изменениях оборудования или драйверов.

Фингерпринтинг обработки аудио

Web Audio API предоставляет ещё один аппаратно-зависимый источник сигналов. Мы создаём узел-осциллятор, подключаем его к динамическому компрессору и измеряем выходной буфер. Различия в точности вычислений с плавающей точкой, реализации DSP и алгоритмах ресемплинга у разного аудиооборудования и операционных систем дают измеримые вариации в выводе.

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

Слияние сигналов и разрешение идентичности

Сырые сигналы шифруются и передаются на наш сервер, где движок идентификации устройств обрабатывает их через трёхуровневую систему хеширования. Аппаратные сигналы (canvas, WebGL, аудио) образуют Уровень 1 — стабильное ядро идентичности. Сигналы уровня браузера (детектирование возможностей, свойства CSS, медиавозможности) образуют Уровень 2, который обрабатывается через сопоставление между сессиями, чтобы учитывать ожидаемый дрейф от обновлений браузера. Изменчивые сигналы (user agent, часовой пояс, язык) образуют Уровень 3, внося вклад в оценку уверенности без влияния на решения об идентичности.

Алгоритм слияния взвешивает каждый сигнал по его уникальности и стабильности. Совпадение по редкому хешу canvas несёт куда больший вес, чем совпадение по распространённому разрешению экрана. Такой взвешенный подход гарантирует, что идентификация остаётся точной, даже когда часть сигналов меняется.

Ни хранилищ, ни cookie

Критически важный принцип проектирования нашей системы в том, что идентификация не зависит ни от какой формы хранилища на стороне клиента. Мы не устанавливаем cookie, не пишем в localStorage и не используем IndexedDB для целей отслеживания. Идентификатор посетителя целиком выводится из присущих устройству характеристик — оборудования, программного стека, сетевой конфигурации. Это означает, что идентификация переживает очистку cookie, режим инкогнито и даже переустановку браузера.

Приватность на уровне архитектуры

Поскольку мы собираем только технические атрибуты браузера — без истории посещений, без данных форм, без личного контента — влияние на приватность минимально. Руководство W3C по фингерпринтингу описывает лучшие практики ответственного использования браузерных сигналов, и наша архитектура соответствует этим принципам. При облачном развёртывании вся обработка происходит на вашей инфраструктуре. Данные посетителей никогда не попадают на наши серверы. Такая архитектура делает соблюдение GDPR, CCPA и других норм о приватности простым.