User-Agent Wyjaśnione: Od UA Strings i odcisków palców przeglądarki do Client Hints

Otwórz panel Network w narzędziach deweloperskich przeglądarki i prawie zawsze znajdziesz nagłówek User-Agent. Wygląda na krótkie wprowadzenie: która przeglądarka wykonuje żądanie, na jakim systemie operacyjnym działa i jaką wersję podaje.

To sprawia, że kusi, by traktować nagłówek jako identyfikator urządzenia — lub zakładać, że zmiana jednej linii może zamienić przeglądarkę w inne urządzenie. Obie te teorie są tylko częściowo trafne.

Ciąg User-Agent, czyli UA, to informacja o zgodności zadeklarowana przez klienta. Nie jest to zaufane dane tożsamości, a klient może je modyfikować. Jednak nie istnieje w izolacji. Strona może porównać UA z Client Hints, JavaScript API, właściwościami ekranu, czcionkami, Canvas, WebGL, kontekstem sieciowym i zachowaniem. Użyteczne pytanie brzmi więc nie tylko, czy UA można zmienić, ale jaką rolę odgrywa w pełnej powierzchni obserwowalności przeglądarki.

Niniejszy artykuł wykorzystuje HTTP standardy oraz badania nad odciskiem palca przeglądarki, aby odpowiedzieć na cztery pytania:

1. Dlaczego UA ciąg wygląda jak dzieło archeologiczne przeglądarki?
2. Ile danych identyfikacyjnych może UA wnieść i jak powinniśmy interpretować badania?
3. Dlaczego zmiana tylko UA może stworzyć bardziej oczywistą niespójność?
4. Co tak naprawdę zmieniły UA Reduction i User-Agent Client Hints?

W tym artykule UA oznacza przede wszystkim nagłówek HTTP User-Agent request. Omawiamy też navigator.userAgent i navigator.userAgentData w JavaScript. Te interfejsy są ze sobą powiązane, ale nie trwale identyczne w każdej przeglądarce i kontekście.

1. Czym jest User-Agent?

Sekcja 10.1.5 RFC 9110 definiuje User-Agent jako pole zawierające informacje o agencie użytkownika, który wywołał żądanie. Jego uproszczona gramatyka to:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

Mówiąc prosto, ciąg zaczyna się od nazwy produktu i może zawierać wersję. Więcej produktów lub komentarzy może się pojawić. Standard uwzględnia zastosowania takie jak obejścia interoperacyjności, diagnostyka i analityka, ale zaleca również implementacjom, by nie ujawniały zbędnych szczegółów: dłuższy, bardziej szczegółowy UA zwiększa zarówno rozmiar żądania, jak i ryzyko odcisku palca.

Nowoczesny Chromium desktopowy UA może wyglądać tak:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

Podzielenie ciągu na space ujawnia kilka nazw, które wydają się niezwiązane z Chrome:

Token	Co to ogólnie oznacza dzisiaj	Częste błędne odczytanie
Mozilla/5.0	Token zgodności historycznej	Przeglądarka musi być Firefox lub Mozilla produktem
Windows NT 10.0	Kategoria Windows platform; zredukowany UA nie może niezawodnie odróżnić Windows 10 od 11	Komputer musi działać Windows 10
Win64; x64	Wskazówka, że to Windows 64-bitowy na architekturze x86-64	Potwierdza dokładny fizyczny model procesora
AppleWebKit/537.36	Token genealogii silnika i kompatybilności	Chrome nadal korzysta z pełnej implementacji Safari
KHTML, like Gecko	Język zgodności historycznej	Zarówno KHTML, jak i Gecko działają
Chrome/145.0.0.0	Rodzina Chrome/Chromium i wersja majorowa; niższe komponenty mogą być redukowane	Ujawnia dokładną wersję łatki
Safari/537.36	Token zachowany dla kompatybilności ze starszymi stronami	Przeglądarka musi być Safari

UA stał się rozwlekły, ponieważ wczesne strony często opierały się na nazwach przeglądarek. Nowe przeglądarki musiały deklarować kompatybilność ze starszymi produktami, aby otrzymać poprawną stronę. Te deklaracje kumulowały się z czasem, tworząc historyczny zapis, którego nie da się odczytać dosłownie.

