WebGPU Atomic Fingerprint: як відеокарта стає новим джерелом даних для антифроду


12.08.26

Ще недавно GPU-фінгерпринтінг в браузері асоціювався насамперед з WebGL: сайт змушував браузер відмалювати задану сцену, аналізував результат і отримував додатковий сигнал для ідентифікації пристрою. Антидетект-браузери навчилися обходити такі перевірки давно — змінювали заявлені параметри, втручалися в рендеринг, додавали шуму чи просто підміняли результат. З приходом WebGPU історія стає набагато цікавішою.

Новий API дає веб-сторінці набагато пряміший доступ до обчислювальних можливостей графічного процесора — а значить, GPU перетворюється з пристрою для відтворення картинки на інструмент, якому можна дати роботу і подивитися, як він впорається. Для антифроду це важлива різниця. Одна справа - запитати браузер: "Яка у тебе відеокарта?". Зовсім інше – дати цій відеокарті завдання і поспостерігати за тим, як реальне залізо її виконує. Саме на цій ідеї будується WebGPU Atomic Fingerprint, розібраний у вебінарі Vektor T13.

Для звичайного користувача технологія майже непомітна. Натомість для розробників антидетект-браузерів, спеціалістів з мультиаккаунтингу і – все частіше – для інфраструктури браузерних AI-агентів вона становить серйозний інтерес. Чим активніша браузерна автоматизація переїжджає на VPS, віртуальні машини та серверні ферми, тим ширший розрив між тим, що браузер заявляє про свій пристрій, і тим, на якому обладнанні він насправді працює. WebGPU дає антифроду новий спосіб цей розрив намацати.

Старий підхід: спитати браузер, хто він такий

Класичний browser fingerprinting в основному побудований навколо читання характеристик оточення: який браузер, яка операційна система, який роздільна здатність екрану, які встановлені шрифти, як веде себе Canvas, який WebGL renderer доступний, які апаратні можливості повідомляє система. Слабке місце такого підходу є очевидним: якщо дані приходять через програмний інтерфейс, між сайтом і реальним пристроєм завжди є шар програмного забезпечення — а його теоретично можна змінити.

Саме цим і займаються антидетект-браузери: вони намагаються показати сайту узгоджений набір характеристик, який відрізняється від справжньої конфігурації машини. Фізично браузер може бути запущений на сервері, але сайт бачить профіль звичайного домашнього комп'ютера з Windows та популярною NVIDIA GeForce. На рівні простих API це цілком переконливо. Але варто поставити інше питання — не «що за пристрій переді мною?», а «нехай пристрій щось обчислить» — і починається зовсім інша гра.

Чому довгий хеш ще не відбиток

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

Тому при аналізі будь-якого чекера набагато корисніше дивитися не на кінцевий рядок, а на дані, з яких вона зібрана. Якщо сервіс бере стандартний набір WebGPU limits і features, більшість цих параметрів збігнеться на величезній кількості машин - такий хеш зручний для порівняння конфігурацій, але автоматично вважати його унікальним відбитком конкретної відеокарти не можна. Звідси проста, але важлива звичка: питати не «який хеш показав чекер?», а «що саме він вимірює?».

Від декларації до поведінки

Цінність WebGPU в тому, що він дозволяє перенести частину фінгерпринтінгу з галузі декларацій до галузі поведінки. Замість читання чергового параметра можна запустити обчислювальне завдання. У аналізованому тесті використовуються compute-шейдери та атомарні операції: безліч паралельних потоків працює із загальним лічильником через Atomic Add. Для звичайного розробника це лише механізм синхронізації паралельних обчислень. Для дослідника фінгерпринтінга цікаво інше — те, як саме GPU організує та планує цю паралельну роботу.

Сучасна відеокарта не зводиться до набору однакових обчислювальних блоків: за розподілом завдань стоїть складна апаратна та програмна архітектура, а на підсумкову поведінку впливають покоління GPU, драйвери, планувальник навантаження, налаштування продуктивності та особливості середовища. Виходить своєрідний експеримент. Сайт не питає «у тебе RTX 2080?» — він каже «ось завдання, виконай його» і потім аналізує профіль виконання. У цьому й суть: декларацію можна замінити на рядок, а поведінку реального обладнання підробити значно складніше.

