Jak ocenić, czy środowisko przeglądarki antydetekcyjnej jest prawdziwe? Co zrobić, gdy wykrywanie odcisku palca wykazuje nieprawidłowości?

O tym, czy środowisko przeglądarki antydetekcyjnej jest prawdziwe, nie decyduje to, czy jakaś witryna kontrolna przyzna 90 czy 100 punktów. Bardziej miarodajne kryteria to: brak wyraźnych sprzeczności między sygnałami sieci, przeglądarki, systemu operacyjnego, sprzętu i uprawnień; to samo środowisko pozostaje stabilne po wielu uruchomieniach; a funkcje potrzebne witrynom biznesowym działają poprawnie.

Zielony wynik narzędzia kontrolnego nie oznacza, że każda platforma zaakceptuje dane środowisko; wynik czerwony nie musi też oznaczać, że środowisko jest bezużyteczne. Witryny kontrolne stosują własne reguły, bazy danych i modele punktacji, dlatego ostateczną ocenę należy oprzeć na konkretnych polach, docelowej witrynie i rzeczywistym scenariuszu biznesowym.

Co oznacza „prawdziwe” środowisko przeglądarki

Rozsądne środowisko zwykle spełnia cztery warunki:

1. Spójność wewnętrzna: silnik przeglądarki, User-Agent, system operacyjny, GPU, język, strefa czasowa i region sieciowy wzajemnie się wyjaśniają;
2. Stabilność w czasie: po restarcie kluczowe parametry nie zmieniają się w sposób chaotyczny i nieprzewidywalny;
3. Działanie funkcji: funkcje potrzebne w praktyce, takie jak logowanie, przesyłanie plików, wideorozmowy, płatności czy panel reklamowy, działają poprawnie;
4. Możliwość ustalenia pochodzenia: zespół wie, z którym kontem, proxy i osobą odpowiedzialną jest powiązane środowisko, a zmiany konfiguracji są odnotowywane.

„Pełna zgodność każdego parametru z fizycznym komputerem” nie jest warunkiem koniecznym. Przeglądarka sama zresztą obniża precyzję danych w trosce o prywatność. Na przykład dokumentacja MDN dotycząca deviceMemory wskazuje, że właściwość ta zwraca jedynie przybliżoną wartość pamięci, zaokrągloną i ograniczoną górnym oraz dolnym limitem; hardwareConcurrency może być też mniejsze niż rzeczywista liczba procesorów logicznych urządzenia. Wykryta wartość nie jest zatem raportem z badania sprzętu.

Przed sprawdzaniem ustal punkt odniesienia

Nie modyfikuj wielokrotnie parametrów w działającym środowisku z ważnymi kontami. Najpierw utwórz środowisko testowe, do którego nie logujesz się na konta biznesowe, i zapisz:

• wersję przeglądarki antydetekcyjnej i silnik Chromium;
• system operacyjny, User-Agent i rozdzielczość ekranu;
• typ proxy, wyjściowy adres IP, kraj i miasto;
• ustawienia języka, strefy czasowej i geolokalizacji;
• politykę WebRTC, DNS, Canvas, WebGL i czcionek;
• zainstalowane rozszerzenia i parametry uruchomieniowe.

Przeprowadź równoległą kontrolę za pomocą dwóch lub trzech narzędzi w tym samym czasie i zapisz zrzuty ekranu lub wyeksportuj wyniki. Potem zmieniaj tylko jedną zmienną naraz i porównuj z punktem odniesienia. Dzięki temu dowiesz się, czy nieprawidłowość pochodzi z proxy, konfiguracji przeglądarki, rozszerzeń, czy też z samej witryny kontrolnej.

Warstwa pierwsza: sprawdź wyjście sieciowe

Najpierw potwierdź, czy publiczny adres IP widoczny w żądaniach HTTP to adres proxy przypisany do środowiska; następnie sprawdź DNS, WebRTC i IPv6.

IP i DNS

Zanotuj wyjściowy adres IP, ASN, ISP, kraj, miasto i strefę czasową. Różne bazy danych mogą różnie oceniać miasto i typ proxy; konflikt na poziomie kraju lub ASN bardziej zasługuje na analizę niż odchylenie w pojedynczym mieście.

