Як насправді працює device fingerprinting: інженерія вердикту за 50 мс

Про device fingerprinting часто говорять маркетинговими термінами й значно рідше — інженерними. Маркетингові формулювання розпливчасті: «130 сигналів», «99,5% точності», «поліморфна детекція». Інженерні деталі, що справді важливі для оцінки того, чи працює система фінгерпринтингу, зазвичай приховані.

Цей матеріал — інженерна версія, написана для технічних осіб, які ухвалюють рішення на платформах SaaS, iGaming, AdTech і FinTech. Аудиторія — продакт-менеджери, керівники інженерних команд і архітектори безпеки, яким треба розуміти, що відбувається під капотом, коли вони оцінюють доцільність розгортання шару device intelligence.

Структура така: що збирається, як сигнали складаються у стабільний ідентифікатор, як система працює з privacy-first браузерами, чому важливий поліморфний код і як архітектурні рішення перетворюються на показники затримки й точності, що їх обіцяє маркетинг постачальників.

Що насправді означає «device fingerprint»

Device fingerprint — це імовірнісний ідентифікатор, побудований із багатьох невеликих шматочків інформації про пристрій, браузер і мережеве середовище. Кожен шматочок окремо дає мало унікальності. У поєднанні за достатньою кількістю вимірів вони ідентифікують пристрій із дуже високою ймовірністю.

Інтуїція така: будь-яка окрема характеристика браузера — скажімо, роздільна здатність екрана — має приблизно 5 біт ентропії на всю сукупність пристроїв в інтернеті. Помножте це на 50 таких характеристик — і ви маєте 250 біт теоретичної ентропії, набагато більше, ніж потрібно для ідентифікації будь-якого окремого пристрою на Землі. На практиці характеристики корелюють між собою, тож реальна ентропія нижча за теоретичний максимум. Але для будь-якої сучасної системи фінгерпринтингу сукупної ентропії достатньо, щоб ідентифікувати пристрої з надзвичайно високою точністю.

Імовірнісна природа важлива. Device fingerprints — це не гарантовані ідентифікатори на кшталт cookie чи облікових даних для входу. Це статистичні збіги: «цей пристрій із імовірністю 99,5% є тим самим пристроєм, який ми бачили три тижні тому». Ці 0,5% невизначеності мають значення в граничних випадках (пристрої зі значними змінами апаратного забезпечення, браузери, скинуті до заводського стану), але не мають значення для більшості продакшн-сценаріїв.

П'ять шарів сигналів

Сучасна система фінгерпринтингу збирає сигнали в кількох шарах, тому що кожен шар незалежно й по-своєму стійкий до підробки, а їх поєднання підробити важче, ніж будь-який окремий шар.

Шар 1: характеристики браузера

Найбазовіший шар. JavaScript збирає спостережувані властивості середовища браузера:

Рендеринг canvas. Намалюйте складну фігуру на елементі canvas, захешуйте отримані пікселі. Різні браузери, драйвери GPU, рушії рендерингу шрифтів і налаштування згладжування дають дещо різний результат. Хеш canvas стабільний для конкретного пристрою, але відрізняється між пристроями.

Сигнатура WebGL. Опитайте рендерер WebGL про його vendor, рядок renderer, підтримувані розширення й виконайте невеликі графічні операції, вихід яких відображає характеристики GPU. WebGL дає більше ентропії, ніж canvas, бо різноманіття GPU велике.

Список шрифтів. Визначте, які шрифти встановлено, вимірюючи ширину відрендереного тексту в конкретних шрифтах. Різні інсталяції ОС мають різні набори шрифтів, стабільні для конкретного пристрою, але відмінні між пристроями.

Властивості екрана. Роздільна здатність, глибина кольору, щільність пікселів, наявність сенсорного вводу. Окремо — помірна ентропія; у поєднанні — значуща.