Що це змінює для антидетект-браузерів

Візьмемо типову конфігурацію. Профіль повідомляє сайту, що користувач працює за звичайним домашнім комп'ютером з дискретною NVIDIA, User-Agent відповідає нормальному Chrome під Windows, решта параметрів теж підібрано акуратно. Але фізично браузер крутиться на VPS, де жодної заявленої відеокарти немає. До певного моменту це протиріччя вдається ховати лише на рівні API: запитали модель GPU — повернулося потрібне значення, перевірили WebGL renderer — прийшов узгоджений результат.

Обчислювальний тест ставить питання інакше: якщо заявлене залізо справді існує, чому фактична обчислювальна поведінка так на нього не схожа? Це не означає, що один WebGPU-тест здатний однозначно заявити "перед нами антидетект" - настільки примітивно антифрод майже ніколи не працює. Але з'являється ще один сильний сигнал і саме такі сигнали потрібні сучасним системам оцінки ризику. Причому найцікавіше тут зовсім не впізнати модель відеокарти, а знайти протиріччя: браузер запевняє одне, а поведінка заліза говорить інше. Саме внутрішні невідповідності цифрової особистості дедалі частіше цікавлять антифрод.

Чому 70% точності – це багато

У вебінарі цього підходу наводиться цифра близько 70% точності ідентифікації. Без опису методології її варто сприймати як універсальну характеристику будь-якого WebGPU Atomic Fingerprint, але сама постановка питання добре показує логіку антифрода. Людині збоку здається: «Усього 70%? Отже, тест ненадійний». Для антифроду це неправильна логіка - йому й не потрібний один ідеальний сигнал із стовідсотковою точністю.

Уявіть систему, яка одночасно бачить характеристики браузера, User-Agent, тип і репутацію IP, ASN, географію, параметри поведінки, Canvas, WebGL, WebGPU, продуктивність процесора і відеокарти, ознаки віртуалізації та історію облікового запису. Кожна ознака може помилятися, але їх комбінація дає зовсім інший результат. Це схоже на розслідування: один доказ рідко вирішує справу, а ось десяток незалежних фактів, що вказують в один бік, має зовсім іншу вагу. Тому навіть помірно точний апаратний сигнал виявляється по-справжньому корисним.

Чекер - це не антифрод

Для ринку антидетект-браузерів це окремий біль. Користувач відкриває публічний чекер, бачить зелені значення та робить висновок, що браузер перевірку пройшов. Але чекер та справжня антифрод-система вирішують різні завдання. Громадському чекер треба показати людині зрозумілий результат; реальна система може взагалі не розкривати, які сигнали вона збирає і яку вагу надає кожному. Більше того, їй не обов'язково звіряти ваш відбиток із якимось «правильним» еталоном — достатньо помітити статистично незвичайну комбінацію характеристик.

Тому при тестуванні антидетект-середовища правильне питання звучить не «чи я пройшов чекер?», а «чи відповідає фактична поведінка пристрою тому профілю, який бачить сайт?». Різниця між цими питаннями величезна.

Рандомізація теж залишає слід

Коли з'являється новий відбиток, перша реакція ринку передбачувана його потрібно рандомізувати. Для деяких типів відбитків це працює, але з обчислювальними характеристиками виникає фундаментальна проблема. Якщо зміна відбувається не природним чином, на рівні заліза та драйверів, а штучно – усередині браузера, – з'являється новий шар поведінки. І цей прошарок теж можна дослідити.

Замість питання «чи однаковий відбиток?» антифрод починає задавати інші: наскільки стабільним є результат, чи узгоджується він з іншими апаратними характеристиками, чи правдоподібно змінюється між запусками, чи здатна заявлена ​​модель GPU взагалі демонструвати таку поведінку. Виходить нескінченна гонка: ми ховаємо один сигнал — система починає аналізувати сам механізм його заміни. Саме тому примітивна рандомізація поступово входить у глухий кут: для стійкого профілю важливіше не випадковий результат, а внутрішня узгодженість середовища.

Тесту необов'язково вантажити відеокарту на 100%

Є ще одна важлива деталь. Коли мова заходить про GPU-фінгерпринтінг через обчислення, легко уявити важкий бенчмарк: розкручуються вентилятори, завантаження відеокарти стрибає до 100%, користувач відразу відчуває недобре. Але тесту не обов'язково бути важким. У демонстрації з вебінару Atomic Fingerprint виконується досить швидко і не викликає помітного стрибка навантаження - і це важливий момент.

