Jak działa śledzenie cyfrowego śladu od podszewki

Każde urządzenie łączące się z internetem pozostawia po sobie ślad technicznych artefaktów — cyfrowy ślad. W tracio.ai rekonstruujemy ten ślad z ponad 300 pasywnych sygnałów zebranych podczas jednego wczytania strony, bez uzależniania identyfikacji od plików cookie ani od jakiejkolwiek innej trwałej pamięci po stronie klienta. Ten artykuł wyjaśnia dokładnie, jak przebiega ten proces.

Warstwa zbierania sygnałów

Gdy nasz agent JavaScript wczytuje się w przeglądarce odwiedzającego, zaczyna zbierać sygnały z wielu kategorii jednocześnie. Renderowanie canvas, odpytywanie parametrów WebGL, przetwarzanie AudioContext, wyliczanie czcionek i odczyty właściwości navigatora działają równolegle, a każda sonda ma własny limit czasu, więc wolna nie zatrzymuje pozostałych. To, jak długo trwa cały przebieg, zależy od urządzenia odwiedzającego, a liczby poniżej to wyniki, które mierzymy na naszym.

Kluczowa obserwacja jest taka, że każdy sygnał uchwytuje inny aspekt sprzętowego i programowego stosu urządzenia. Renderowanie canvas odzwierciedla GPU, sterownik i silnik renderowania czcionek. Parametry WebGL ujawniają model i możliwości karty graficznej. AudioContext ujawnia różnice w tym, jak audio DSP przetwarza operacje zmiennoprzecinkowe. Właściwości navigatora raportują liczbę rdzeni CPU, pamięć, platformę i ustawienia języka.

Nasz zespół zmierzył to na 2 miliardach zdarzeń w zeszłym miesiącu: mediana czasu zbierania wyniosła 38 ms, a 99. percentyl — 52 ms. Na początku wypróbowaliśmy naiwne podejście — zbieranie sygnałów sekwencyjnie. Było 40 razy wolniejsze. Zbieranie równoległe z barierą czasową było jedną z pierwszych decyzji architektonicznych, które podjęliśmy właściwie.

Odcisk TLS: pierwsza warstwa

Zanim nasz JavaScript w ogóle się wykona, przeglądarka już ujawniła istotne informacje poprzez uzgadnianie TLS. Wiadomość Client Hello zawiera zestawy szyfrów obsługiwane przez przeglądarkę, używane przez nią rozszerzenia TLS, preferowane krzywe eliptyczne oraz akceptowane algorytmy podpisu. Informacje te są determinowane przez bibliotekę TLS przeglądarki i znacząco różnią się między rodzinami przeglądarek, wersjami i systemami operacyjnymi.

Przechwytujemy ten odcisk TLS za pomocą haszowania JA4 — nowoczesnego następcy JA3, który zapewnia lepszą granularność i stabilność między wersjami. Sam hash JA4 potrafi odróżnić Chrome od Firefoxa i od Safari, a często zawęża identyfikację do konkretnego zakresu wersji przeglądarki. W połączeniu z naszymi sygnałami po stronie klienta stanowi warstwę walidacji krzyżowej, którą niezwykle trudno podrobić.

Odcisk canvas i GPU

Odcisk canvas wykorzystuje fakt, że różne GPU renderują te same instrukcje rysowania z subtelnymi różnicami na poziomie pikseli. Canvas API pozwala nam narysować starannie zaprojektowaną scenę — konkretne łańcuchy tekstu w wielu czcionkach, kształty geometryczne o określonych współrzędnych oraz gradienty z precyzyjnymi punktami koloru — a następnie obliczyć hash powstałych danych pikselowych.

Różnice w renderowaniu wynikają z odmienności algorytmów antyaliasingu, renderowania subpikselowego, mieszania kolorów oraz hintingu czcionek między modelami GPU i wersjami sterowników. Nawet dwa urządzenia z tym samym modelem GPU mogą wygenerować różne wyniki canvas, jeśli działają na innych wersjach sterownika lub systemu operacyjnego. To sprawia, że hash canvas jest jednym z naszych najbardziej charakterystycznych sygnałów.

Profilowanie sprzętu przez WebGL

WebGL API ujawnia szczegółowe informacje o podsystemie graficznym, które wykraczają daleko poza łańcuchy renderera i producenta. Odpytujemy maksymalne rozmiary tekstur, formaty precyzji shaderów, obsługiwane rozszerzenia, wymiary viewportu oraz dziesiątki innych parametrów, które różnią się między modelami GPU i konfiguracjami sterowników.

