User-Agent Client Hints: замена User-Agent или новый источник данных

Client Hints и User-Agent Client Hints

Хотя механизм Client Hints появился еще в 2013 году, он использовался для оптимизации доставки контента и не касался идентификации браузера. И лишь с появлением User-Agent Client Hints его начали рассматривать как альтернативу стандартному User-Agent.

Подход Client Hints реализован в браузерах Chromium — сервер запрашивает подсказки, а браузер принимает решение, что возвращать. Это означает, что по умолчанию браузер не шлет ничего лишнего, а отдает только ту информацию, которую запросил сервер. Самый простой пример — разработчики могут отказаться от сложного парсинга строки User-Agent и пользоваться простыми заголовками вместо разбора User-Agent через регулярные выражения.

Со временем User‑Agent обрастал деталями, костыльными записями типа Mozilla/5.0 (конкретно эта запись актуальна еще с 90-х годов). Это, в свою очередь, порождало:

• Сложность парсинга. Так как формат User‑Agent не стандартизирован, то и разбирать эту строку приходится регулярными выражениями, что далеко не всегда надежно. Сложный для прочтения User‑Agent становится причиной багов и проблем совместимости.

• Утечку приватных данных. User‑Agent передает очень много информации, причем она отправляется в каждом запросе. Такие детали позволяют отслеживать пользователя: точная версия браузера, модель устройства, разрядность — все это используется трекерами для фингерпринтинга.

Как видите, возникла острая необходимость замены User-Agent новым механизмом, который был бы структурирован и управляем сервером, но при этом не ломал бы совместимость и повышал приватность.

Далее по тексту мы будем использовать термин энтропийность. В контексте UA-CH — это степень уникальности передаваемой информации. Чем выше энтропийность набора параметров — тем больше шанс, что браузер будет иметь уникальный отпечаток, а это, в свою очередь, помогает антифрод-системам узнавать его среди многих других профилей. 

User-Agent Client Hints (UA-CH) — это специализированный набор клиентских подсказок, который передает характеристики браузера и устройства. Вместо единой строки UA браузер отправляет ряд структурированных заголовков с префиксом Sec-CH-UA-*, в частности: 

• Sec-CH-UA — список брендов браузера и его версий.

• Sec-CH-UA-Mobile ?0 или ?1 — сообщает, считается ли текущий браузер мобильным.

• Sec-CH-UA-Platform — название операционной системы (Windows, Android, macOS).

• Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Model, Sec-CH-UA-Full-Version-List — высокоэнтропийные подсказки с точной версией ОС, архитектурой и моделью устройства. Они могут раскрывать больше уникальной информации и поэтому отправляются только при явном запросе сервера. 

Некоторые подсказки считаются низкоэнтропийными — они отправляются сразу и не дают уникальной информации (бренд браузера, платформа, признак мобильного устройства). 

Высокоэнтропийные подсказки (точная версия ОС, модель устройства, архитектура и битность) браузер шлет только при явном запросе Accept-CH, поскольку они дают больше уникальных данных. Так UA-CH позволяют передавать те же и даже дополнительные сведения, что и User-Agent, но более приватно и под контролем сервера. Насчет контроля конечно сказано слишком громко, так как технически UA-CH позволяет передать намного больше информации, чем  UA, ничто не мешает серверу запросить всю эту информацию дополнительным запросом. В плане оптимизации работы с данными использование UA-CH удобнее и структурированнее, чем длинная строка, но вот к конфиденциальности могут возникнуть вопросы.

Как работает обмен Client Hints

На практике жизненный цикл с UA-CH идет так: 

1. Первый запрос

При первом запросе браузер по умолчанию добавляет в заголовки низкоэнтропийные подсказки:

Sec-CH-UA: "Google Chrome";v="137", "Chromium";v="137", "Not/A)Brand";v="24"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

То есть базовый набор данных о бренде и операционной системе. 

2. Ответ сервера

Сервер в ответе может указать заголовок Accept-CH и перечислить дополнительные подсказки, которые ему нужны. Например:

Accept-CH: Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch, Sec-CH-UA-Model

Это команда запросить версию операционной системы, архитектуру и модель. После чего браузер кэширует требование сервера и в следующих запросах к тому же домену добавит эти заголовки. 

3. Последующие запросы

Следующий запрос придет уже таким:

Sec-CH-UA-Platform-Version: "10.0"
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Model: ""

Что мы имеем в итоге: на первом запросе сервер получает только общую информацию, а все остальное добавляется на последующих переходах после запроса через Accept-CH.

Чтобы CDN и прокси корректно кэшировали разные версии контента, сервер должен также добавить Vary: Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch. Это нужно в том случае, когда, к примеру, сайт делает разную сборку JavaScript для ARM и x86. 

А что насчет JavaScript API?

Помимо HTTP-заголовков, подсказки UA-CH доступны и в браузерном JS. В Chromium-подобных браузерах есть объект navigator.userAgentData, из которого сразу можно получить низкоэнтропийные данные:

