Фінгерпринтинг WebGPU: наступне покоління після Canvas і WebGL

WebGPU з’явився у Chrome 113 у 2023 році. До 2026-го він доступний в усіх основних браузерах на всіх основних платформах. На відміну від WebGL — браузерного API, обгорнутого навколо OpenGL ES 2.0, — WebGPU є прямим інтерфейсом до сучасних графічних API: Vulkan у Linux, Metal у macOS, DirectX 12 у Windows.

Це змінює те, що браузер може дізнатися про залізо під ним. Фінгерпринтинг на Canvas і WebGL спирався на результати рендерингу. WebGPU дозволяє напряму запитувати можливості самого GPU, розкриваючи архітектурні деталі, на які вивід рендерингу може лише натякати.

Для фінгерпринтингу це стрибкоподібне поліпшення якості сигналу.

Що розкриває WebGPU і не розкриває WebGL

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

WebGPU дає об’єкти GPUAdapter і GPUAdapterInfo із суттєво багатшими даними:

• Vendor — ідентифікатор виробника GPU (NVIDIA, AMD, Intel, Apple, Qualcomm).
• Architecture — родина архітектури GPU (Ampere, RDNA 2, Xe-LP, Apple M2, Adreno).
• Device — конкретна модель, якщо вона доступна.
• Description — людиночитний рядок.

Крім ідентифікації, WebGPU розкриває ліміти GPU — точні числові характеристики заліза. Їх можна запитати через інтерфейс GPUSupportedLimits, і включають вони понад 30 числових властивостей:

• Максимальні розміри текстур — maxTextureDimension2D
• Максимальний розмір буфера — maxBufferSize
• Максимальна кількість bind-груп — maxBindGroups
• Максимальні розмірності compute-workgroup
• Максимальна кількість вершинних атрибутів
• Вимоги до вирівнювання storage-буферів

Кожне з цих значень задає драйвер GPU, виходячи з можливостей заліза. У різних поколінь GPU — навіть в одного вендора — різні комбінації лімітів. У GPU 2019 року ліміти не такі, як у GPU 2023 року з тієї самої родини.

Чому це важче підробити

Антидетект-браузери підробляють Canvas і WebGL, перехоплюючи виклики API та підмінюючи результати. Повернення Canvas — це хеші відмальованих пікселів: браузер може відмалювати, а потім підмінити хеш. У WebGL запитується невелика кількість рядків, які можна замінити цілком.

З WebGPU інакше. Поверхня API велика — сотні методів і властивостей. Кожному виклику потрібне правдоподібне значення. Шар підробки зобов’язаний:

• Тримати узгоджену ідентичність за всіма числовими лімітами — GPU, що видає себе за NVIDIA RTX 4090, має повертати кожне значення ліміту, яке відповідає цьому залізу.
• Давати раду з реальним виконанням обчислень. WebGPU дозволяє запускати compute-шейдери. Якщо шар підробки заявляє високу продуктивність, але видає повільні обчислення, розбіжність виявляється за таймінгами.
• Стежити за змінами між версіями драйверів. У кожної версії драйвера GPU ліміти трохи різняться. Статичні таблиці підробки застарівають із виходом нових драйверів.

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

Продуктивність обчислень як відбиток

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

Бенчмарк перебору хешів, множення матриць або близька до рендерингу обчислювальна задача виконуються зі швидкістю, яку визначає залізо. Двоє відвідувачів, що заявляють ту саму модель GPU, але показують різну швидкість обчислень, брешуть про залізо.

Така техніка повністю обходить статичну підробку відбитка. Відвідувач може заявити будь-який рядок GPU. Але не може заявити продуктивність обчислень, якої не має.

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

Доступність функцій як сигнал

WebGPU розкриває опційні функції через GPUAdapter.features. Деякі GPU підтримують конкретні розширення:

• timestamp-query — потребує сучасного GPU з лічильниками продуктивності
• shader-f16 — половинна точність із рухомою комою, часто трапляється в мобільних GPU
• texture-compression-bc — Block Compression, стандарт для десктопа
• texture-compression-etc2 — мобільний формат стиснення текстур
• texture-compression-astc — мобільний формат стиснення текстур

