Почему после заморозки User-Agent новым сигналом браузерного отпечатка становятся Client Hints? Переход от UA к CH

В последние годы крупнейшие браузеры последовательно ужесточают политику конфиденциальности: Safari внедрил ITP, Firefox — Total Cookie Protection, а Chrome официально продвигает заморозку User-Agent (UA Reduction). Многие до сих пор считают, что достаточно «поменять UA», чтобы устройство выглядело иначе, не учитывая, что UA уже сильно упрощён и постепенно теряет подробную информацию. Роль важного сигнала для идентификации устройства всё больше переходит к Client Hints (CH).

Эта статья не обучает способам «обхода детектирования». Здесь рассматриваются только технические принципы и три вопроса: зачем замораживают UA? Что такое Client Hints и почему они считаются высокоэнтропийным сигналом отпечатка? Почему ключевое значение имеет так называемая «согласованность отпечатка»? Это помогает понять, почему современное управление браузерными средами, особенно при изоляции нескольких аккаунтов, должно рассматривать параметры как единую согласованную систему, а не как набор разрозненных полей.

1. Почему строки UA больше недостаточно?

Долгое время User-Agent был главным источником, по которому сайты определяли браузер и устройство. Он раскрывает такие сведения, как бренд и версия браузера, операционная система и архитектура устройства. Но строки UA были длинными и стабильными, что делало их удобными для fingerprinting. Поэтому Chrome прямо объявил о постепенном сокращении UA: сохранении только базовой информации, например основной версии, и переносе более подробных характеристик в новый механизм — Client Hints.

Прямое следствие заморозки UA: одной подмены UA уже недостаточно. Системы больше не доверяют только ему и проверяют, согласуются ли с UA другие поля. Самые заметные признаки несоответствия — противоречивые параметры, например:

• В UA указано macOS 14, а поле версии платформы сообщает macOS 13;
• UA заявляет мобильное устройство, но мобильный флаг по-прежнему равен ?0;
• Архитектура аппаратной части указана как arm64, а значения вроде navigator.hardwareConcurrency больше напоминают x86.

В системах идентификации устройств такие противоречия быстро показывают, что профиль может не соответствовать реальному устройству. Поэтому в эпоху заморозки User-Agent подход «изменить только UA» уже не работает.

2. Что такое Client Hints и почему это высокоэнтропийный отпечаток?

Client Hints (CH) — это набор данных о возможностях устройства, которые браузер может по запросу передать серверу через HTTP-запросы или среду JavaScript. От UA они отличаются прежде всего двумя особенностями:

1. Они включают высокоэнтропийные поля (High Entropy Values). Высокая энтропия означает, что сочетание таких данных обладает высокой уникальностью и его трудно угадать — например, точная версия платформы, полный список брендов и версий или архитектура устройства. Реальные браузеры возвращают эти значения по запросу, а не раскрывают всё сразу.

2. CH не оценивается отдельно, а сверяется с другими отпечатками. Реальные системы идентификации часто проверяют, соответствует ли CH User-Agent, согласуются ли CH и отпечатки транспортного уровня, такие как TLS JA3/JA4, с одной и той же семьёй браузеров, совпадает ли CH со свойствами JavaScript вроде navigator.platform, параллелизма и device pixel ratio (DPR), а также соответствует ли он характеристикам платформы операционной системы.

Отсюда следует важный принцип: сложно не изменить одно поле, а сделать так, чтобы все поля выглядели так, словно они пришли с одного реального устройства. Почти любое отдельное поле можно изменить изолированно. Настоящая задача — согласовать бренд, версию платформы, UA, DPR, память, архитектуру, TLS-отпечаток и другие сигналы в единый логичный профиль устройства. Поэтому даже конфигурации, где «заполнены все поля», могут выглядеть очевидно несогласованными.

3. Какие ошибки согласованности отпечатка встречаются чаще всего?

Когда понятно, что главное — согласованность, становится проще увидеть причины ошибок в настройках. Частые примеры:

• CH не соответствует UA (самый распространённый случай): UA сообщает macOS 14.1, а CH возвращает версию платформы, которой в реальности не существует;
• Мобильный UA при флаге ?0: на настоящем мобильном устройстве обычно должно быть ?1;
• Неверно выведен полный список версий: например, основная версия браузера — 120, а полные характеристики версии выглядят как у старой 115;
• DPR, память и другие значения противоречат реальному классу устройства: например, устройство Apple показывает аномально низкую плотность пикселей или обычный компьютер Windows сообщает всего 1 ГБ памяти;
• Игнорируются различия между браузерами: например, принудительно добавляется поле, которое браузер не поддерживает, или движок возвращает значение, которого в реальности у него быть не должно.