Фінгерпринтінг не потрібно повноцінно вимірювати продуктивність відеокарти; для ідентифікації може вистачити невеликий, спеціально підібраного обчислювального завдання. З погляду сайту це зручно: тест вбудовується у звичайне завантаження сторінки, не перетворюючи візит в інтернет-магазин на запуск FurMark, а користувач може взагалі нічого не помітити. Саме тому WebGPU такий цікавий антифроду — він відкриває доступ до досить низькорівневих обчислень прямо з веб-сторінки, і для цього не потрібно встановлювати окрему програму.

Від мультиаккаунтингу до AI-агентів

Кілька років тому основною аудиторією подібних досліджень були розробники антидетект-браузерів, арбітражники та фахівці з мультиаккаунтингу. Зараз до них додалася ще одна величезна категорія – браузерні AI-агенти. Такому агенту постійно доводиться працювати зі звичайними сайтами: шукати інформацію, заповнювати форми, користуватися SaaS, керувати кабінетами, тестувати інтерфейси — зазвичай через Playwright, Chromium та інші фреймворки автоматизації. І запускається все це найчастіше не на ноутбуці користувача, а у хмарі.

Один сервер може тримати десятки браузерів: оркестратор створює і знищує контейнери, сесії мігрують між вузлами, кожному браузеру призначається свій профіль, і всі вони виглядають як окремі пристрої. Для класичної автоматизації цього зазвичай достатньо, а ось для серйозного device fingerprinting вже немає. Логічна ідентичність агента починає розходитися з фізичною ідентичністю машини: агент вважає себе одним пристроєм, browser profile описує інше, GPU належить третій інфраструктурі, IP приходить із четвертої мережі - і все це одночасно доступне системі оцінки ризику.

Звідси новий клас кореляційних сигналів. Уявіть платформу, яка паралельно запускає сотню браузерних агентів: у кожного свій профіль, свої cookies, локальне сховище та роздільна здатність екрану, так що на рівні програми це сто незалежних користувачів. Але всі вони можуть працювати на декількох однакових серверах. І якщо десятки незалежних пристроїв демонструють дуже схожу низькорівневу обчислювальну поведінку, у системи з'являється підстава запідозрити загальне джерело інфраструктури. Для мультиаккаунтинг це стара проблема в новій формі; для індустрії AI-агентів - проблема, масштаб якої тільки починає проявлятися. І стосується вона навіть тих, хто запускає агентів абсолютно легально: рано чи пізно доведеться розуміти, чому сайти сприймають таку інфраструктуру як підозрілу автоматизацію.

VPS все важче видавати за звичайний ПК

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

WebGPU Performance показує один бік питання — наскільки швидко виконуються певні операції GPU. Atomic Fingerprint додає іншу — як поводиться паралельне виконання. І подібних тестів з часом, швидше за все, буде все більше, причому не тільки для відеокарти: процесор, пам'ять, таймери, особливості планувальника, віртуалізація, графічний стек - сучасний браузер є величезною поверхнею для вимірювань.

WebGL нікуди не подінеться

У вихідному вебінарі WebGL-фінгерпринтінг описується як технологія, яка має поступитися місцем WebGPU, — і тут варто зробити уточнення. Поява сильнішого сигналу зазвичай не означає, що старий негайно перестають збирати: дешева додаткова ознака антифроду майже завжди корисна. Тому правильніше дивитися на WebGPU не як кнопку, яка «замінить WebGL», бо як наступний шар апаратного фингерпринтинга. WebGL дає одну групу ознак, WebGPU – іншу, performance-тест – третю, User-Agent та Client Hints – четверту. Антифрод не потрібно вибирати щось одне; сила системи саме у комбінації.