Jeśli zapytania DNS przechodzą przez sieć lokalną, a ruch do witryn przez proxy, witryna kontrolna może pokazać region DNS inny niż region wyjściowy. Najpierw sprawdź, czy proxy obsługuje zdalny DNS, czy przeglądarka lub system ma odrębne ustawienia DNS oraz czy rozszerzenia nie zmieniają żądań sieciowych.

WebRTC

WebRTC gromadzi adresy kandydujące ICE, aby nawiązać połączenie peer-to-peer. RFC 8828 wyjaśnia, że może to ujawnić dodatkowe publiczne lub prywatne adresy, a gdy proxy zezwala na bezpośrednie połączenia — obejść proxy i ujawnić prawdziwy publiczny adres IP.

Wykrycie adresu prywatnego nie musi oznaczać wycieku prawdziwego publicznego IP; 192.168.x.x, 10.x.x.x itd. to jedynie adresy sieci lokalnej. Najważniejsze jest to, czy w kandydatach ICE pojawia się inny publiczny adres IP niezwiązany z wyjściem proxy.

Nie wyłączaj WebRTC mechanicznie w każdej sytuacji. Wideokonferencje, rozmowy głosowe i komunikacja w czasie rzeczywistym mogą od niego zależeć. Wybierz rozwiązanie w zależności od zastosowania: pozwól WebRTC korzystać z domyślnej trasy proxy, używaj proxy obsługującego UDP lub TURN, ogranicz ujawnianie adresów lokalnych albo wyłącz WebRTC, gdy komunikacja w czasie rzeczywistym nie jest potrzebna. Po każdej zmianie testuj zarówno wyniki prywatności, jak i funkcje biznesowe.

Geolokalizacja

Współrzędne z API Geolocation przeglądarki mogą pochodzić z GPS, Wi-Fi, IP, sieci komórkowej lub danych podanych przez użytkownika. Specyfikacja geolokalizacji W3C wyraźnie stwierdza, że API nie gwarantuje zwrócenia rzeczywistej lokalizacji urządzenia.

Niewielka różnica między miastem wskazanym przez IP a współrzędnymi geolokalizacji nie musi być więc nieprawidłowością. Ważniejsze są: niewyjaśnione konflikty między krajem, strefą czasową, językiem i regionem działalności oraz to, czy witryna otrzymała już uprawnienie do lokalizacji.

Warstwa druga: sprawdź przeglądarkę i system operacyjny

Porównuj przede wszystkim następujące zestawienia:

• wersję silnika Chromium z główną wersją przeglądarki w User-Agent;
• system operacyjny w User-Agent z platform, UA Client Hints i zestawem czcionek;
• język interfejsu przeglądarki, Accept-Language, strefę czasową i format regionalny;
• rozdzielczość, współczynnik skali pikseli, rozmiar okna i obsługę dotyku;
• oznaczenia urządzeń mobilnych z rozmiarem ekranu, typem wskaźnika i cechami sprzętowymi.

Typową nieprawidłowością jest ręczna zmiana User-Agent bez synchronizacji z silnikiem lub podpowiedziami klienta; albo zadeklarowanie środowiska Windows jako macOS przy zachowaniu wyraźnie windowsowych czcionek, GPU i cech interakcji.

Najbezpieczniejsze podejście to nie ręczne wymyślanie poszczególnych wartości, lecz korzystanie ze sprawdzonych presetów systemowych, aby silnik, UA, platforma i powiązane parametry były aktualizowane jako jedna grupa. Po aktualizacji silnika wygeneruj lub zweryfikuj User-Agent od nowa — nie trzymaj się długotrwale wyraźnie przestarzałej wersji.

Warstwa trzecia: sprawdź sygnały sprzętowe i renderingowe

Canvas, WebGL, AudioContext, czcionki, CPU, pamięć, urządzenia multimedialne i ClientRects mogą brać udział w identyfikacji środowiska. Podczas kontroli skup się na tym, „czy zestawienie jest spójne” i „czy jest stabilne”, zamiast dążyć do uzyskania jednego unikalnego hasha.

WebGL i GPU

Jeśli środowisko deklaruje dany system operacyjny lub typ urządzenia, a producent WebGL, renderer i stan akceleracji sprzętowej jednocześnie tworzą zestawienie, które jest wyraźnie niemożliwe, wróć do presetów systemowych i sprawdź je. Nie zmieniaj nazwy producenta na inną markę tylko po to, aby przejść kontrolę w jednej witrynie; błędne zestawienia zwykle pociągają za sobą kolejne sprzeczności.

