Strony testujące fingerprint pokazują wiele danych, które witryny i tak mogą odczytać. Te sześć kontroli pomaga wykryć sprzeczności między przeglądarką, systemem, regionem, siecią i renderowaniem, bo niespójne sygnały często rzucają się w oczy bardziej niż pojedyncza nietypowa wartość.
Otwórz dowolną stronę do testowania fingerprintu przeglądarki, a zobaczysz długą listę pól: UA, ekran, strefę czasową, czcionki, wyniki renderowania Canvas i parametry sprzętowe. Wiele osób najpierw patrzy na „unikalność”, ale w praktyce jest ona najmniej istotna. Ważniejsze jest to, czy wszystkie te dane są ze sobą zgodne.
Co witryny mogą odczytać bez dodatkowych mechanizmów
Fingerprint nie jest przechowywany jak cookie. Cookie możesz usunąć, zablokować albo ominąć w trybie prywatnym; fingerprint wynika z konfiguracji samej przeglądarki i urządzenia. UA zawiera typ i wersję przeglądarki oraz system operacyjny i jego wersję. Dochodzą do tego zainstalowane wtyczki, rozdzielczość i głębia kolorów ekranu, lista czcionek, strefa czasowa i preferowany język, typ CPU, model GPU i ilość pamięci, adres IP, operator i typ połączenia, a także wyniki renderowania zwracane przez interfejsy HTML5, takie jak Canvas i WebGL. Razem tworzą one identyfikator, który zwykle prawie się nie zmienia po zmianie IP, wyczyszczeniu cookies czy uruchomieniu trybu prywatnego. Platformy wykorzystują tę samą zasadę, gdy oceniają, czy konta mogą być ze sobą powiązane.
Najpierw porównaj trzy elementy z systemem
Najlepiej zacząć od User Agenta, bo to sposób, w jaki przeglądarka opisuje samą siebie. Skopiuj UA ze strony testowej, sprawdź wersję przeglądarki w jej ustawieniach i wersję systemu operacyjnego w ustawieniach systemowych. Jeśli system albo wersja jądra podana przez UA nie zgadza się z rzeczywistym urządzeniem lub wyraźnie odstaje od obecnie popularnych wersji, jest to jedna z najłatwiejszych do zauważenia niespójności.
Strefa czasowa powinna pasować do regionu wyjścia sieciowego. Strony testowe zwykle pokazują bieżącą strefę bezpośrednio, a prosty skrypt odczytujący strefę zwróci tę samą wartość. Dodatkowo sprawdź na dowolnej stronie do wyszukiwania IP, do jakiego regionu przypisany jest adres wyjściowy. Jeśli oba wskazania dotyczą różnych regionów, warto usunąć tę rozbieżność.
Język i region to osobno słabe sygnały, ale razem bywają przydatne. Sprawdź listę zwracaną przez navigator.language i navigator.languages i porównaj ją z językami typowymi dla regionu wyjścia. Strefa czasowa z USA, język chiński i wyjście w Europie razem zwracają większą uwagę niż każdy z tych elementów osobno.
Ekran, wyjście sieciowe i cechy renderowania
Przy parametrach ekranu i sprzętu sprawdź dwie rzeczy: czy wartości są typowe i czy pasują do typu urządzenia deklarowanego przez UA. Rozdzielczość, współczynnik pikseli, dostępny obszar ekranu, liczbę rdzeni CPU i pamięć można analizować łącznie. Rozdzielczość charakterystyczna dla telefonu zestawiona z desktopowym UA to klasyczna sprzeczność.
WebRTC warto kontrolować oddzielnie, ponieważ może ujawniać rzeczywiste informacje o sieci. Strony testowe zwykle pokazują je jako osobną pozycję. Sprawdź, czy zwracany jest lokalny adres urządzenia, na przykład zaczynający się od 192.168 lub 10, albo nawet prawdziwy publiczny adres wyjściowy. Jeśli proxy jest włączone, a rzeczywisty adres nadal się pojawia, oznacza to, że ten ruch nie przechodzi przez proxy. To ma najwyższy priorytet.
W przypadku Canvas i WebGL sprawdź, czy wyniki są stabilne i czy pasują do deklarowanego modelu GPU. Ważny szczegół: jeśli kilka środowisk uruchomionych równolegle na tej samej maszynie zwraca dokładnie te same wartości renderowania, łatwiej je ze sobą powiązać niż wtedy, gdy wartości zawierają pewną zmienność lub szum.
Sprzeczności wyróżniają się bardziej niż nieidealny realizm
Platformy nie wymagają, aby każde urządzenie było całkowicie unikalne. Próbują raczej ustalić, czy cały zestaw informacji wygląda tak, jakby pochodził z normalnej maszyny. Pojedyncza wartość, która nie jest do końca „realistyczna”, na przykład rzadka rozdzielczość, zwykle jest tylko słabym sygnałem. Gdy kilka pól sobie przeczy, niespójność staje się znacznie łatwiejsza do wykrycia. UA mówi Windows, ale lista czcionek wygląda jak z macOS; strefa czasowa wskazuje USA, język jest chiński, a wyjście znajduje się w Europie; rozdzielczość odpowiada telefonowi, ale UA deklaruje przeglądarkę desktopową. Jeden taki przypadek może zniwelować wiele drobnych korekt pozostałych parametrów. Dlatego podczas samokontroli najpierw warto znaleźć wyraźne sprzeczności, a dopiero potem dopracowywać szczegóły.
Jeśli chcesz poprawić tylko trzy rzeczy
Na pierwszym miejscu jest wyciek WebRTC, bo ujawnia rzeczywiste informacje sieciowe. Na drugim spójność strefy czasowej i języka z regionem wyjścia, ponieważ takie rozbieżności łatwo składają się na nietypowy profil. Na trzecim znajduje się obsługa Canvas i WebGL, aby ta sama maszyna nie ujawniała bezpośrednio stabilnej, unikalnej wartości renderowania.
Jest też praktyczna granica: wyłączenie lub mocne ograniczenie JavaScriptu może zablokować część zbierania danych, ale wyraźnie obniża użyteczność wielu stron. Przeglądarki nastawione na prywatność mają wbudowane mechanizmy ochronne i często wystarczają do codziennego korzystania z sieci, lecz są mniej elastyczne, gdy trzeba przez dłuższy czas utrzymywać kilka niepowiązanych ze sobą tożsamości.
Jak utrzymywać wiele środowisk
Nie chodzi o to, aby za każdym razem tworzyć całkowicie losowy fingerprint. Każde środowisko powinno być wewnętrznie stabilne, a jednocześnie różnić się od pozostałych. W PurpleMark można utworzyć osobne środowisko przeglądarki dla każdego konta, oddzielnie obsługiwać parametry takie jak Canvas, a następnie sprawdzić spójność każdego środowiska na stronie testowej. Środowisko, które przejdzie taką kontrolę, nadaje się do długotrwałego użycia.
Ostatecznie test fingerprintu ma dwa cele: zobaczyć, jakie informacje ujawniasz, i potwierdzić, że są one wewnętrznie spójne. Unikalność to element, którym warto przejmować się najmniej.
