Dlaczego po zamrożeniu User-Agent to Client Hints stają się nowym sygnałem fingerprintu? Ewolucja UA do CH

W ostatnich latach główne przeglądarki konsekwentnie zaostrzają politykę prywatności: Safari wprowadziło ITP, Firefox wdrożył Total Cookie Protection, a Chrome oficjalnie rozwija zamrożenie User-Agent (UA Reduction). Wiele osób nadal uważa, że „wystarczy zmienić UA”, aby urządzenie wyglądało inaczej, nie zdając sobie sprawy, że UA został już znacząco uproszczony i stopniowo traci szczegółowe informacje. Rolę kluczowego sygnału identyfikacji urządzenia przejmują Client Hints (CH).

Ten artykuł nie uczy metod „omijania wykrywania”. Wyjaśnia jedynie techniczne podstawy trzech zagadnień: dlaczego UA jest zamrażany? Czym dokładnie są Client Hints i dlaczego uważa się je za sygnały fingerprintu o wysokiej entropii? Dlaczego tak zwana „spójność fingerprintu” jest najważniejsza? Dzięki temu łatwiej zrozumieć, dlaczego nowoczesne zarządzanie środowiskiem przeglądarki, szczególnie przy izolacji wielu kont, powinno traktować parametry jako jeden spójny system, a nie zbiór niezależnych pól.

1. Dlaczego ciąg UA przestał wystarczać?

Przez długi czas User-Agent był podstawową informacją wykorzystywaną przez strony do rozpoznawania przeglądarki i urządzenia. Ujawniał m.in. markę i wersję przeglądarki, system operacyjny oraz architekturę urządzenia. Ponieważ ciągi UA były długie i stabilne, łatwo wykorzystywano je do fingerprintingu. Dlatego Chrome jednoznacznie zapowiedział stopniową redukcję UA: pozostawienie głównie podstawowej wersji głównej i przeniesienie bardziej szczegółowych informacji do nowego mechanizmu, czyli Client Hints.

Bezpośredni skutek zamrożenia UA jest taki, że samo sfałszowanie UA nie jest już przekonujące. Systemy nie ufają wyłącznie UA, lecz sprawdzają, czy pozostałe pola są z nim zgodne. Najbardziej oczywiste sygnały niespójności to sprzeczne parametry, na przykład:

• UA wskazuje macOS 14, a pole wersji platformy pokazuje macOS 13;
• UA deklaruje urządzenie mobilne, ale znacznik mobilny nadal ma wartość ?0;
• Architektura sprzętu to arm64, lecz wartości takie jak navigator.hardwareConcurrency wyglądają bardziej jak x86.

W systemach identyfikacji urządzeń takie sprzeczności mogą szybko sugerować, że profil nie pochodzi z prawdziwego urządzenia. Dlatego „zmiana tylko UA” w erze jego zamrażania już nie wystarcza.

2. Czym są Client Hints i dlaczego są fingerprintem o wysokiej entropii?

Client Hints (CH) to zestaw informacji o możliwościach urządzenia, które przeglądarka może na żądanie ujawnić serwerowi w żądaniach HTTP lub środowisku JavaScript. Od UA różnią się przede wszystkim dwiema cechami:

1. Zawierają pola o wysokiej entropii (High Entropy Values). Wysoka entropia oznacza, że kombinacja takich informacji jest bardzo charakterystyczna i trudna do odgadnięcia — może to być dokładna wersja platformy, pełna lista marek i wersji czy architektura urządzenia. Prawdziwa przeglądarka zwraca te informacje na żądanie, zamiast przekazywać wszystkie od razu.

2. CH nie jest oceniane osobno, lecz porównywane z innymi fingerprintami. Rzeczywiste systemy identyfikacji często sprawdzają, czy CH zgadza się z UA, czy CH i fingerprinty warstwy transportowej, takie jak TLS JA3/JA4, pasują do tej samej rodziny przeglądarek, czy CH jest spójne z właściwościami JavaScript, takimi jak navigator.platform, współbieżność i współczynnik pikseli urządzenia (DPR), a także czy zgadza się z cechami platformy systemu operacyjnego.

Prowadzi to do kluczowej zasady: trudność nie polega na zmianie pojedynczego pola, lecz na tym, by wszystkie pola wyglądały tak, jakby pochodziły z jednego prawdziwego urządzenia. Prawie każde pole można zmodyfikować w izolacji. Prawdziwym wyzwaniem jest połączenie marki, wersji platformy, UA, DPR, pamięci, architektury, fingerprintu TLS i innych sygnałów w jeden logiczny profil urządzenia. Dlatego konfiguracje, w których „wypełniono wszystkie pola”, nadal mogą wyglądać bardzo niespójnie.

3. Jakie błędy spójności fingerprintu występują najczęściej?

Gdy wiemy już, że kluczowa jest spójność, łatwo zrozumieć, dlaczego wiele konfiguracji parametrów zawodzi. Typowe błędy to:

• CH nie zgadza się z UA (najczęstszy przypadek): UA wskazuje macOS 14.1, ale CH zwraca wersję platformy, która w rzeczywistości nie istnieje;
• Mobilny UA ze znacznikiem ?0: na prawdziwym urządzeniu mobilnym zwykle powinno być ?1;
• Nieprawidłowe wyprowadzenie pełnej listy wersji: np. główna wersja przeglądarki to 120, ale pełne cechy wersji wyglądają jak stare 115;
• DPR, pamięć i inne wartości nie pasują do rzeczywistego typu urządzenia: np. urządzenie Apple pokazuje nienaturalnie niski współczynnik pikseli albo zwykły komputer z Windows zgłasza tylko 1 GB pamięci;
• Ignorowanie różnic pomiędzy przeglądarkami: np. wymuszanie pola w przeglądarce, która go nie obsługuje, albo zwracanie przez dany silnik wartości, której ten silnik nigdy faktycznie nie udostępnia.