Властивості Navigator. Рядок User-Agent, мовні налаштування, ідентифікація платформи, список плагінів (де він ще доступний), підказка hardware concurrency.

Часовий пояс і локаль. Стабільні для конкретного користувача, відрізняються між користувачами.

Лише цей шар дає 15–20 біт ентропії в типових реалізаціях. Це також шар, який найлегше підробити anti-detect браузерам, що цілеспрямовано атакують саме ці сигнали.

Шар 2: апаратні сигнали

Глибші сигнали, що залежать від реальної поведінки апаратного забезпечення, а не від значень, які повідомляє браузер:

Фінгерпринт AudioContext. Згенеруйте звук через Web Audio API, дослідіть вихідний буфер. Реальне аудіообладнання дає дещо інший вихід із плаваючою комою, ніж віртуалізовані середовища. Сигнал невеликий, але стійкий до підробки на боці клієнта.

Дрейф годинника в реальному часі (clock skew). Виміряйте часові характеристики різних операцій. Реальні споживчі пристрої мають розкид через JIT-компіляцію, збирання сміття та переривання рівня ОС. Хмарні браузери у віртуалізованих середовищах зазвичай надто рівні.

Дані сенсорів на мобільних. Значення акселерометра, гіроскопа, магнітометра під час взаємодії. Реальне користування пристроєм дає безперервну варіацію виходу сенсорів. Симульовані середовища часто не відтворюють це реалістично.

Performance API. Виміряйте час виконання конкретних обчислювальних патернів. У реальних GPU є характерні патерни з плаваючою комою, які важко підробити на роздільній здатності менш ніж мілісекунда.

Battery API (де підтримується). Відсоток заряду батареї та стан заряджання. Реальні пристрої мають реалістичні патерни батареї; хмарні інстанси часто показують 100% заряду без варіації.

Цей шар дає ще 5–10 біт ентропії й стійкіший до підробки, ніж шар браузера, бо залежить від реальної поведінки апаратного забезпечення, а не від повідомлених значень.

Шар 3: мережеві характеристики

Сигнали, спостережувані з боку сервера, незалежно від того, що повідомляє JavaScript на клієнті:

TCP fingerprint. Мережеві стеки мають характерні патерни у форматуванні TCP-пакетів — розміри вікон, порядок опцій, прапорці за замовчуванням. Фінгерпринт із високою впевненістю ідентифікує мережевий стек ОС і не може бути підроблений на рівні JavaScript.

TLS fingerprint (хеші JA3/JA4). Повідомлення TLS ClientHello містить уподобання щодо наборів шифрів, розширення та переваги еліптичних кривих у певному порядку. Різні бібліотеки TLS дають різні патерни. Захешуйте це у формат JA3 або JA4 — і ви маєте стабільний ідентифікатор мережевого рівня.

Порядок фреймів HTTP/2. Ініціалізація з'єднання HTTP/2 має патерни, специфічні для реалізації. Різні бібліотеки (Chrome, Firefox, Safari, Python requests, Go HTTP тощо) дають ледь помітно різні патерни.

Патерни таймінгів запитів. Реальні споживчі з'єднання мають змінну затримку залежно від умов мережі, NAT-трансляції, маршрутизації провайдера. Хмарна автоматизація має рівніші патерни таймінгів через високоякісні мережеві шляхи.

ASN і репутація IP. Чи належить IP-адреса, що підключається, споживчому провайдеру, дата-центру, VPN-сервісу, резидентному проксі чи відомому постачальнику інфраструктури для автоматизації. Важливо для відрізнення реальних користувачів від автоматизації.

Цей шар критично важливий, бо працює на боці сервера, де підробка на боці клієнта не діє. Клієнт може брехати про те, який браузер він запускає; мережеві пакети розкривають, який стек їх насправді створив.

Шар 4: поведінкові сигнали

Патерни взаємодії користувача з часом:

