GL_RENDERER и Vendor strings: как браузер сам раскрывает графический стек

GL_RENDERER и Vendor strings: как браузер сам раскрывает графический стек

WebGL-отпечаток редко ограничивается одним значением. Внутри запроса сидят GL_VENDOR, GL_RENDERER, GL_VERSION, shading language, а иногда и расширения, которые выдают не только GPU, но и слой абстракции вокруг него. Браузерное окружение передает больше данных, чем кажется: одна строка может указывать на железо, другая — на драйвер, третья — на виртуализатор или софт-рендер.

Смотрим на три слоя сигнала:
— GL_RENDERER часто несет модель или псевдоним, по которому видно аппаратную конфигурацию;
— GL_VENDOR показывает производителя стека, и это не всегда совпадает с реальным железом;
— UNMASKED_VENDOR_WEBGL и UNMASKED_RENDERER_WEBGL через расширение дают более «чистый» срез, если API не замаскирован.

Анализируем энтропию параметров. Опасны не сами строки, а их сочетания: мобильный GPU с десктопным набором шейдеров, странный vendor при обычном renderer, отсутствие ожидаемых расширений. Такие несостыковки чаще всего всплывают в антифроде как признак эмуляции, удаленного рендера или патченного профиля.

Что проверять вручную:
• совпадает ли renderer с платформой и типом устройства;
• не противоречат ли строки WebGL данным canvas и audio;
• есть ли одинаковый стек у нескольких профилей, где он быть не должен;
• не ломается ли значение после пересоздания контекста.

Разбираем сигнатуру на уровне syscall, когда нужно понять не только «что отдал API», но и «почему оно вообще так отдалось». Если строки выглядят слишком аккуратно, это тоже сигнал. Скрытность — это не отсутствие следов, это шум, сливающийся с фоном.