Hardware Concurrency: тихий идентификатор мобильного браузера, который недооценивают

Hardware Concurrency: тихий идентификатор мобильного браузера, который недооценивают

Браузерное окружение передает больше данных, чем кажется. navigator.hardwareConcurrency выглядит как бытовой параметр, но на мобильных устройствах он часто коррелирует с классом SoC, тепловым профилем и политикой энергосбережения. В связке с touch-моделью, памятью и таймингами рендеринга он сужает пространство поиска заметно сильнее, чем отдельные «безобидные» поля.

Анализируем энтропию параметров. Сам по себе concurrency редко уникален, но важен не он один, а связность признаков: 4 потока на старом бюджетном Android, 6–8 на среднем сегменте, 8+ на флагманах — и это уже не абстракция, а фильтр по аппаратному классу. Для антифрода опасен не точный матч, а устойчивое несоответствие: высокий concurrency при слабом GPU, аномальные задержки ввода, конфликт с UA и размером viewport.

Разбираем сигнатуру на уровне syscall. Поле легко стабилизируется между сессиями и плохо «маскируется» поверхностными расширениями, если остальные API остаются честными. Поэтому деанонимизация строится не на одном числе, а на кластере: concurrency + deviceMemory + canvas/RAF timing + сенсорные паттерны. Скрытность — это не отсутствие следов, это шум, сливающийся с фоном.

Практика для защиты проста: не пытайтесь править только один API. Нужна согласованная модель окружения, где concurrency, производительность JS и аппаратные признаки не противоречат друг другу. Иначе браузер сам выдаст, что перед вами не устройство, а имитация.