Рух миші. Кривизна, прискорення, тремтіння (jitter). Реальний людський рух миші має характерні патерни шуму на роздільній здатності менш ніж мілісекунда, які важко відтворити в автоматизації.

Динаміка натискань клавіш. Час між клавішами, патерни виправлення помилок, використання клавіш-модифікаторів. Різні люди мають різний ритм набору. Автоматизація зазвичай дає патерни або надто рівні (на основі скриптів), або надто чисті (деякі на основі агентів).

Патерни прокручування. Швидкість, прискорення, паузи, зміни напрямку. Реальне читання дає характерні патерни прокручування; автоматизація часто прокручує математично рівними інтервалами.

Таймінг заповнення форм. Час між подіями фокуса, переходами по Tab, завершенням полів. Люди заповнюють форми з характерними паузами; автоматизація схильна або заповнювати миттєво, або заповнювати підозріло рівними інтервалами.

Цей шар окремо дає помірну ентропію, але добре поєднується з іншими шарами для виявлення конкретних категорій атак (особливо credential stuffing і захоплення облікових записів).

Шар 5: узгодженість середовища

Перехресні перевірки узгодженості між шарами. Ключова ідея: окремі сигнали можна підробити, але узгоджено підтримувати консистентність між усіма сигналами значно важче.

Приклади неузгодженості:

• JavaScript стверджує «Chrome 120 на macOS», але рендерер WebGL повідомляє про драйвери Mesa (індикатор Linux/Wayland)
• TCP fingerprint відповідає Linux-серверу, але середовище JavaScript стверджує, що це iOS
• Аудіофінгерпринт відповідає Windows, але список шрифтів відповідає macOS
• Заявлений часовий пояс відповідає Тихоокеанському, але патерни мережевої затримки відповідають європейській маршрутизації

Інструменти підробки ретельно обробляють окремі сигнали. Підтримання узгодженості між усіма сигналами одночасно вимагає більшої витонченості, ніж має більшість інфраструктур для автоматизації. Саме цей шар ловить більшість сучасних спроб обходу.

Як сигнали стають стабільним ідентифікатором

Сирі сигнали не ідентифікують пристрій напряму. Системі треба перетворити їх на стабільний ідентифікатор, що переживає звичайні зміни пристрою (оновлення браузера, оновлення ОС, епізодичні зміни IP, заміну одного компонента апаратного забезпечення).

Архітектурний патерн:

Обчислення фінгерпринта. Об'єднайте сигнали у високовимірний вектор, що представляє поточне спостереження пристрою.

ML-зіставлення. Порівняйте поточний фінгерпринт із раніше баченими фінгерпринтами в базі даних системи. Використовуйте модель, натреновану розпізнавати пристрої попри поступові зміни: той самий ноутбук із оновленням браузера має збігтися з попереднім спостереженням; інший ноутбук зі схожими характеристиками — ні.

Присвоєння ідентифікатора. Коли збіг існує з високою впевненістю — присвойте наявний Visitor ID. Коли збігу немає — створіть новий Visitor ID. Коли є частковий збіг із непевною впевненістю — позначте для додаткової перевірки.

Підтримання кластера. У міру накопичення спостережень система вивчає природну варіацію кожного пристрою. Фінгерпринт «вашого ноутбука» — це не фіксоване значення, а кластер спостережень, що повільно дрейфує з часом у міру еволюції браузера, ОС і мережевого середовища.

Математичні основи добре зрозумілі. Для точності важливі деталі реалізації. Погано налаштована модель зіставлення дає або високий рівень хибнопозитивних спрацювань (різні пристрої ідентифіковані як один), або високий рівень хибнонегативних (той самий пристрій ідентифіковано як різні між візитами). Обидві помилки шкодять сценарію використання.

Заявлена точність «99,5%» стосується частки, з якою пристрій, що повертається, коректно зіставляється зі своїм попереднім Visitor ID у вікні 30 днів. Зрілі системи цього досягають; незрілі — не дотягують. Метрика, про яку варто питати постачальників, — це точність у часовому горизонті, а не заголовкове число.

