GPU & WASM Leak Test

Проверьте, раскрывает ли ваш GPU и WebAssembly аппаратные отпечатки, позволяющие отслеживать вас между сессиями

КАК ЭТО РАБОТАЕТ

Процесс определения аппаратного отпечатка

ОПРЕДЕЛЕНИЕ GPU

Определение WebGPU адаптера, features, limits

COMPUTE TIMING

Запуск GPU compute шейдеров, замер тайминга

WASM ПРОФИЛИРОВАНИЕ

Выполнение WASM бенчмарков, определение движка

КРОСС-ПРОВЕРКА

Сравнение сигналов с заявлениями браузера

GPU и WASM: сигналы, о которых забывают антидетект-браузеры

User-Agent врёт. Canvas-хеши рандомизируются. WebGL-renderer подменяется. Антидетект-браузеры построили целую индустрию на убедительной лжи JavaScript. Получалось, в основном, до 2023 года. В 2023 году Chrome выкатил WebGPU в дефолтные каналы. WebGPU отдаёт страницам vendor видеокарты, архитектуру, набор фич, лимиты ресурсов, и позволяет запустить настоящие compute-шейдеры на железе. Примерно тогда же исследования фингерпринтинга сдвинулись от "что говорит браузер" к "что говорит математика". WASM-модуль, скомпилированный V8, требует другого числа миллисекунд чем тот же модуль в SpiderMonkey. User-Agent тут роли не играет. Движок не выбирает себе характеристики производительности; сам движок и есть отпечаток. Дальше: что именно выкладывает наружу WebGPU, почему WASM-тайминг выдаёт JS-движок сквозь любые слои подмены, и как перекрёстная проверка этих сигналов ловит антидетект-браузеры за руку.

Что отдаёт WebGPU

Двадцать лет WebGL давал страницам аккуратный, ограниченный канал к видеокарте. Строка renderer. Vendor. Несколько расширений. Команда приватности браузеров получила годы на осмысление поверхности и подчистила большую её часть: расширения вроде CanvasBlocker могли чисто перехватить `WEBGL_debug_renderer_info`, чувствительные биты ушли за worker-only флаг, Tor Browser отрезал всё. WebGPU выкатился в 2023 с противоположной философией: максимум честности. Страница вызывает `navigator.gpu.requestAdapter()`, получает adapter-объект, читает: - `vendor`: Intel, NVIDIA, AMD, Apple, Microsoft (для software-fallback) - `architecture`: строка вида `"ampere"`, `"rdna-3"`, `"apple-m2"` - `device`: конкретное семейство чипов - `limits`: примерно 30 численных значений (max texture size, max workgroup count, max bind groups) - `features`: Set дополнительных возможностей (timestamp-query, shader-f16, depth-clip-control) Только словарь limits сам по себе серьёзно идентифицирующий. У RTX 3070 другой `maxStorageBufferBindingSize` чем у RTX 4080 чем у Apple M2 GPU. Значения пользователем не настраиваются, по дизайну меняться не должны, между сессиями на одной машине не меняются. Хеш limits плюс набор features ставит большинство потребительских GPU в когорты по десятки штук, не миллионы. Дальше compute. WebGPU позволяет странице отправить compute-шейдер и засечь время его выполнения. Запустить умножение матриц 1024×1024. Считать тайминг. Распределение специфично для GPU. Пропускная способность памяти, число ALU, тактовая частота, состояние теплового троттлинга, всё это сходится в одно миллисекундное число которое удивительно стабильно для конкретной машины. Команды приватности браузеров эту историю до конца ещё не написали. Поверхность уже отгружена, исследования фингерпринтинга отстают на год-два. Тот же зазор что у новых лекарств, опережающих длинные клинические исследования: молекула уже в аптеках, популяционные данные ещё впереди.

WASM как детектор движка

