<b>Hardware Concurrency: почему число потоков выдаёт мобильный браузер</b>

<b>Hardware Concurrency: почему число потоков выдаёт мобильный браузер</b>

navigator.hardwareConcurrency выглядит как безобидный флаг, но в мобильной среде он часто отражает класс SoC, энергопрофиль и ограничения браузерного процесса. Анализируем энтропию параметров: одно и то же устройство может стабильно отдавать 2, 4, 6 или 8, и это уже полезный признак для склейки сессий.

Опасен не сам параметр, а его согласованность с остальным окружением:
• CPU cores vs. user-agent и platform
• число потоков vs. таймеры и поведение WebWorker
• hardwareConcurrency vs. memory, touch points, screen metrics

Если браузер маскируется под десктоп, а concurrency остаётся «мобильной», профиль получает внутреннее противоречие. Если же значение искусственно зафиксировано, оно часто выбивается из статистики по соседним признакам и даёт не меньше сигнала, чем нативное число. Браузерное окружение передает больше данных, чем кажется.

Для деанонимизации важна не точность до единицы, а кластеризация. Один и тот же набор признаков повторяется между сессиями, и этого достаточно, чтобы связать трафик, даже когда IP меняется. Разбираем сигнатуру на уровне syscall: приложение может не раскрывать железо явно, но поведение планировщика и параллелизм всё равно оставляют след.

Практика защиты проста: проверять согласованность hardwareConcurrency с остальными fingerprint-каналами и не пытаться «лечить» только один атрибут. Скрытность — это не отсутствие следов, это шум, сливающийся с фоном.