Набір функцій детермінований для кожної моделі GPU. Машина на Windows, що заявляє мобільні функції Adreno, попадається. Мобільний пристрій, що заявляє суто десктопні формати стиснення, попадається.

Узгодженість із WebGL

До WebGPU браузери мали одну основну поверхню запитів до GPU — WebGL. Тепер їх дві, і вони мусять збігатися.

WebGL і WebGPU розкривають той самий GPU. Їхні відповіді мають бути несуперечливими. Браузер, який через WebGL повідомляє NVIDIA RTX 4080, але повертає ліміти WebGPU, що відповідають вбудованому Intel, на реальному залізі неможливий.

Узгодженість між API — ще один сигнал для детекції. Підробити один API просто. Підробити два API взаємно несуперечливо — помітно складніше, і нинішні антидетект-браузери здебільшого цього не роблять.

Що WebGPU розкриває про ОС і драйвер

Крім ідентифікації GPU, WebGPU розкриває контекст графічного стека:

• У Windows за WebGPU видно, чи використовується Direct3D 11, чи Direct3D 12, а це корелює з версією ОС і поколінням драйвера.
• У macOS підтримувана версія Metal видає версію macOS — бо версії Metal постачаються з оновленнями системи.
• У Linux рівні підтримки Vulkan видають дистрибутив і походження драйвера (наприклад, пропрієтарний NVIDIA проти відкритого Mesa).

Жоден із цих сигналів не є прямим — кожен потребує інтерпретації. Але разом вони складаються в картину програмного стека, яка має корелювати із заявленим відбитком браузера. Розбіжності вказують на підробку.

Терміни впровадження у стеки детекції

У 2026 році фінгерпринтинг WebGPU ще не став масовою технікою детекції — із трьох причин:

1. Підтримка в браузерах усе ще стабілізується. WebGPU у Firefox вийшов у 2024-му, але з обмеженим покриттям функцій. У Safari WebGPU вийшов у 2024-му, але з лімітами, відмінними від Chrome. Системам детекції потрібне широке покриття, перш ніж покладатися на сигнали WebGPU.
2. Реальна підтримка WebGPU в користувачів усе ще неповна. У старих пристроїв немає GPU з підтримкою функцій WebGPU. Система детекції, яка штрафує відвідувачів без WebGPU, ризикує блокувати легітимних користувачів на п’ятирічному залізі.
3. Антидетект-браузери ще не збудували повноцінну підробку WebGPU, а отже, сигнали на його основі зараз ефективні проти витончених атакувальників, упевнених, що вони замели сліди. Це зміниться в міру зростання впровадження детекції та відповідного доопрацювання інструментів підробки.

Горизонт впровадження у 2–3 роки виглядає реалістично. До 2027–2028 років сигнали WebGPU стануть для детекції ботів такими ж центральними, як сьогодні WebGL. Питання для команд детекції — коли починати збирати дані WebGPU, і відповідь тут: зараз, щоб на момент, коли ці сигнали стануть основними, вже була історична база.

Що це означає для тих, хто захищається

Фінгерпринтинг на Canvas — зріла техніка. Фінгерпринтинг на WebGL — зріла техніка. Обидві активно підробляються антидетект-інструментами, і з прийнятним для атакувальників успіхом.

Фінгерпринтинг на WebGPU — техніка молода. Інструменти підробки за нею не встигли. Це створює вікно — імовірно, 18–36 місяців, — у якому сигнали WebGPU чисто відділяють справжніх користувачів від витончених ботів. У це вікно варто вкластися.

Сигнали, які він дає, до того ж структурно важче підробити, ніж Canvas чи WebGL. Рендеринг можна перехопити. Продуктивність обчислень — ні. Про набори функцій можна збрехати, але не узгоджено по всій поверхні API. Кожне покоління технік фінгерпринтингу підвищує ціну підробки. WebGPU підвищує її суттєво.

Для платформ, які серйозно ставляться до детекції ботів у 2026 році й далі, сигнал зміщується саме у бік WebGPU.