JS-движки это огромные кодовые базы оптимизированные под разные задачи. V8 затачивается на throughput длительно работающих скриптов. SpiderMonkey делает ставку на более быстрый compile-tier-up. JSC (Safari) тяжело анализирует типы заранее. Три философии, три тайминговых отпечатка. Один и тот же стандарт, три разных темпа. Самый чистый сигнал: оверхед JS-к-WASM вызова. Вызов WASM-функции из JavaScript требует моста через границу движка. Мост V8 заточен под мономорфные call-sites и в прогретом состоянии работает примерно за 50 наносекунд. Мост SpiderMonkey ближе к 400 наносекундам. JSC между ними но с большим разбросом. 10000 вызовов, замерил суммарное время, поделил. Цифра выдаёт движок без единого вопроса к браузеру. Compile/validate-соотношение это другая улика. У каждого движка свой баланс между baseline-компиляцией (быстрая, исполнение медленное) и tier-up до оптимизированного кода. Liftoff в V8 справляется с 1MB модулем за 10мс. BaselineCompiler в SpiderMonkey тратит примерно 25мс. Интерпретатор JSC ещё дольше, но компиляцию пропускает совсем. Латентность WASM memory.grow это третий канал. V8 заранее mmap-ает виртуальный регион и расширяет переотображением. SpiderMonkey выделяет свежий кусок и копирует. Разница задержки на росте с 4MB до 8MB примерно 12мс против 200μс. Движок вычисляется только из этого числа. Почему это важно для фингерпринтинга: каждый коммерческий антидетект-браузер подделывает User-Agent, подменяет navigator-свойства, имитирует canvas-выход. Некоторые подменяют WebGL-renderer. Никто из них на 2026 год не умеет подделывать JS-к-WASM тайминг. Для этого пришлось бы поставлять кастомную сборку V8 с намеренными замедлениями, а все используют Chromium напрямую. Поэтому если профиль Firefox на Mac возвращает тайминги в форме V8, подмена вылезает за 100мс измерения.

Перекрёстная проверка ловит лжецов

Фингерпринтинг по одному сигналу хрупкий. Расширение, подмешивающее шум, может замутить любой одиночный канал. Перекрёстная проверка делает тест полезным: у честного браузера все сигналы согласуются. У подделанного хотя бы один противоречит остальным. Конкретные проверки которые стоит гонять: - WebGPU-vendor против WebGL-vendor. Обе API спрашивают GPU через разные пути драйвера. Должны вернуть одного вендора. Если WebGPU говорит Apple, а WebGL говорит NVIDIA, кто-то между страницей и железом переписывает строки. - Движок определён через WASM против заявленного User-Agent. UA говорит Safari, WASM говорит V8, значит Chrome в маске Safari. - Флаг software-renderer против заявленной архитектуры. Chrome на Linux без GPU откатывается на SwiftShader и сообщает `vendor: "Microsoft Basic Render Driver"`. Если страница видит этот vendor вместе с UA топового игрового компа, комп выдуманный. - Скорость GPU compute против заявленной мобильной платформы. iPhone-овые GPU дают примерно 1.5 TFLOPS. Бенчмарк WASM, заявляющий iPhone, но выдающий 4 TFLOPS на FP32, это косплей. - Хеш limits WebGPU против строки architecture. У каждого семейства GPU фиксированные значения limits; если architecture говорит `"ampere"` а хеш limits соответствует RDNA-3, подмена коснулась только видимой строки. Та же логика что у полиграфа: ни один канал по отдельности не надёжен, но несоответствия между каналами это диагностика. Железо не врёт. Драйвер не врёт. JIT-компилятор не врёт. Самоотчёт браузера это единственный кусок в этом стеке у которого есть стимул врать, поэтому именно его стоит подозревать. Сканер GPU/WASM-утечек в WHOX гоняет все пять перекрёстных проверок, показывает какая с какой не сходится, и даёт конкретный указатель на каком слое подмены вы сейчас находитесь. Полезно для проверки антидетект-настроек и для подтверждения, что вы реальное устройство, когда это действительно так.

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Что такое GPU fingerprinting?

GPU fingerprinting идентифицирует ваше устройство, измеряя уникальные характеристики графического оборудования — паттерны compute timing, поддерживаемые features, точность шейдеров и лимиты памяти. Эти сигналы сохраняются между сессиями и практически невозможно подделать.

Может ли WebAssembly раскрыть движок браузера?

Да. Разные JavaScript-движки (V8/Chrome, SpiderMonkey/Firefox, JSC/Safari) выполняют WASM с измеримо разными паттернами тайминга. Только overhead вызовов JS↔WASM может отличаться в 8 раз между движками.

Чем это отличается от canvas fingerprinting?

Canvas fingerprinting захватывает результат рендеринга. GPU/WASM fingerprinting измеряет вычислительное поведение — паттерны тайминга, точность шейдеров, скорости доступа к памяти. Это сигналы аппаратного уровня.

Все наши тесты

Запускайте весь набор WHOX из одного блока: проверки утечек, fingerprint-пробы, сетевую диагностику, репутацию IP и тесты приватности.