Чому важливий поліморфний код

Конкретне архітектурне рішення, що відрізняє зрілі системи фінгерпринтингу від менш зрілих: клієнтський JavaScript, який збирає сигнали, регулярно змінюється.

Причина: постачальники anti-detect браузерів реверс-інжинірять скрипти детекції й випускають патчі, що повертають правильні значення для відомих проб. Зі статичним клієнтським кодом обхід, випущений проти скрипта детекції, працює необмежено довго, доки скрипт не зміниться.

Поліморфна доставка це змінює:

• Скрипт детекції генерується на вимогу з пулу 50–100+ варіантів на кожну пробу
• Кожен клієнт отримує унікальну комбінацію під час завантаження сторінки
• Імена функцій, імена змінних, порядок перевірок рандомізовані
• Обфускація коду ускладнює статичний аналіз

Результат: постачальники anti-detect не можуть випустити один патч, що обходить усі варіанти. Їм доводиться випускати динамічні патчі, що адаптуються до конкретного отриманого коду, а це набагато складніше. Вікно обходу скорочується з місяців до днів.

Реалізація вимагає керування варіантами на боці сервера й клієнтського коду, стійкого до налагодження (пастки anti-debugger, код, що виявляє інструменти розробника браузера). Це інженерна інвестиція, але саме вона відрізняє детекцію, що витримує, від детекції, яку обходять протягом кількох тижнів після будь-якого оновлення.

Заявлена затримка 50 мс

Маркетингові матеріали часто наводять заяви про затримку. Інженерні реалії, що стоять за вердиктом у 50 мс:

Куди йде час:

• Збір сигналів на боці клієнта: 10–30 мс (деякі сигнали вимагають асинхронного вимірювання)
• Мережевий round-trip до сервісу верифікації: 5–15 мс (залежить від гео)
• Зіставлення фінгерпринта на боці сервера: 5–15 мс
• Застосування логіки вердикту: 1–5 мс
• Мережевий round-trip назад до клієнта: 5–15 мс

Разом: 26–80 мс залежно від географічного розташування й набору сигналів. Заява про 50 мс стосується типового випадку в добре розподіленому розгортанні.

Що шкодить затримці:

• Синхронний збір сигналів, що блокує рендеринг сторінки
• Запити до бази даних проти великих історичних наборів фінгерпринтів без належної індексації
• Розгортання в одному регіоні, що змушує до довгих мережевих round-trip
• Неефективне обчислення сигналів (деякі сигнали вимагають кількох round-trip через рушій JavaScript)

Що допомагає затримці:

• Асинхронний збір сигналів, що виконується у фоні
• Верифікація, розгорнута на edge (обробка сигналів близько до користувача)
• Оптимізоване зіставлення фінгерпринтів за допомогою алгоритмів наближеного пошуку найближчих сусідів
• Кешування для відвідувачів, що повертаються

Ціль 50 мс досяжна для належно спроєктованих систем. Повільніші системи існують (деякі заяви постачальників про затримку 200–500 мс відображають недостатню інженерію, а не фундаментальні обмеження).

Сумісність із privacy-first браузерами

Основні браузери постачають функції приватності, покликані обмежити відстеження. Зокрема Privacy Sandbox у Chrome, Intelligent Tracking Prevention у Safari, Enhanced Tracking Protection у Firefox. Питання: чи працює фінгерпринтинг у цьому середовищі?

Відповідь вимагає розрізнення двох сценаріїв:

Крос-сайтове відстеження. Ідентифікація користувачів на кількох незв'язаних сайтах для реклами чи аналітики. Саме на це передусім націлені функції приватності. Сторонні cookie блокуються. Деякі проби фінгерпринтингу обмежуються (рандомізація canvas, зміни в перелічуванні шрифтів). Сценарій крос-сайтового відстеження справді ускладнюється.

