Відкрийте панель Network у інструментах розробника браузера, і ви майже завжди знайдете заголовок User-Agent. Виглядає як коротке вступлення: який браузер робить запит, на якій операційній системі він працює і яку версію він називає.
Це створює спокусу розглядати заголовок як ідентифікатор пристрою або припустити, що зміна одного рядка може перетворити браузер на інший пристрій. Обидві ідеї лише частково правильні.
Рядок User-Agent, або UA, — це інформація сумісності, оголошена клієнтом. Це не довірена ідентифікаційна дата, і клієнт може його змінювати. Проте він не існує окремо. Сайт може порівнювати UA з Client Hints, JavaScript API, властивостями екрану, шрифтами, 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, а деякі UA Firefox з'явилися разом із функціями зберігання, доступними лише в 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.