Такие противоречия хорошо заметны системам идентификации устройств. По сути, все они возникают из-за того, что среда не рассматривается как единое согласованное целое.

4. Что на самом деле означает «правильная конфигурация»?

Вместо идеи «заполнить поля» правильнее говорить о поддержании согласованного профиля среды. Обычно это включает несколько принципов:

• Связать CH с UA: выводить соответствующий набор CH — бренд, платформу и версию — по реальным правилам конкретного движка и версии браузера, а не собирать случайные значения;
• Соблюдать реальную стратегию возврата высокоэнтропийных полей: по умолчанию давать низкоэнтропийную информацию, высокоэнтропийные значения возвращать по запросу так, как это делает настоящий браузер, и не возвращать поля, которые текущий браузер не поддерживает;
• Согласовать свойства JS, HTTP-заголовки и системные характеристики: DPR должен соответствовать разрешению экрана, объём памяти — типу платформы, мобильный флаг — UA, а архитектура — логике всего системного профиля;
• Учитывать отпечатки транспортного уровня: характеристики вроде TLS/JA3/JA4 также должны соответствовать заявленной версии браузера.

Одной фразой: настоящая сложность в том, чтобы CH, UA, среда JavaScript и системные характеристики вместе образовывали согласованный профиль поведения браузера, а не в количестве заполненных полей.

5. Как это связано с управлением средами для нескольких аккаунтов?

У тех, кто работает в международной электронной коммерции, рекламе в социальных сетях или с независимыми магазинами, может возникнуть вопрос: какое отношение эти принципы имеют к «созданию отдельных браузерных сред для разных бизнес-аккаунтов»? Связь прямая: управление средами возможно только тогда, когда каждая среда внутренне согласована.

• При большом числе аккаунтов и регионов вместо ручного подбора UA, ОС, разрешения и других параметров для каждой среды разумнее, чтобы инструмент автоматически создавал взаимно согласованный набор параметров на основе выбранной системы и версии движка, уменьшая количество ошибок от несвязанных ручных изменений.
• Бизнес-аккаунты для разных регионов и платформ должны иметь отдельные среды с внутренне согласованными параметрами, а не использовать одну и ту же «шаблонную конфигурацию», из-за чего все профили будут выглядеть слишком похожими на уровне устройства.
• При переключении прокси на другой регион более естественно, если версия системы, модель устройства и другие характеристики продолжают логично соответствовать одной среде, чем если «меняется только IP, а все остальные параметры остаются полностью неизменными».

Именно такие задачи согласованности решают инструменты управления браузерными средами для нескольких аккаунтов. При создании среды PurpleMark предлагает единый интерфейс для операционной системы, версии движка Chromium, User-Agent, разрешения, часового пояса, языка, CPU/памяти, Canvas, WebGL, TLS и других параметров устройства и отпечатка. Выбрав регион и назначение аккаунта, можно сформировать среду по единой схеме вместо ручного подбора параметров при каждом входе. На практике система управляет общей согласованностью и повторным использованием настроек аккаунта, браузерной среды и сети в одном рабочем пространстве, а не способами обмануть конкретный механизм детектирования.

6. Итоги

Заморозка UA обозначает новый этап браузерного fingerprinting: важно уже не только наличие отдельных полей, а их взаимная согласованность. По мере того как Client Hints становятся источником высокоэнтропийных сигналов вместо детального UA, понимание связи CH с UA, системными характеристиками и транспортными отпечатками важнее, чем запоминание длинного списка названий полей.

Если вы просто поддерживаете несколько реальных и легитимных бизнес-аккаунтов, нет необходимости сосредотачиваться на противодействии детектированию. Практичнее использовать инструмент управления средой, например PurpleMark, чтобы регион, система и параметры браузера каждого аккаунта оставались понятными, согласованными и пригодными для повторного использования, уменьшая проблемы от противоречивых настроек ещё на исходном уровне.

(Примечание: статья предназначена исключительно для образовательного объяснения технических принципов браузерного fingerprinting. Всегда соблюдайте условия использования платформ и работайте с легитимными аккаунтами.)