Pierwsza zasada parsowania UA jest więc prosta: jest to protokół zgodności, a nie ścisły opis urządzenia.

2. Dlaczego strony internetowe nadal używają UA?

UA nie służy tylko do śledzenia. Legalne zastosowania obejmują:

• służąc jako awantura do starszej przeglądarki z znanym problemem z kompatybilnością;
• wybór odpowiedniego instalatora lub formatu pobierania;
• znajdowanie specyficznych dla wersji awarii w logach diagnostycznych;
• mierzenie szerokich dystrybucji rodzin przeglądarek, platform i głównych wersji;
• identyfikowanie niemożliwych kombinacji w ruchu automatycznym lub złośliwym.

Problem zaczyna się, gdy UA wąchanie przechodzi z wąskiego zabezpieczenia kompatybilności do możliwości zgadywania według nazwy produktu. Kod może zobaczyć Chrome i założyć, że istnieje konkretne API. To założenie może zawiódć w osadzonym WebView, przeglądarce wyprowadzonej od Chromium, przeglądarce z polityką korporacyjną, zamrożonym UA lub kliencie, który zmienił nagłówek.

Bardziej solidna kolejność operacji to:

1. Testuj wymagane API lub zachowanie bezpośrednio, gdy tylko możliwe jest wykrywanie możliwości.
2. Gdy identyfikacja przeglądarki jest nieunikniona, należy używać utrzymywanego parsera zamiast doraźnego wyrażenia regularnego.
3. Przechowuj tylko te grube kategorie, których produkt naprawdę potrzebuje.
4. Zapewnij rezerwowy dla nieznanych marek, nieznanych wersji i brakujących pól.

3. Czy UA odcisk palca w przeglądarce?

Dokładniej mówiąc, UA jest jedno wejście do odcisku palca przeglądarki, a nie zazwyczaj cały odcisk palca.

Odcisk palca w przeglądarce nie wymaga tajnego numeru seryjnego. Mierzy on zbiór stosunkowo stabilnych, wyróżniających cech ujawnionych przez przeglądarkę. UA dostarcza wskazówek dotyczących rodziny przeglądarek, wersji i platformy. Wymiary ekranu, czcionki, strefy czasowe, Canvas, WebGL, AudioContext i inne interfejsy dostarczają dodatkowych informacji.

Badanie przeprowadzone przez Laperdrixa i współpracowników, Browser Fingerprinting: A Survey, omawia te techniki jako formę uznania bezpaństwowego. Strona nie musi koniecznie najpierw pisać Cookie; Może próbować powiązać wizyty z atrybutów udostępnianych przez przeglądarkę. "Bezstanowe" nie oznacza, że serwer nic nie przechowuje. Oznacza to, że materiał rozpoznawczy nie zależy od trwałego identyfikatora po stronie klienta.

1. Co oznacza wynik 10-bitowy artykułu?

W badaniu z Panopticlick z 2010 roku How Unique Is Your Web Browser? Peter Eckersley przeanalizował około 470 000 odcisków palców przeglądarki. Gazeta donosiła, że:

• Cały odcisk palca zawierał średnio około 18,1 bitów informacji identyfikacyjnych w tej próbce;
• Intuicyjnie mówiąc, średni odcisk palca pojawił się mniej więcej raz na 286 777 przeglądarkach;
• Tabela podawała około 10,0 bitów średniej informacji dla samego ciągu UA;
• wśród przeglądarek z włączoną Flash lub Javą 94,2% kompletnych odcisków palców było unikalnych.

Samoinformacja jest zwykle zapisywana jako:

I(x) = -log₂ P(x)

Jeśli dany UA występuje z prawdopodobieństwem 1/1024 w populacji, jego obserwacja dostarcza 10 bitów informacji. Czy to nie oznacza, że UA ma dokładnie 1 024 możliwe wartości lub że jednoznacznie identyfikuje daną osobę. Opisuje, ile niepewności ta obserwacja średnio usuwa.

2. Dlaczego wynik z 2010 roku nie jest stały dla dzisiejszego internetu?

Wynik pozostaje istotny, ale wymaga co najmniej trzech ustaleń:

• Odwiedzający stronę testującą prywatność nie byli losową próbą wszystkich użytkowników internetu;
• Różnorodność przeglądarek, wtyczek i UA wersji w 2010 roku znacznie różniła się od dzisiejszego ekosystemu;
• UA Reduction, kurczące się powierzchnie wtyczek oraz zabezpieczenia antyodciskowe zmieniły rozkład obserwowalnych atrybutów.

