Чому після заморожування 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 — бренд, платформу та версію — за реальними правилами конкретного рушія й версії браузера, а не складати довільні значення;
• Дотримуватися реальної стратегії повернення високоентропійних полів: за замовчуванням надавати низькоентропійну інформацію, високоентропійні значення повертати на запит так, як це робить справжній браузер, і не повертати поля, які поточний browser не підтримує;
• Узгодити властивості JS, HTTP-заголовки та системні характеристики: DPR має відповідати роздільній здатності екрана, обсяг пам’яті — типу платформи, мобільний прапорець — UA, а архітектура — логіці всього системного профілю;
• Пов’язати з відбитками транспортного рівня: характеристики на кшталт TLS/JA3/JA4 також мають відповідати заявленій версії браузера.

Коротко: справжня складність — зробити CH, UA, середовище JavaScript і системні характеристики єдиним узгодженим профілем поведінки браузера, а не просто заповнити якомога більше полів.

5. Як це пов’язано з керуванням середовищами для кількох акаунтів?

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

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

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

6. Підсумок

Заморожування UA позначає новий етап browser fingerprinting: важливо вже не лише те, які поля існують, а те, чи узгоджуються вони між собою. Коли Client Hints перебирають роль джерела високоентропійних сигналів, розуміння зв’язку між CH, UA, системними характеристиками та транспортними відбитками важливіше за запам’ятовування довгого списку назв полів.

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

(Примітка: стаття має виключно освітню мету та пояснює технічні принципи browser fingerprinting. Завжди дотримуйтеся умов використання платформ і працюйте з легітимними акаунтами.)