CPU i pamięć

hardwareConcurrency oznacza liczbę procesorów logicznych dostępnych dla przeglądarki; przeglądarka może celowo raportować niższą wartość. deviceMemory to z kolei zaokrąglona wartość przybliżona. Widok „4 rdzenie” czy „8 GB” nie pozwala wywnioskować rzeczywistego sprzętu i nie powinien skłaniać do natychmiastowej zmiany tylko dlatego, że nie zgadza się z fizycznym komputerem.

Sprawdzać należy raczej: czy wartość mieści się w zakresie obsługiwanym przez przeglądarkę, czy nie koliduje wyraźnie z typem urządzenia mobilnego lub desktopowego oraz czy to samo środowisko po restarcie pozostaje w rozsądny sposób stabilne.

Canvas i dźwięk

Polityka ochrony prywatności lub szumu może sprawić, że to samo fizyczne urządzenie w różnych środowiskach daje różne wyniki. Jeśli jednak hash w tym samym środowisku zmienia się przy każdym odświeżeniu, może to oznaczać zbyt silną randomizację, która pogarsza stabilność długotrwałych sesji.

Przetestuj to samo środowisko przy kolejnych odświeżeniach, po zamknięciu i ponownym otwarciu oraz przy starcie następnego dnia. Jeśli polityka została zaprojektowana jako „stabilny szum na poziomie środowiska”, to samo środowisko powinno wykazywać możliwą do wytłumaczenia ciągłość.

Warstwa czwarta: sprawdź pamięć masową, rozszerzenia i parametry uruchomieniowe

Izolacja środowiska obejmuje nie tylko parametry odcisków palców, lecz także cookie, Local Storage, IndexedDB, pamięć podręczną, Service Worker, rozszerzenia i historię pobrań.

Zaloguj się w dwóch środowiskach testowych do różnych witryn testowych i potwierdź, że cookie oraz pamięć lokalna nie mieszają się między sobą; sprawdź też, czy po wyczyszczeniu pamięci podręcznej, zaimportowaniu cookie lub przywróceniu środowiska dane są zgodne z oczekiwaniami.

Rozszerzenia to częste źródło zakłóceń. Mogą modyfikować User-Agent, proxy, nagłówki żądań, Canvas, WebRTC lub skrypty stron. Gdy wykryjesz nieprawidłowość, najpierw wyłącz w kopii testowej wszystkie zbędne rozszerzenia, a potem włączaj je pojedynczo. Niestandardowe parametry uruchomieniowe również wykluczaj pojedynczo, aby uniknąć sytuacji, w której kilka narzędzi jednocześnie modyfikuje ten sam sygnał.

Typowe nieprawidłowości i sposoby ich rozwiązywania

Objaw	Możliwa przyczyna	Zalecane postępowanie
Kraj IP nie zgadza się ze strefą czasową	Strefa czasowa ustawiona na stałe na lokalną albo błędnie rozpoznany region proxy	Najpierw zweryfikuj kraj proxy, potem ustaw strefę czasową zgodnie z IP lub rzeczywistym regionem działalności
Wyjście HTTP różni się od publicznego IP WebRTC	Bezpośrednie połączenie WebRTC, brak obsługi UDP przez proxy albo rozdzielenie tras	Dostosuj politykę trasowania WebRTC, przetestuj UDP/TURN oraz funkcje biznesowe
Wersja UA nie zgadza się z silnikiem	Ręcznie ustawiona UA jest przestarzała lub nie została zsynchronizowana po aktualizacji silnika	Użyj pasującego presetu, wygeneruj UA ponownie i ponownie sprawdź UA Client Hints
Oznaczenie macOS przy windowsowych czcionkach/GPU	Zmieniono tylko pola wierzchnie	Wróć do presetów systemowych, nie składaj ręcznie elementów z różnych systemów
Canvas zmienia się przy każdym odświeżeniu	Zbyt silny losowy szum lub konflikt z rozszerzeniem	Ustal politykę na poziomie środowiska, wyłącz kolidujące rozszerzenie i przetestuj ponownie
CPU lub pamięć oznaczone na czerwono	Witryna kontrolna interpretuje zaokrąglone wartości jako fizyczny sprzęt	Najpierw sprawdź definicje API przeglądarki, potem oceń, czy faktycznie występuje konflikt zestawień
Dwie witryny kontrolne dają sprzeczne wnioski	Różne bazy danych, reguły i tempo aktualizacji	Porównuj surowe pola, nie tylko sumę punktów; decydujący jest test w docelowej działalności
Po restarcie środowiska zmieniają się kluczowe pola	Losowa konfiguracja nie została utrwalona lub środowisko zostało odtworzone	Sprawdź politykę zapisu, synchronizacji i losowych odcisków palców, ustal stałe parametry środowiska