Kombinacja tych parametrów tworzy szczegółowy profil sprzętowy. Urządzenie z NVIDIA RTX 4070 zaraportuje na przykład inne maksymalne rozmiary tekstur, inną precyzję shaderów i inną obsługę rozszerzeń niż urządzenie z AMD RX 7800 XT. Ten profil sprzętowy jest z natury stabilny — nie zmienia się wraz z aktualizacjami przeglądarki, a jedynie przy zmianach sprzętu lub sterowników.

Odcisk przetwarzania audio

Web Audio API dostarcza kolejnego źródła sygnałów zależnych od sprzętu. Tworzymy węzeł oscylatora, łączymy go z kompresorem dynamiki i mierzymy bufor wyjściowy. Różnice w precyzji zmiennoprzecinkowej, implementacji DSP oraz algorytmach próbkowania między sprzętem audio a systemami operacyjnymi dają mierzalne wariacje na wyjściu.

Odciski audio mają umiarkowaną unikalność, ale wyjątkową stabilność. Potok przetwarzania audio rzadko się zmienia, chyba że użytkownik zmieni sprzęt audio lub ponownie zainstaluje system operacyjny. To czyni sygnały audio wartościowymi kotwicami w naszym wielopoziomowym systemie identyfikacji.

Fuzja sygnałów i rozwiązywanie tożsamości

Surowe sygnały są szyfrowane i przesyłane na nasz serwer, gdzie silnik identyfikacji urządzeń przetwarza je poprzez trójpoziomowy system haszowania. Sygnały na poziomie sprzętu (canvas, WebGL, audio) tworzą Poziom 1 — stabilny rdzeń tożsamości. Sygnały na poziomie przeglądarki (wykrywanie funkcji, właściwości CSS, możliwości mediów) tworzą Poziom 2, przetwarzany poprzez dopasowywanie międzysesyjne, aby obsłużyć oczekiwany dryf wynikający z aktualizacji przeglądarki. Sygnały zmienne (user agent, strefa czasowa, język) tworzą Poziom 3, przyczyniając się do oceny pewności bez sterowania decyzjami o tożsamości.

Algorytm fuzji waży każdy sygnał według jego unikalności i stabilności. Dopasowanie rzadkiego hasha canvas ma znacznie większą wagę niż dopasowanie powszechnej rozdzielczości ekranu. To podejście ważone zapewnia, że identyfikacja pozostaje dokładna nawet wtedy, gdy część sygnałów się zmienia.

Co zapisujemy i dlaczego identyfikacja od tego nie zależy

Krytyczną zasadą projektową naszego systemu jest to, że identyfikacja nie zależy od pamięci po stronie klienta. Identyfikator odwiedzającego jest wyprowadzany z wrodzonych cech urządzenia — sprzętu, stosu programowego, konfiguracji sieci — i właśnie dlatego identyfikacja przetrwa czyszczenie cookies, tryb incognito, a nawet ponowną instalację przeglądarki.

To twierdzenie o zależności, nie o abstynencji, i tę różnicę warto powiedzieć wprost. Ustawiamy jeden własny plik cookie, _vid_t, zawierający nieprzejrzysty identyfikator z ważnością 365 dni, a tę samą wartość odwzorowujemy w localStorage. Czego nie robimy: nie ustawiamy plików cookie stron trzecich, nie zapisujemy niczego, co działa między witrynami, i nie czytamy historii przeglądania, danych z formularzy ani IndexedDB. Ten plik cookie istnieje, bo jest najtańszą możliwą odpowiedzią na pytanie „czy widzieliśmy już tę przeglądarkę?” — gdy przetrwa, dopasowanie jest natychmiastowe i pewne. Gdy nie przetrwa, nic się nie psuje: sygnały urządzenia same odtwarzają identyfikator, z nieco niższą pewnością. Odwiedzający, który wyczyści wszystko, wciąż zostaje rozpoznany; system oparty wyłącznie na pamięci by go stracił.

Prywatność wynikająca z architektury

Ponieważ zbieramy wyłącznie techniczne atrybuty przeglądarki — bez historii przeglądania, bez danych z formularzy, bez treści osobistych — wpływ na prywatność jest minimalny. Wytyczne W3C dotyczące fingerprintingu określają najlepsze praktyki odpowiedzialnego wykorzystania sygnałów przeglądarki, a nasza architektura jest zgodna z tymi zasadami. Przetwarzanie odbywa się w naszej zarządzanej chmurze, z lokalizacją danych w UE lub w USA — zależnie od wybranego przez Ciebie regionu. Taka architektura sprawia, że zgodność z RODO, CCPA i innymi regulacjami dotyczącymi prywatności staje się prosta.