З тієї ж причини не рятує зворотний хід — повністю відключити WebGPU. Як прийом діагностики це корисно: можна порівняти поведінку сайту з API без нього і зрозуміти, чи залежить щось від його доступності. Але як постійна стратегія відключення працює гірше, адже відсутність технології це теж характеристика. Якщо WebGPU стає нормальною частиною сучасних браузерів, профіль з вимкненим API може виділятися на тлі масової конфігурації. До того ж WebGPU все частіше потрібен не для фінгерпринтінгу, а для графіки, обчислень і кількості веб-додатків, включаючи частину AI-навантажень прямо в браузері. Виходить знайома пастка: нескінченно підвищувати приватність простим відключенням API не вийде - у якийсь момент сам набір відключених можливостей перетворюється на відбиток.

Антифрод шукає не «погане», а дивне

Мабуть, це головне, що варто винести з історії з WebGPU. Антифрод часто представляють як набір детекторів: VPN – погано, proxy – погано, WebGPU mismatch – погано, автоматизація – погано. Реальні системи влаштовані цікавіше. Користувач корпоративної мережі цілком легально сидить за VPN; розробник працює усередині віртуальної машини; хмарний ігровий сервіс видає віддалений GPU; AI-агент визначення є автоматизацією. Тому одного факту недостатньо — система намагається зрозуміти контекст і оцінити, наскільки правдоподібною є вся комбінація цілком. І ось тут у погано зібраних середовищ починаються проблеми: браузер стверджує одне, GPU показує інше, продуктивність – третє, IP розповідає четверту історію, поведінка користувача – п'яту. Кожна характеристика окремо допустима, а разом виходить пристрій, який складно зустріти у реальному світі.

Саме тому доба статичних відбитків поступово закінчується. Ринок довго жив з уявленням, що fingerprint - це набір значень: Canvas hash, WebGL hash, AudioContext, шрифти, роздільна здатність екрану, hardware concurrency. Зібрали значення, склеїли – отримали ідентифікатор. Цікавіший напрямок сьогодні — active fingerprinting, коли сайт не просто запитує пристрій про характеристики, а дає йому завдання і спостерігає за реакцією. Це набагато ближче до поведінкової біометрії, тільки об'єктом стає не людина, а комп'ютер: як швидко виконується операція, як розподіляється паралельне навантаження, наскільки стабільним є результат, як система поводиться при зміні умов і чи відповідає все це заявленому залізу. Підробити відповіді такі питання відносно просто. Підробити цілу фізику поведінки системи набагато складніше.

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

Для розробників антидетект-браузерів висновок досить неприємний: робота з відбитками все глибше йде вниз по стеку. Простої зміни JavaScript API вже недостатньо – чим ближче вимір до реальної апаратної поведінки, тим важче побудувати правдоподібну абстракцію. Для фахівців з мультиаккаунтингу це означає, що якість інфраструктури стає важливішою за кількість перемикачів в інтерфейсі антидетекту: зелений чекер сам по собі нічого не гарантує. Арбітражним командам варто оцінювати інфраструктурний ризик окремо від якості IP та browser profile - дорогий residential proxy не виправляє протиріч на рівні пристрою.

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

WebGPU — це лише початок

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

Для фахівців це змінює сам підхід до фінгерпринтінгу. Головне питання тепер не «що браузер повідомляє про комп'ютер?», а «Чи відповідає поведінка комп'ютера тому, що повідомляє браузер?» - І різниця між ними величезна. У світі статичних відбитків можна було зосередитись на правильних значеннях; у світі активного фінгерпринтінга доведеться думати про правильну поведінку всього середовища. Тому WebGPU Atomic Fingerprint цікавий навіть тим, хто ніколи не має наміру писати власний GPU-чекер: він наочно показує, куди рухається сучасний антифрод — від перевірки окремих параметрів до перевірки внутрішньої узгодженості пристрою. Для арбітражника це означає, що дивитися тільки на IP та зелені індикатори вже недостатньо; для розробника антидетекта — що межа між браузером та залізом стає все важливішою; для інженера AI-агентів - що інфраструктура виконання сама перетворюється на частину ідентичності агента. А для антифроду це ще один спосіб задати пристрою просте питання: Ти дійсно той комп'ютер, за який себе видаєш?.

Ще не з нами?

Зареєструйтеся, щоб отримати доступ до всіх можливостей сайту.

Зареєструватися

Пов'язані публікації

Натискаючи "Прийняти", ви погоджуєтеся з тим, що Detect Expert може використовувати файли cookie для персоналізації контенту.

Ви завжди можете відмовитися від участі, дотримуючись інструкцій у нашому Cookie Policy.