Zlokalizuj problem warstwa po warstwie w PurpleMark

Jeśli wcześniejsze wnioski wyglądają na poprawne, a niektóre platformy nadal zgłaszają nieprawidłowości, możesz przenieść czynności kontrolne na konkretne środowisko w PurpleMark.

Pierwszy krok to potwierdzenie wyjścia. W menedżerze proxy w PurpleMark sprawdź proxy przypisane do bieżącego środowiska, potwierdź jego wyjściowy adres IP, region i strefę czasową, porównaj z publicznym adresem IP pokazywanym przez witrynę kontrolną, a następnie sprawdź, czy w WebRTC nie pojawia się inny publiczny adres niezwiązany z wyjściem.

Drugi krok to potraktowanie parametrów jako zestawu, a nie ręczna zmiana każdego z osobna. Podczas tworzenia środowiska w PurpleMark możesz ustawić za jednym razem system operacyjny, silnik Chromium, User-Agent, język, strefę czasową i geolokalizację oraz skonfigurować parametry odcisków palców, takie jak WebGL, WebRTC, CPU, pamięć czy Canvas. Dzięki temu, że silnik, UA, system operacyjny i czcionki korzystają z tego samego presetu, unikniesz sprzecznych zestawień w rodzaju „windowsowych czcionek z oznaczeniem macOS”. Przed zapisaniem zajrzyj do podglądu środowiska, potwierdź, że kombinacja pól jest spójna, i dopiero potem zapisz ją do użytku.

Trzeci krok to bezpieczne eksperymenty. Utwórz kopię problematycznego środowiska jako egzemplarz testowy i nie zmieniaj wielokrotnie środowiska działającego. Modyfikuj za każdym razem tylko jedną zmienną — na przykład najpierw proxy lub trasę WebRTC, potem politykę szumu Canvas — po każdej zmianie zapisuj wynik kontroli, dwukrotnie uruchom środowisko ponownie, aby potwierdzić stabilność, a następnie przejdź przez prawdziwy proces biznesowy na docelowej witrynie. Jeśli podejrzewasz zakłócenia ze strony rozszerzeń, włączaj je w kopii pojedynczo.

Te działania pomogą Ci zweryfikować wyjście, zestawienie parametrów i stabilność w obrębie jednej konfiguracji, dzięki czemu łatwiej będzie ustalić, „z której warstwy pochodzi wynik kontroli”. Należy przy tym pamiętać, że PurpleMark odpowiada za zachowanie spójności parametrów i odtwarzalność środowiska; ostateczny werdykt kontroli zależy wciąż od jakości proxy, wersji przeglądarki, rozszerzeń, tras sieciowych oraz logiki oceny samej witryny docelowej.

Nie twórz nowych nieprawidłowości w pogoni za maksymalną punktacją

Punktacja witryn kontrolnych nadaje się do wykrywania tropów, ale nie powinna być jedynym celem. Częste zmienianie UA, GPU, Canvas, czcionek i strefy czasowej może uczynić środowisko mniej stabilnym niż wcześniej; skopiowanie cudzych „parametrów na maksymalną punktację” nie skopiuje też cudzej sieci, sprzętu ani historii użytkowania.

Właściwe podejście zaczyna się od surowych pól: najpierw usuń oczywiste sprzeczności, potem zweryfikuj długoterminową stabilność i funkcje biznesowe. Środowisko o nie najwyższej punktacji, ale spójnym zestawieniu i trwałej stabilności jest zwykle łatwiejsze w zarządzaniu niż „środowisko na maksymalną punktację”, które zmienia się przy każdym sprawdzeniu.