const brands = navigator.userAgentData?.brands;  // [{brand: 'Chromium', version: '137'}, ...]
const mobile = navigator.userAgentData?.mobile;  // true/false
const platform = navigator.userAgentData?.platform;  // "Windows"

Для получения детальных (высокоэнтропийных) полей вызывают промис — специальный объект, который описывает, как работать с данными:

navigator.userAgentData.getHighEntropyValues([
  'architecture','bitness','model','platformVersion','fullVersionList','wow64'
]).then(ua => {
  console.log(ua.architecture);     // "x86"
  console.log(ua.bitness);          // "64"
  console.log(ua.platformVersion);  // "10.0"
  console.log(ua.model);            // модель устройства или пусто
  console.log(ua.fullVersionList);  // массив полных версий
});

Важно помнить, что этот API поддерживается только в Chromium-браузерах (в Safari/Firefox его нет), поэтому в коде нужно обязательно предусматривать fallback на классический navigator.userAgent (по крайней мере, в ближайшее время точно). А на сервере важно проверять наличие заголовков Sec-CH-UA-*, так как без них придется использовать анализ старого User-Agent.

User-Agent vs UA-CH: что меняется

Теперь давайте рассмотрим ключевые различия между классическим UA и новой схемой Client Hints:

• Формат: UA — одна длинная строка; UA-CH — набор структурированных HTTP-заголовков (с Sec-CH-UA-*).

• Отправка: UA уходит всегда с каждым запросом; UA-CH — только то, что запросил сервер. Браузер сам решает, какие поля добавить при необходимости.

• Расширяемость: классический UA сложно расширять (любой новый параметр ломает парсеры); UA-CH — более гибкий протокол: новые подсказки можно добавить без нарушения старых, так как сервер сам их запрашивает.

• Парсинг: UA-строку приходится дробить на части вручную (регулярными выражениями); UA-CH читаются напрямую из заголовков, что проще и надежнее.

• Поддержка: UA понимают все браузеры; UA-CH реализованы по умолчанию в Chromium (Chrome 89+, Edge, Opera, Brave, Vivaldi и другие на его движке), но не поддерживаются Safari и Firefox по умолчанию.

• Точность первой загрузки: классический UA сразу дает полную информацию; UA-CH на первом запросе предоставляет только базовые подсказки, детали будут доступны лишь после ответного запроса серверу (это важно учитывать при выборе версий контента).

• Контроль сервера: UA не позволяет серверу выбирать данные — все отправляется всегда; с UA-CH сервер сам решает в Accept-CH, какие поля ему нужны.

• Риск фингерпринтинга: в UA-CH меньше уникальной информации для трекеров, но это не отменяет других методов уникализации пользователя (язык, часовой пояс, Canvas/WebGL и т. д.). UA-CH лишь снижают количество выдаваемых данных на начальном этапе, но не устраняют всю проблему фингерпринтинга.

В итоге UA-CH позволяют собирать нужные сведения более осмысленно и приватно, что упрощает жизнь разработчиков парсеров и повышает гибкость при работе. Но очевидно, что переход будет длительным. Есть ощущение, что гибридный подход закончится не скоро: там, где есть UA-CH, — будут использовать их, а для всего остального — продолжат разбирать старый UA.

Практические рекомендации

1. Не запрашивайте все подряд. Если в Accept-CH указывать все сразу, это похоже на фингерпринтинг. Запрашивайте только то, что действительно требуется. Например, для адаптивных картинок будут полезны Sec-CH-Viewport-Width, Sec-CH-DPR и Sec-CH-Width; для адаптации интерфейса — Sec-CH-UA-Mobile, Sec-CH-UA-Platform; для трафика — Sec-CH-Save-Data, Sec-CH-RTT, Sec-CH-ECT. Избегайте лишних «зондов» вроде всех подсказок устройств и памяти сразу — это может насторожить систему защиты.

2. Не забывайте про кэш. Если вы меняете контент под Client Hints, всегда указывайте Vary для этих заголовков. Например, если вы различаете контент по Sec-CH-UA-Mobile и Sec-CH-Viewport-Width, нужно установить в ответе Vary: Sec-CH-UA-Mobile, Sec-CH-Viewport-Width. Иначе CDN или прокси могут кэшировать ответ без учета нужных подсказок и отдавать неподходящую версию.

3. Избегайте частых изменений. Браузер кэширует Accept‑CH. Не стоит запрашивать разные подсказки на каждой странице — это увеличит поток заголовков.

4. Fallback обязателен. UA-CH пока не покрывают весь рынок. По дефолту лучше читать и использовать Sec-CH-UA-* или navigator.userAgentData, а если их нет — парсить привычный User-Agent. Не полагайтесь на UA-CH как на обязательный источник.

Итог

User-Agent Client Hints — это не просто еще один заголовок, а попытка полностью переработать устаревшую модель одной длинной строки. С помощью UA-CH данные о клиенте передаются структурировано и по запросу сервера, что:

• упрощает жизнь разработчику;

• дает возможность для дальнейшего развития индустрии.

Ключевая польза UA-CH для разработчиков парсеров и пользователей антидетект-браузеров сейчас — баланс между нужной информацией и удобством использования.