Badanie potwierdza tezę, że UA i inne cechy mogą dostarczać mierzalnych informacji rozróżniających. Nie wspiera to stwierdzenia, że UA zawsze ma dziś dokładnie 10 bitów entropii. Siła odcisków zależy od populacji, okna czasowego, polityk przeglądarki oraz kombinacji sygnałów.

4. Dlaczego zmiana tylko UA może się obrócić przeciwko nim?

UA jest deklaracją klienta bez dowodu kryptograficznego. Serwer nie może odczytać fabrycznej prawdy urządzenia z tego nagłówka. Może jednak sprawdzić, czy różne obserwacje są rozsądnie kompatybilne.

Załóżmy, że UA twierdzi, że jest przeglądarką mobilną, ale strona nie zauważa punktów styku, okno konsekwentnie przypomina wyświetlacz na pulpicie, a Client Hints raportuje platformę desktopową. Każda obserwacja może mieć uzasadniony wyjątek. Kilka stabilnych sprzeczności razem może nadal tworzyć wzorzec klasyfikowalny.

Artykuł z Panopticlick roku już dokumentował podobne przypadki: niektóre przeglądarki twierdziły, że są iPhone, a jednocześnie obsługiwały Flash, a niektóre Firefox UA pojawiły się wraz z funkcjami pamięci masowej dostępnymi tylko w Internet Explorerze. Badanie z 2018 roku FP-Scanner roku analizowało ten problem systematycznie. Niektóre rozszerzenia anty-fingerprintingowe i narzędzia do podszywania się wprowadzały niespójności między interfejsami, pozwalając detektorowi identyfikować zmodyfikowane atrybuty, a w niektórych przypadkach wnioskować o oryginalnej rodzinie przeglądarek lub systemów operacyjnych.

Nie każda niespójność jest złośliwa. Zdalne pulpity, narzędzia do dostępności, polityki korporacyjne, warstwy kompatybilności oraz rzadki sprzęt mogą tworzyć nietypowe kombinacje. Staranny system ryzyka powinien traktować niespójność jako dowód probabilistycznym, a nie automatyczny powód do zablokowania użytkownika.

Do zarządzania profilami przeglądarki ważne są trzy właściwości:

• Spójność wewnętrzna: Sygnały UA, Client Hints, platformy, architektury, dotyku i ekranu nie powinny sobie bezpośrednio przecząć.
• Stabilność w czasie: profil długotrwały nie powinien zmieniać się drastycznie przy każdym starcie bez powodu.
• Prawdopodobna różnorodność: profile mogą się różnić, ale rzadkie mechanicznie generowane kombinacje niekoniecznie są bezpieczniejsze.

Badanie FP-STALKER wykazało również, że zmiana atrybutów nie zapobiega automatycznie powiązaniu. Model może wykorzystywać stabilne atrybuty i prawdopodobne zmiany wersji, aby łączyć wcześniejsze i późniejsze odciski palców.

5. Jaki problem UA Reduction rozwiązuje?

Do niemal każdej prośby wysyłany jest tradycyjny UA. Każdy punkt końcowy pierwszej lub trzeciej strony, który otrzyma żądanie, może je odczytać pasywnie. Im dokładniejszy ciąg tekstów, tym więcej domyślnych informacji wyróżniających otrzymuje każdy odbiorca.

Chromium User-Agent Reduction plan ogranicza tę domyślną szczegółowość:

• Począwszy od Chrome 101, wersje desktopowe minor, build i patch zostały ograniczone do 0.0.0;
• późniejsze fazy zunifikowane wersje systemów operacyjnych dla pulpitów, szczegóły CPU oraz informacje o Android urządzeniach;
• Zredukowany Android UA wykorzystuje stałe wartości platformy i modelu, takie jak Android 10; K;
• Strony, które naprawdę wymagają więcej szczegółów, mogą żądać User-Agent Client Hints.

Format uproszczony można podsumować następująco:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

Redukcja zmniejsza pasywną powierzchnię odcisków palców w UA dziedziczą. Nie eliminuje to fingerprintingu przeglądarki. Główna wersja, ogólna platforma i stan mobilny mogą pozostać widoczne, podczas gdy inne API, właściwości sieci i zachowanie mogą nadal dostarczać informacji.