Takie sprzeczności są wyraźnie widoczne w systemach identyfikacji urządzeń. Ich wspólną przyczyną jest brak traktowania środowiska jako jednego spójnego zestawu.

4. Co naprawdę oznacza „poprawna konfiguracja”?

Zamiast myśleć o „wypełnianiu pól”, lepiej mówić o utrzymywaniu spójnego profilu środowiska. Zwykle oznacza to kilka zasad:

• Powiązanie CH z UA: wyprowadzenie odpowiedniego zestawu CH — marki, platformy i wersji — według rzeczywistych reguł silnika oraz wersji przeglądarki, zamiast składania przypadkowych wartości;
• Przestrzeganie sposobu zwracania pól o wysokiej entropii: domyślnie zwracać informacje o niskiej entropii, wartości o wysokiej entropii udostępniać na żądanie tak jak prawdziwa przeglądarka i nie zwracać pól, których dany browser nie obsługuje;
• Zachowanie zgodności właściwości JS, nagłówków HTTP i cech systemu: DPR powinien pasować do rozdzielczości ekranu, pamięć do typu platformy, znacznik mobilny do UA, a architektura do logiki całego profilu systemowego;
• Powiązanie z fingerprintem warstwy transportowej: cechy takie jak TLS/JA3/JA4 również powinny odpowiadać deklarowanej wersji przeglądarki.

W skrócie: prawdziwym wyzwaniem jest stworzenie z CH, UA, środowiska JavaScript i cech systemu jednego spójnego profilu zachowania przeglądarki, a nie wypełnienie jak największej liczby pól.

5. Jaki to ma związek z zarządzaniem środowiskami wielu kont?

Osoby zajmujące się transgranicznym e-commerce, reklamą w social mediach czy własnymi sklepami mogą zapytać, co te zasady mają wspólnego z „tworzeniem oddzielnych środowisk przeglądarki dla różnych kont biznesowych”. Związek jest prosty: warunkiem zarządzania środowiskami jest wewnętrzna spójność każdego środowiska.

• Przy wielu kontach i regionach ręczne dobieranie UA, systemu operacyjnego, rozdzielczości i innych parametrów dla każdej konfiguracji jest podatne na błędy. Lepiej, aby narzędzie na podstawie wybranego systemu i wersji silnika automatycznie generowało wzajemnie zgodny zestaw parametrów, ograniczając poprawki po sprzecznych zmianach poszczególnych pól.
• Konta biznesowe dla różnych regionów i platform powinny mieć odrębne środowiska, których parametry są spójne wewnętrznie, zamiast korzystać z jednej puli „szablonowych parametrów” i wyglądać nienaturalnie podobnie na poziomie urządzenia.
• Przy zmianie proxy na inny region bardziej przypomina zachowanie prawdziwego urządzenia sytuacja, w której wersja systemu, model urządzenia i inne cechy pozostają logicznie spójne w ramach danego środowiska, niż „zmiana samego IP przy całkowicie niezmienionych pozostałych parametrach”.

Właśnie takie problemy ze spójnością rozwiązują narzędzia do zarządzania środowiskami przeglądarki dla wielu kont. Podczas tworzenia środowiska PurpleMark udostępnia wspólny panel konfiguracji systemu operacyjnego, wersji silnika Chromium, User-Agent, rozdzielczości, strefy czasowej, języka, CPU/pamięci, Canvas, WebGL, TLS oraz innych parametrów urządzenia i fingerprintu. Po wybraniu regionu i przeznaczenia konta środowisko można wygenerować według jednego spójnego schematu zamiast każdorazowo ręcznie składać parametry przy logowaniu. W praktyce zarządzana jest ogólna spójność oraz możliwość ponownego użycia ustawień konta, środowiska przeglądarki i sieci w jednej przestrzeni roboczej, a nie obchodzenie konkretnego systemu detekcji.

6. Podsumowanie

Zamrożenie UA wyznacza nowy etap browser fingerprintingu: nie liczy się już tylko to, jakie pola istnieją, ale czy są ze sobą spójne. Gdy Client Hints przejmują rolę źródła sygnałów o wysokiej entropii, zrozumienie powiązań między CH, UA, cechami systemu i fingerprintami transportowymi jest ważniejsze niż zapamiętywanie długiej listy nazw pól.

Jeśli utrzymujesz tylko kilka prawdziwych, zgodnych z zasadami kont biznesowych, nie ma potrzeby koncentrowania się na walce z detekcją. Praktyczniejsze jest użycie narzędzia do zarządzania środowiskami, takiego jak PurpleMark, aby region, system i parametry przeglądarki każdego konta były jasne, spójne i wielokrotnego użytku, co ogranicza problemy wywołane sprzecznymi ustawieniami już u źródła.

(Uwaga: artykuł ma wyłącznie charakter edukacyjny i wyjaśnia techniczne podstawy fingerprintingu przeglądarek. Zawsze przestrzegaj regulaminów platform i korzystaj z legalnych, zgodnych kont.)