WebGL выдаёт железо не только через GL_RENDERER: ищем скрытые строки и шум

WebGL выдаёт железо не только через GL_RENDERER: ищем скрытые строки и шум

WebGL-фингерпринт редко строится на одном параметре. Анализируем энтропию параметров: GL_VENDOR, GL_RENDERER, UNMASKED_VENDOR_WEBGL, UNMASKED_RENDERER_WEBGL, а также список расширений и лимиты буферов. Браузерное окружение передает больше данных, чем кажется: даже одинаковые строки могут вести к разным профилям из-за сочетания GPU, драйвера и компоновщика.

Ключевой риск — несогласованность. Если vendor string указывает на один стек, а extension-set и precision formats — на другой, это выглядит как подмена или прокси-слой. Разбираем сигнатуру на уровне syscall косвенно: не через системные вызовы, а через следы, которые оставляет графический бэкенд в доступных WebGL API. Особенно заметны аномалии в max texture size, anisotropy, aliased line width range и supported shader precision.

Проверять надо не один вызов, а связку: canvas hash, WebGL context attributes, строки из getParameter, поведение getExtension и стабильность ответа между вкладками. Скрытность — это не отсутствие следов, это шум, сливающийся с фоном. Если профиль «слишком чистый», с одинаковыми ответами на редкие запросы, детектор видит не человека, а шаблон.

Практика здесь одна: не маскировать только Renderer, а выравнивать весь графический профиль, включая редкие параметры и порядок ответов. Иначе любой несостыкованный vendor string становится маркером, который переживает очистку cookies и смену IP.