First-party ідентифікація. Платформа ідентифікує власних відвідувачів на власному сайті з міркувань безпеки й запобігання шахрайству. Функції приватності цього не обмежують — і не можуть, не зламавши базову функціональність вебу. First-party ідентифікація пристрою й далі працює, бо не потребує крос-сайтових механізмів, які обмежують функції приватності.

Фінгерпринтинг для запобігання шахрайству належить до другої категорії. Платформа ідентифікує власних відвідувачів на власних сторінках. Функції приватності, націлені на крос-сайтове відстеження, на цей сценарій не впливають.

Втім, архітектурний акцент зміщується. Сучасні системи фінгерпринтингу надають більше ваги серверним сигналам (TCP/TLS-фінгерпринтинг, мережева поведінка) і менше ваги клієнтським пробам, які в майбутньому можуть бути обмежені. Системи, побудовані для privacy-first світу, адаптуються чисто; системи, побудовані навколо статичних клієнтських проб, мають еволюціонувати.

Що це означає для оцінки

Якщо ви оцінюєте постачальників device intelligence, ось інженерні питання, що дають інформативні відповіді:

Питання 1: яке у вас покриття сигналів за шарами? Постачальники, що зосереджені лише на сигналах шару браузера, вразливі до обходу anti-detect браузерами. Багатошарове покриття з мережевими й поведінковими сигналами витримує краще.

Питання 2: як ваша модель зіставлення працює з поступовими змінами пристрою? Постачальники з наївним зіставленням (будь-яка зміна сигналів = інший пристрій) дають високий рівень хибнонегативних спрацювань. Зрілі моделі зіставлення коректно обробляють дрейф.

Питання 3: чи постачаєте ви поліморфний клієнтський код? Статичний клієнтський код реверс-інжинірять і обходять. Поліморфний код відчутно важче обійти.

Питання 4: яка у вас затримка на нашому очікуваному обсязі? Затримка P99 під навантаженням — це справжня перевірка, а не маркетингові бенчмарки.

Питання 5: як ви працюєте з обміном сигналами між клієнтами? Анонімізований обмін сигналами між базами клієнтів ловить шахрайські операції, що охоплюють кілька платформ. Мережевий ефект постачальника — частина цінності.

Питання 6: як ваша заявлена точність деградує з часом? Постачальник, що заявляє 99,5% точності на 1-й день, має пояснити, яким є це число на 30-й, 90-й, 180-й день.

Ці питання виявляють постачальників, які зробили інженерну роботу, на противагу постачальникам із сильним маркетингом і слабким технічним фундаментом.

Де тут Tracio

Архітектура Tracio охоплює п'ять описаних вище шарів сигналів: характеристики браузера, апаратні сигнали, мережеві характеристики, поведінкові патерни та перевірки узгодженості середовища. Збір працює за 130+ сигналами на пристрій, а перехресна узгодженість між шарами є первинною поверхнею детекції.

Шар поліморфного JavaScript змінюється щодня. Модель зіставлення обробляє поступові зміни пристрою з точністю 99,5% на горизонті 30 днів. Вердикт — ALLOW, CHALLENGE або BLOCK — повертається менш ніж за 50 мс із доданими базовими сигналами для верифікації й налаштування.

Розгортання — це один SDK на сторінці й один серверний виклик verify у кожній точці ухвалення рішення. Безкоштовний тариф покриває 2500 верифікацій на місяць — достатньо, щоб провести повноцінну технічну оцінку на реальному трафіку.

Хочете побачити, як фінгерпринтинг Tracio працює з вашим конкретним трафіком?

Почніть безкоштовний пробний період — 2500 верифікацій безкоштовно, без банківської картки. Замовте демо, щоб разом із нашою командою розібрати технічну архітектуру й провести структуровану оцінку проти вашої конкретної моделі загроз.