6. Jak działa User-Agent Client Hints?

Ogólny mechanizm jest zdefiniowany w RFC 8942, natomiast WICG User-Agent Client Hints szkicu opisuje pola specyficzne dla UA. Podejście dzieli informacje, które kiedyś istniały w nieustrukturyzowanym ciągu na pola ustrukturyzowane, rozróżniając wskazówki o niskiej entropii, które mogą być domyślnie wysyłane, od wskazówek o wysokiej entropii, o które strona zwykle prosi wprost.

Uproszczone początkowe żądanie może wyglądać następująco:

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"

Jeśli serwer naprawdę potrzebuje architektury i bitowości do wyboru instalatora, może odpowiedzieć następująco:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Gdy przeglądarka obsługuje mechanizm i spełnione są wymagania dotyczące bezpieczeństwa oraz polityki, późniejsze żądanie może obejmować:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

Do UA Client Hints należą:

Pole	Typowy cel	Poziom informacji
Sec-CH-UA	Lista marek i głównych wersji	Zazwyczaj niska entropia
Sec-CH-UA-Mobile	Czy klient preferuje doświadczenie mobilne	Zazwyczaj niska entropia
Sec-CH-UA-Platform	Kategoria szerokiego programu	Zazwyczaj niska entropia
Sec-CH-UA-Arch	Architektura CPU	Wysoka entropia; prośba, gdy jest potrzebna
Sec-CH-UA-Bitness	Bitowość architektury	Wysoka entropia; prośba, gdy jest potrzebna
Sec-CH-UA-Platform-Version	Wersja platformowa	Wysoka entropia; prośba, gdy jest potrzebna
Sec-CH-UA-Full-Version-List	Pełne wersje dla zgłoszonych marek	Wysoka entropia; prośba, gdy jest potrzebna
Sec-CH-UA-Model	Model urządzenia	Wysoka entropia; prośba, gdy jest potrzebna

Trzy szczegóły inżynieryjne łatwo przeoczyć.

1. Client Hints nie są wysyłane automatycznie

Wskazówki o niskiej entropii mogą pojawiać się domyślnie. Wskazówki o wysokiej entropii zwykle wymagają Accept-CH odpowiedzi. Początkowa nawigacja, podzasoby, polityka uprawnień, bezpieczny transport oraz wsparcie dla przeglądarki mogą wpłynąć na to, co się pojawi. Serwer musi pozwolić, aby wszystkie opcjonalne pola były nieobecne.

2. Lista marek celowo testuje odporność parsera

Sec-CH-UA może zawierać wiele marek oraz syntetyczną markę służącą do testowania kompatybilności. Kod nie może zakładać, że pierwszy wpis zawsze jest nazwą produktu i nie może się zawiódć, gdy pojawi się nieznana marka. Analizuj uporządkowane pole, ignoruj wpisy, których nie rozpoznajesz, i zostaw miejsce na przyszłe marki.

3. Odpowiedzi różniące się wskazówkami wymagają prawidłowego zarządzania pamięcią podręczną

Jeśli architektura, platforma lub inna wskazówka zmienia odpowiedź, poprawnie skonfiguruj Vary lub równoważną strategię klucza podręcznego. W przeciwnym razie współdzielona pamięć podręczna może przekazywać treści generowane dla jednej klasy urządzeń innej.

7. Czy Client Hints bardziej prywatne niż tradycyjne UA?

Poprawiają sposoby ujawniania informacji, ale nie zapewniają odporności na pobieranie odcisków palców.

Tradycyjny UA ukazuje duży, nieustrukturyzowany pakiet pasywnie i domyślnie. Client Hints podziel ten pakiet na pola, spraw, by żądania informacji o wyższej entropii były bardziej wyraźne i dały przeglądarce możliwość zastosowania polityk, uprawnień lub kontroli prywatności budżetowej.

Jednak architektura, pełne wersje, wersje platform i modele urządzeń mogą nadal zwiększać rozpoznawalność. RFC 8942 wyraźnie traktuje prywatność i wydajność jako ograniczenia projektowe. Deweloperzy powinni zapytać:

