Canvas и WebGL ломаются не спуфингом, а аномалиями в распределении признаков

Canvas и WebGL ломаются не спуфингом, а аномалиями в распределении признаков

Разберем энтропию данного параметра: антифрод смотрит не на один hash, а на связку Canvas, WebGL vendor/renderer, extensions, precision, DPR, font metrics и поведение GPU-стека. Если менять только Canvas, а WebGL оставить «чистым», корреляция разъезжается быстрее, чем сам отпечаток.

Для Canvas безопаснее не рисовать «случайный шум», а вносить микросмещение на уровне рендер-пайплайна: одинаковый патч для чтения пикселей, стабильный на одной сессии, но с небольшой вариативностью между профилями. Любой рандом по каждому вызову дает детект на уровне сетевого стека и JS-таймингов: один и тот же скрипт начинает получать разные массивы при повторных чтениях.

По WebGL логика та же. Под капотом Chromium API важна не только подмена strings, но и согласованность: supported extensions, precision format, UNMASKED_VENDOR_WEBGL, UNMASKED_RENDERER_WEBGL, поведение readPixels и наличие типичных ограничений конкретного GPU. Если заявлен один стек, а shader precision и лимиты буферов ведут себя как другой, это видно в CreepJS и BrowserLeaks без особого труда.

Рабочая схема одна: фиксировать профиль на уровне всей графической подсистемы, проверять Canvas/WebGL парой, а не отдельно, и не трогать параметры, которые вы не умеете согласовать в цепочке. Спуфинг через инъекцию JS-кода без модели консистентности почти всегда оставляет след; устойчивым считается только тот отпечаток, где все поля согласуются между собой.