Эмуляция CPU, RAM и GPU: где антифрод ловит несоответствие за один запрос

Эмуляция CPU, RAM и GPU: где антифрод ловит несоответствие за один запрос

Аппаратные признаки редко валят профиль поодиночке. Обычно детект строится на согласованности: navigator.hardwareConcurrency, deviceMemory, число logical cores, поведение WebGL renderer и следы драйвера в шейдерном стеке. Разберем энтропию данного параметра: если «8 ядер» живут рядом с 2 GB RAM и интегрированной графикой, профиль начинает шуметь на уровне модели устройства.

Практический слой эмуляции должен держать связку, а не отдельные поля. • hardwareConcurrency не должен конфликтовать с типом процессора и платформой • deviceMemory лучше выбирать в допустимых для сегмента диапазонах, без экзотики • WebGL vendor/renderer обязаны совпадать с семейством GPU и типом ОС • UNMASKED_RENDERER_WEBGL, maxTextureSize, precisionFormat и список extensions должны быть внутренне непротиворечивыми

Под капотом Chromium API часть параметров читается не только из JS, но и через косвенные сигналы: тайминги отрисовки, Canvas, AudioContext, поведение requestAnimationFrame под нагрузкой. Поэтому Спуфинг через инъекцию JS-кода работает только если он синхронизирован с нативным слоем профиля и не создает «плоский» отпечаток, который невозможно получить на реальном железе.

Если нужна рабочая модель, сначала собирают эталонный стек устройства, затем сверяют его через Pixelscan, CreepJS и BrowserLeaks: задача не «сделать мощнее», а убрать взаимоисключающие признаки. Логика простая: аппаратные характеристики должны выглядеть как результат одной и той же физической машины, а не набора независимых подмен.