Откройте панель Network в инструментах разработчиков браузера, и вы почти всегда найдёте заголовок User-Agent. Похоже, это короткое введение: какой браузер делает запрос, на какой операционной системе он работает и какую версию он называет.
Это создаёт соблазн рассматривать заголовок как идентификатор устройства — или предполагать, что изменение одной строки может превратить браузер в другое устройство. Обе идеи лишь частично верны.
Строка User-Agent, или UA, — это информация о совместимости, объявленная клиентом. Это не надёжный идентификатор, и клиент может его изменять. Однако она не существует в изоляции. Сайт может сравнивать UA с Client Hints, API JavaScript, свойствами экрана, шрифтами, Canvas, WebGL, сетевым контекстом и поведением. Полезный вопрос заключается не только в том, можно ли изменить UA, а в том, какую роль он играет в полной наблюдаемой поверхности браузера.
В этой статье используются HTTP стандарты и исследования браузерных отпечатков для ответа на четыре вопроса:
- Почему UA-строка выглядит как фрагмент археологии браузера?
- Сколько идентифицирующей информации UA может внести вклад и как следует интерпретировать это исследование?
- Почему изменение только UA может создавать более очевидную несоответствие?
- Что UA Reduction и User-Agent Client Hints на самом деле изменили?
В этой статье UA в первую очередь означает заголовок запроса HTTP
User-Agent. Мы также обсуждаемnavigator.userAgentиnavigator.userAgentDataв JavaScript. Эти интерфейсы связаны, но не всегда идентичны во всех браузерах и контекстах.
1. Что такое User-Agent?
Раздел 10.1.5 RFC 9110 определяет User-Agent как поле, содержащее информацию о пользовательском агенте, который инициировал запрос. Её упрощённая грамматика выглядит так:
User-Agent = product *( RWS ( product / comment ) )
product = token [ "/" product-version ]
Проще говоря, строка начинается с названия продукта и может включать версию. Далее можно оставить больше продуктов или комментариев. Стандарт признаёт такие применения, как обходные решения по совместимости, диагностика и аналитика, но также рекомендует внедрять не раскрывать лишние детали: более длинный и конкретный UA увеличивает как размер запроса, так и риск отпечатков пальцев.
Современный Chromium настольный UA может выглядеть так:
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36
Разделение строки на пробелы выявляет несколько имён, которые кажутся не связанными с Chrome:
| Токен | Что это вообще значит сегодня | Распространённое непонимание |
|---|---|---|
Mozilla/5.0 | Исторический токен совместимости | Браузер должен быть Firefox или продуктом Mozilla |
Windows NT 10.0 | Категория Windows платформ; Уменьшенный UA не может надёжно отличить Windows 10 от 11 | Компьютер должен работать Windows 10 |
Win64; x64 | Подсказка о том, что это 64-битный Windows на архитектуре x86-64 | Он доказывает точную физическую модель процессора |
AppleWebKit/537.36 | Токен родословной движка и совместимости | Chrome всё ещё использует полную реализацию Safari |
KHTML, like Gecko | Язык исторической совместимости | И KHTML, и Gecko работают |
Chrome/145.0.0.0 | Семейство Chrome/Chromium и основная версия; Компоненты более низкой версии могут быть уменьшены | Он показывает точную версию патча |
Safari/537.36 | Токен, сохранённый для совместимости со старыми сайтами | Браузер должен быть Safari |
Этот UA стал многословным, потому что ранние сайты часто ветвялись по названиям браузеров. Новые браузеры должны были заявлять о совместимости со старыми продуктами, чтобы получить правильную страницу. Эти заявления накапливались со временем, создавая исторический факт, который невозможно читать буквально.
Первое правило UA парсинга просто: это протокол совместимости, а не строгое описание устройства.
2. Почему сайты всё ещё используют UA?
UA используется не только для отслеживания. Законные применения включают:
- предоставляя запасной вариант для старого браузера с известной проблемой совместимости;
- выбор подходящего установщика или формата скачивания;
- обнаружение специфических для версии сбоев в диагностических журналах;
- измерение широкого семейства браузеров, платформ и основных версий;
- выявление невозможных комбинаций в автоматическом или вредоносном трафике.
Проблема начинается, когда UA нюхание переходит от узкого варианта совместимости к угадыванию возможностей по названию продукта. Код может видеть Chrome и предполагать, что существует определённый API. Это предположение может не сработать в встроенном WebView, браузере, основанном на Chromium, браузере с корпоративной политикой, замороженной UA или клиенте, изменившем заголовок.
Более надёжный порядок действий выглядит так:
- Тестируйте требуемый API или поведение напрямую, когда возможно обнаружение возможностей.
- Когда идентификация браузера неизбежна, используйте поддерживаемый парсер вместо ad hoc регулярного выражения.
- Храните только те категории, которые действительно нужны продукту.
- Предложите запасной вариант для неизвестных брендов, неизвестных версий и отсутствующих полей.
3. Является ли UA отпечатком браузера?
Точнее, UA — это один ввод в браузерный отпечаток, обычно не полный отпечаток.
Отпечаток в браузере не требует секретного серийного номера. Он измеряет набор относительно стабильных, отличительных атрибутов, открытых браузером. UA даёт подсказки о семействе, версии и платформе браузеров. Размеры экрана, шрифты, часовые поясы, Canvas, WebGL, AudioContext и другие интерфейсы добавляют дополнительную информацию.
Опрос, проведённый Лапердриксом и коллегами Browser Fingerprinting: A Survey, рассматривает эти методы как форму безгосударственного распознавания. Сайт не обязательно должен сначала написать Cookie; Он может пытаться связать визиты с атрибутами, которые предоставляет браузер. «Без состояния» не означает, что сервер ничего не хранит. Это означает, что материал распознавания не зависит от постоянного идентификатора на стороне клиента.
1. Что означает 10-битный результат бумаги?
В исследовании Panopticlick 2010 года How Unique Is Your Web Browser? Питер Эккерсли проанализировал примерно 470 000 отпечатков браузеров. Газета сообщила, что:
- Полный отпечаток в этом образце содержал в среднем около 18,1 бит идентифицирующей информации;
- Интуитивно говоря, средний отпечаток пальца встречался примерно один раз в 286 777 браузерах;
- Таблица сообщала около 10,0 бит средней информации только для UA строки;
- среди браузеров с поддержкой Flash или Java 94,2% полных отпечатков были уникальными.
Самоинформирование обычно пишется как:
I(x) = -log₂ P(x)
Если определённый UA встречается с вероятностью 1/1024 в популяции, его наблюдение даёт 10 бит информации. Это не означает, что UA имеет ровно 1 024 возможных значения или что он уникально идентифицирует человека. Он описывает, сколько неопределённости устраняет это наблюдение в среднем.
2. Почему результат 2010 года не является постоянным для современного интернета?
Результат остаётся важен, но для него требуется как минимум три уточнения:
- Посетители страницы тестирования конфиденциальности не были случайной выборкой всех пользователей интернета;
- Разнообразие браузеров, плагинов и версий UA в 2010 году сильно отличалось от современной экосистемы;
- UA Reduction, уменьшение поверхностей плагинов и защита от отпечатков пальцев изменили распределение наблюдаемых атрибутов.
Исследование подтверждает утверждение, что UA и другие атрибуты могут вносить измеримую отличительную информацию. Она не поддерживает утверждение, что UA сегодня всегда имеет ровно 10 бит энтропии. Мощность отпечатка пальцев зависит от популяции, временного окна, политики браузера и комбинации сигналов.
4. Почему изменение только UA может обернуться против них?
UA — это декларация клиента без криптографических доказательств. Сервер не может прочитать заводскую истину устройства из этого заголовка. Однако он может проверить, совместимы ли разные наблюдения.
Предположим, что UA заявляет о мобильном браузере, но страница не обнаруживает точек соприкосновения, есть окно, которое постоянно напоминает настольный дисплей, и Client Hints сообщает о настольной платформе. Любое одно наблюдение может иметь законное исключение. Несколько стабильных противоречий вместе всё равно могут образовывать классифицируемый шаблон.
Статья Panopticlick уже задокументировала аналогичные случаи: некоторые браузеры заявляли, что являются iPhone, поддерживая Flash, а некоторые Firefox UA появлялись вместе с функциями хранения, доступными только в Internet Explorer. Исследование 2018 года FP-Scanner систематически рассмотрело эту проблему. Некоторые расширения против отпечатков пальцев и инструменты для подделки вводили несоответствия между интерфейсами, позволяя детектору выявлять изменённые атрибуты и, в некоторых случаях, делать выводы о оригинальном браузере или семействе операционной системы.
Не каждое несоответствие является злонамеренным. Удалённые рабочие столы, инструменты доступности, корпоративные политики, слои совместимости и необычное оборудование могут создавать необычные комбинации. Тщательная система риска должна рассматривать несоответствие как вероятностное доказательство, а не как автоматическую причину для блокировки пользователя.
Для управления профилями браузера важны три свойства:
- Внутренняя согласованность: UA, Client Hints, платформа, архитектура, сенсорные и экранные сигналы не должны прямо противоречат друг другу.
- Стабильность со временем: долгоживущий профиль не должен кардинально меняться при каждом запуске без причины.
- Правдоподобное разнообразие: профили могут отличаться, но редкие механически сгенерированные комбинации не обязательно безопаснее.
Исследование FP-STALKER также показало, что изменение атрибутов не автоматически предотвращает связь. Модель может использовать стабильные атрибуты и правдоподобные изменения версий для соединения более ранних и поздних отпечатков.
5. Какую проблему UA Reduction решать?
Традиционный UA отправляется почти с каждым запросом. Любой сторонний или сторонний конечный объект, получивший запрос, может пассивно его прочитать. Чем точнее строка, тем более отличительной информации получает каждый получатель по умолчанию.
User-Agent Reduction план Chromium уменьшает эту стандартную детализацию:
- начиная с Chrome 101, версии Desktop Minor, Build и Patch были сокращены до
0.0.0; - поздние этапы — версии унифицированных рабочих стольных операционных систем, детали процессора и информации о Android устройствах;
- уменьшенный Android UA использует фиксированные значения платформы и моделей, такие как
Android 10; K; - Сайты, которые действительно требуют большей информации, могут запрашивать User-Agent Client Hints.
Сокращённый формат можно резюмировать так:
Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36
Редукция уменьшает пассивную поверхность отпечатка пальцев в наследственной UA. Он не устраняет отпечатки в браузере. Основная версия, широкая платформа и состояние мобильного устройства могут оставаться видимыми, в то время как другие API, свойства сети и поведение всё ещё могут предоставлять информацию.
6. Как User-Agent Client Hints работает?
Общий механизм определён в RFC 8942, а WICG User-Agent Client Hints draft описывает UA-специфические поля. Этот подход разбивает информацию, которая когда-то существовала в неструктурированной строке, на структурированные поля, отличая подсказки с низкой энтропией, которые могут быть отправлены по умолчанию, от подсказок с высокой энтропией, которые сайт обычно запрашивает явно.
Упрощённый первоначальный запрос может выглядеть так:
GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Если серверу действительно нужна архитектура и битность для выбора установщика, он может ответить:
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Когда браузер поддерживает механизм и требования к безопасности и политике выполнены, последующий запрос может включать:
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Распространённые UA Client Hints включают:
| Поле | Типичная цель | Уровень информации |
|---|---|---|
Sec-CH-UA | Список брендов и основных версий | Обычно низкая энтропия |
Sec-CH-UA-Mobile | Предпочитает ли клиент мобильный опыт | Обычно низкая энтропия |
Sec-CH-UA-Platform | Категория широкой платформы | Обычно низкая энтропия |
Sec-CH-UA-Arch | Архитектура процессора | Высокая энтропия; Запрос при необходимости |
Sec-CH-UA-Bitness | Битность архитектуры | Высокая энтропия; Запрос при необходимости |
Sec-CH-UA-Platform-Version | Версия платформы | Высокая энтропия; Запрос при необходимости |
Sec-CH-UA-Full-Version-List | Полные версии для указанных брендов | Высокая энтропия; Запрос при необходимости |
Sec-CH-UA-Model | Модель устройства | Высокая энтропия; Запрос при необходимости |
Три инженерных детали легко упустить.
1. Client Hints не все отправляются автоматически
Подсказки с низкой энтропией могут появляться по умолчанию. Подсказки с высокой энтропией обычно требуют Accept-CH ответа. Начальная навигация, подресурсы, политика разрешений, безопасный транспорт и поддержка браузера могут влиять на то, что поступает. Сервер должен допускать отсутствие всех опциональных полей.
2. Список брендов намеренно проверяет надёжность парсеров
Sec-CH-UA может содержать несколько брендов и синтетический бренд, используемый для проверки совместимости. Код не должен предполагать, что первая запись всегда является названием продукта, и не должен провалиться при появлении неизвестного бренда. Анализируйте структурированное поле, игнорируйте незнакомые записи и оставляйте место для будущих брендов.
3. Ответы, различающиеся по подсказкам, требуют корректной обработки кэша
Если архитектура, платформа или другая подсказка изменяет ответ, правильно настройте Vary или эквивалентную стратегию кэш-ключа. В противном случае общий кэш может передавать контент, сгенерированный для одного класса устройств, другому.
7. Являются ли Client Hints более приватными, чем традиционные UA?
Они улучшают распространение информации, но не обеспечивают иммунитет от снятия отпечатков пальцев.
Традиционный UA обнажает большой неструктурированный пучок пассивно и по умолчанию. Client Hints разделить этот набор на поля, сделать запросы информации с более высокой энтропией более явными и дать браузеру возможность применять политику, разрешения или контроли бюджета конфиденциальности.
Однако архитектура, полные версии, платформенные версии и модели устройств всё равно могут повысить различие. RFC 8942 явно рассматривает конфиденциальность и производительность как ограничения дизайна. Разработчикам стоит спросить:
- Действительно ли эта функция требует этого поля?
- Может ли обнаружение возможностей или выбор пользователя заменить её?
- Может ли приложение хранить только грубую категорию?
- Как долго сохраняются необработанные значения и кто может к ним получить доступ?
- Получат ли сторонние ресурсы те же подсказки?
8. Инженерные рекомендации по обработке UA на сервере
1. Никогда не используйте UA как доказательство личности или авторитета
UA может поддерживать выбор презентации и запасные варианты совместимости. Он не должен определять личность, авторизацию, платёжный траст или границы безопасности. Значение, контролируемое клиентом, не может служить учетной записью для контроля доступа.
2. Предпочтение обнаружения возможностей перед списками браузера
Когда фронтенду нужен API, тестируйте эту возможность напрямую:
if ('share' in navigator) {
// Offer the system share feature.
} else {
// Fall back to copying a link.
}
Обнаружение возможностей лучше справляется с браузерами, экспериментальными функциями, корпоративными политиками и будущими релизами, чем правило вроде «включить это для Chrome 145».
3. Принять наследственные UA, Client Hints и неизвестные государства
Во время миграции сервер может получать только наследственные UA, как UA, так и Client Hints, либо сильно сокращённые формы обоих. Модель данных должна позволять unknown, а не угадывать точную операционную систему или модель устройства, чтобы заполнить каждое поле.
4. Уменьшить детализацию логарифма
Если аналитике нужен только десктопный или мобильный, браузерная семья и основная версия, не сохраняйте необработанные UA строки и каждую подсказку с высокой энтропией бесконечно. Минимизация данных снижает риск конфиденциальности и не позволяет аналитическому конвейеру рассматривать незначительные вариации как значимое измерение.
5. Рассматривайте аномалии как доказательства, а не как вердикты
UA, который утверждает, что Windows при одном из API ведёт себя иначе, — это, в лучшем случае, один из сигналов риска. Корпоративные среды, виртуализация, удалённые сессии, слои совместимости и вспомогательные технологии могут создавать реальные аномалии. Превращение одного несоответствия в автоматическое решение о мошенничестве создаёт ложные срабатывания.
9. Как UA следует настраивать в многопрофильных средах?
Для межрегионального тестирования, рекламных превью, управления аккаунтами и изоляции конфиденциальности целью не должно быть создание самых необычных UA. Профиль должен быть объяснимым, стабильным и совместимым с окружающей средой.
Прочитайте следующее в порядке:
- Браузерная версия: UA основная версия должна быть правдоподобной для самого движка и его возможностей.
- Операционная система: категория UA, платформа Client Hints и JavaScript видимая платформа должны быть совместимы.
- Архитектура и битность: UA, Client Hints и исполняемая среда не должны делать прямо противоречивые заявления.
- Форм-фактор устройства: мобильное объявление должно иметь смысл наряду с поддержкой сенсорного сигнала, вьюпортом, соотношением пикселей и паттернами взаимодействия.
- Региональный контекст: язык, часовой пояс, геолокация и выход через прокси не обязательно должны совпадать механически, но они должны быть логичны для реального рабочего процесса.
- Стабильность профиля: Когда один аккаунт или тестовая идентичность повторно использует долгоживущий профиль, избегайте смены платформы и основной версии без причины.
Текущее преобразование профиля PurpleMark сопоставляет выбранную операционную систему с платформой UA и сначала пытается извлечь версию браузера из настроенного токена Chrome/ или CriOS/. Когда не существует пригодной версии, она получает разумный запасной вариант по сравнению с основной версией текущего движка. Цель — не подделать одну изолированную строку, а поместить UA конфигурацию в единую модель профиля браузера.
Изоляция профилей и согласованность параметров могут снизить техническую корреляцию и смещение тестирования. Они не могут гарантировать, что аккаунты никогда не будут связаны, и не заменяют правила платформы, данные счетов, платёжную информацию или ответственные операционные практики. Используйте эти возможности только для законной защиты конфиденциальности, авторизованного тестирования и соответствующей бизнес-деятельности.
10. Часто задаваемые вопросы
Вопрос 1: Превращает ли изменение UA браузер в другой браузер?
Нет. Это меняет часть заявлений клиента. Он не заменяет движок JavaScript, конвейер рендеринга, сетевой стек или поддерживаемые веб-API.
Вопрос 2: Может ли сайт прочитать «настоящий UA»?
Не существует универсального аппаратного уровня «реального UA», который каждый сайт мог бы обойти браузер и прочитать. Тем не менее, сайт может сравнивать Client Hints, тесты возможностей и другие сигналы отпечатков пальцев, находить несовместимые утверждения и делать вероятностные выводы.
Вопрос 3: Может ли уменьшенный UA отличить Windows 10 от Windows 11?
Уменьшённые UA обычно не могут делать это надёжно, так как оба могут сообщать о Windows NT 10.0. Браузер, поддерживающий UA Client Hints, может предоставить более подробную информацию о версии платформы после запроса сайта. Серверы всё равно должны обрабатывать отсутствующие поля и различия в отображении.
Вопрос 4: Прекращает ли отключение JavaScript UA воздействие?
Не полностью. HTTP User-Agent — это заголовок запроса, который может быть отправлен вместе с запросом страницы до запуска JavaScript й страницы. Отключение JavaScript удаляет часть поверхностей коллекции, но также разрушает значительные части современной сети.
Вопрос 5: Полностью ли Client Hints заменят User-Agent?
Не предполагайте этого в ближайшей перспективе. Многие клиенты и серверы всё ещё зависят от наследственных UA, при этом UA Client Hints поддержка варьируется. Рассматривайте Client Hints как прогрессивное улучшение: предпочитайте структурированную информацию, когда она доступна, но сохраняйте резервные варианты для наследственных UA и неизвестных состояний.
Вопрос 6: Улучшает ли случайно сгенерированный UA анонимность?
Не обязательно. Рандомизация одного поля может создавать противоречия между версиями, платформой, сенсорными и рендеринговыми сигналами. Для долгоживущего профиля обычная, стабильная и внутренне совместимая конфигурация обычно более оправдана, чем частые случайные изменения.
11. Заключение
User-Agent не является ни надёжным удостоверением личности, ни несущественной строкой. Он находится на пересечении совместимости с вебом, конфиденциальности и анализа рисков. Для разработчиков это ввод совместимости, обременённый историей. Для исследователей отпечатков пальцев это атрибут с измеряемой статистической информацией. Для производителей браузеров это поверхность экспозиции по умолчанию, которую нужно уменьшить.
Ключевые идеи вписываются в три утверждения:
- Не читайте UA буквально; Он содержит множество исторических токенов совместимости.
- Не оценивайте UA в одиночку; Практическое распознавание происходит благодаря сочетанию сигналов и их эволюции со временем.
- Не думайте о Client Hints просто как о «более UA полях»; Их ценность заключается в структурированном, ориентированном на запросы и управляемом раскрытии информации.
Когда система переходит от определения имени браузера к тестированию необходимых возможностей — и от сбора всех доступных деталей к запросу только необходимого — UA возвращается к своей собственной роли: подсказке совместимости, а не истине идентичности.
Ссылки и стандарты
- Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
- Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
- IETF. RFC 9110: HTTP Semantics, 2022.
- IETF. RFC 8942: HTTP Client Hints, 2021.
- WICG. User-Agent Client Hints, Draft Community Group Report.
- Chromium. User-Agent Reduction.
- Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.