• Czy ta funkcja rzeczywiście wymaga tego pola?
• Czy wykrywanie możliwości lub wybór użytkownika może je zastąpić?
• Czy aplikacja może przechowywać tylko kategorię grubą?
• Jak długo surowe wartości są przechowywane i kto może do nich mieć dostęp?
• Czy zasoby zewnętrzne otrzymają te same wskazówki?

8. Wytyczne inżynieryjne dotyczące obsługi UA po stronie serwera

1. Nigdy nie używaj UA jako dowodu tożsamości lub autorytetu

UA może wspierać wybór prezentacji oraz rozwiązania kompatybilności. Nie powinien określać tożsamości, autoryzacji, funduszu powierniczego płatności ani granicy bezpieczeństwa. Wartość kontrolowana przez klienta nie może pełnić funkcji uwierzytelniania kontroli dostępu.

2. Preferuj wykrywanie zdolności zamiast list przeglądarskich

Gdy front-end potrzebuje API, testuj tę funkcjonalność bezpośrednio:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

Wykrywanie możliwości lepiej radzi sobie z przeglądarkami pochodnymi, funkcjami eksperymentalnymi, politykami korporacyjnymi i przyszłymi wydaniami niż reguła typu "włącz to dla Chrome 145."

3. Akceptuj stany dziedziczone UA, Client Hints i nieznane

Podczas migracji serwer może otrzymywać tylko dziedziczone UA, zarówno UA, jak i Client Hints, lub znacznie zredukowane formy obu. Model danych powinien pozwalać unknown zamiast zgadywać dokładny system operacyjny lub model urządzenia, który wypełni każde pole.

4. Zmniejszenie logarytmiczności granularności

Jeśli analityka potrzebuje tylko desktopu versus urządzenia mobilnego, rodzina przeglądarek i główne wersje, nie zachowuj surowych UA ciągów i każdej wskazówki o wysokiej entropii w nieskończoność. Minimalizacja danych zmniejsza ryzyko prywatności i zapobiega traktowaniu drobnych zmian jako istotnego wymiaru przez pipeline analityczne.

5. Traktować anomalie jako dowód, a nie werdykty

UA twierdząca, że Windows podczas gdy jedno API zachowuje się inaczej, jest co najwyżej jednym sygnałem ryzyka. Środowiska korporacyjne, wirtualizacja, sesje zdalne, warstwy kompatybilności oraz technologie wspomagające mogą powodować prawdziwe anomalie. Przekształcenie jednej rozbieżności w automatyczną decyzję o oszustwie powoduje fałszywe alarmy.

9. Jak UA powinno być skonfigurowane w środowiskach wieloprofilowych?

W przypadku testów międzyregionalnych, podglądów reklam, operacji kont i izolacji prywatności celem nie powinno być tworzenie najbardziej nietypowych UA. Profil powinien być wyjaśniający, stabilny i kompatybilny z otoczeniem.

Przejrzyj następujące kwestie po kolei:

1. Wersja przeglądarkowa: UA główna wersja powinna być wiarygodna dla samego silnika i jego możliwości.
2. System operacyjny: Platforma UA, Client Hints platforma oraz kategoria JavaScript widocznych platformach powinny być kompatybilne.
3. Architektura i bitowość: UA, Client Hints oraz środowisko wykonywalne nie powinny składać bezpośrednio sprzecznych twierdzeń.
4. Forma urządzenia: Deklaracja mobilna powinna mieć sens w połączeniu z obsługą dotyku, widokiem, proporcjami pikseli i wzorcami interakcji.
5. Kontekst regionalny: język, strefa czasowa, geolokalizacja i wyjście proxy nie muszą się mechanicznie pokrywać, ale powinny mieć sens dla rzeczywistego workflow.
6. Stabilność profilu: gdy jedno konto lub tożsamość testowa ponownie używa długowiecznego profilu, unikaj zmiany platformy i głównej wersji bez powodu.

Obecna konwersja profilu PurpleMark mapuje wybrany system operacyjny na platformę UA i najpierw próbuje wyodrębnić wersję przeglądarki z skonfigurowanego tokena Chrome/ lub CriOS/. Gdy nie istnieje żadna użyteczna wersja, to rozsądny awans względem głównej wersji obecnego silnika. Celem nie jest podszywanie się pod jeden izolowany ciąg znaków, lecz umieszczenie UA konfiguracji w spójnym modelu profilu przeglądarki.

