Як під капотом працює відстеження цифрового відбитка

Кожен пристрій, що підключається до інтернету, залишає слід технічних артефактів — цифровий відбиток. У 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 Fingerprinting Guidance викладає найкращі практики відповідального використання сигналів браузера, і наша архітектура узгоджується з цими принципами. За хмарного розгортання вся обробка відбувається на вашій інфраструктурі. Жодні дані відвідувачів ніколи не потрапляють на наші сервери. Така архітектура спрощує відповідність GDPR, CCPA та іншим регуляціям приватності.