Izolacja profilu i spójność parametrów mogą zmniejszyć korelację techniczną i błędy testowania. Nie mogą zagwarantować, że konta nigdy nie zostaną połączone, i nie zastępują zasad platformy, danych kont, informacji o płatnościach ani odpowiedzialnych praktyk operacyjnych. Korzystaj z tych funkcji wyłącznie do ochrony prywatności zgodnie z prawem, testów autoryzowanych oraz zgodności z działalnością biznesową.

10. Najczęściej zadawane pytania

P1: Czy zmiana UA zamienia przeglądarkę w inną przeglądarkę?

Nie. Zmienia część tego, co deklaruje klient. Nie zastępuje silnika JavaScript, potoku renderowania, stosu sieciowego ani obsługiwanych API webowych.

P2: Czy strona internetowa potrafi odczytać "prawdziwą UA"?

Nie istnieje uniwersalny sprzętowy "prawdziwy UA", który każda strona internetowa mogłaby obejść przeglądarkę, aby go przeczytać. Strona może jednak porównać Client Hints, testy zdolności i inne sygnały odcisków palców, znaleźć niezgodne twierdzenia i wyciągnąć probabilistyczne wnioski.

P3: Czy zredukowany UA może odróżnić Windows 10 od Windows 11?

Zmniejszone UA legacy zwykle nie mogą tego robić niezawodnie, ponieważ oba mogą raportować Windows NT 10.0. Przeglądarka obsługująca UA Client Hints może dostarczyć bardziej szczegółowe informacje o wersji platformy po tym, jak strona o to zażąda. Serwery muszą nadal obsługiwać brakujące pola i różnice w mapach.

P4: Czy wyłączenie JavaScript powstrzymuje UA narażenie?

Nie całkowicie. HTTP User-Agent to nagłówek żądania i może być wysłany wraz z żądaniem strony przed uruchomieniem JavaScript strony. Wyłączenie JavaScript usuwa niektóre powierzchnie kolekcji, ale także psuje znaczną część nowoczesnej sieci.

P5: Czy Client Hints całkowicie zastąpi User-Agent?

Nie zakładaj tego w najbliższej perspektywie. Wielu klientów i serwerów nadal polega na starszych UA, podczas gdy UA Client Hints wsparcie się różni. Traktuj Client Hints jako postępowe ulepszanie: preferuj informacje uporządkowane, gdy są dostępne, ale zachowaj awaryjne dla UA dziedziczonych i nieznanych stanów.

P6: Czy losowo generowany UA poprawia anonimowość?

Niekoniecznie. Losowanie jednego pola może powodować sprzeczności z wersją, platformą, sygnałami dotykowymi i renderującymi. Dla profilu długowiecznego wspólna, stabilna, wewnętrznie kompatybilna konfiguracja jest zwykle bardziej obronna niż częste zmiany losowe.

11. Podsumowanie

User-Agent nie jest ani wiarygodnym poświadczeniem tożsamości, ani nieistotnym nią. Znajduje się na styku kompatybilności sieciowej, prywatności i analizy ryzyka. Dla deweloperów jest to dane kompatybilności, obciążone historią. Dla badaczy odcisków palców jest to atrybut posiadający mierzalne dane statystyczne. Dla producentów przeglądarek jest to domyślna powierzchnia ekspozycji, którą trzeba ograniczyć.

Kluczowe idee mieszczą się w trzech stwierdzeniach:

• Nie czytaj UA dosłownie; zawiera wiele historycznych tokenów kompatybilności.
• Nie oceniaj UA w izolacji; Praktyczne rozpoznanie wynika z kombinacji sygnałów i ich ewolucji w czasie.
• Nie myśl o Client Hints jedynie jako o "więcej UA dziedzinach"; Ich wartość tkwi w ustrukturyzowanym, opartym na żądaniach i możliwym do zarządzania ujawnianiem informacji.

Gdy system przechodzi od identyfikowania nazwy przeglądarki do testowania potrzebnych funkcji—a następnie od zbierania wszystkich dostępnych szczegółów do żądania tylko tego, co konieczne—UA wraca do swojej właściwej roli: wskazówki zgodności, a nie prawdy tożsamości.

Bibliografia i normy

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.