Ochrona przed fingerprintingiem w Safari 26: które interfejsy są ograniczane dla znanych skryptów

Safari 26 ogranicza znane skrypty fingerprintingowe, czyli kod służący do rozpoznawania przeglądarki na podstawie zestawu cech urządzenia. WebKit opisuje ograniczenia interfejsów urządzenia, trwałego zapisu przez skrypty i dostępu do informacji o nawigacji. Apple wskazuje również rozszerzenie ochrony przed fingerprintingiem na zwykłe przeglądanie w iOS 26.

Wpływ na konkretną integrację zależy od skryptu, kontekstu wykonania, wersji Safari i ustawień prywatności. Etykieta „narzędzie analityczne” nie gwarantuje wyjątku. Sama aktualizacja przeglądarki nie dowodzi też przyczyny zmiany raportowanego ruchu.

Trzy ograniczenia o różnych skutkach

WebKit wymienia najpierw interfejsy ujawniające cechy urządzenia: wymiary ekranu, równoległość procesora, dostępne głosy syntezy mowy, możliwości Apple Pay, odczyt danych audio i canvas 2D. Znane skrypty fingerprintingowe tracą wiarygodny dostęp do tych cech. Nie oznacza to, że każdy ograniczony interfejs zawsze zwraca pustą wartość albo że przestaje działać zwykłe odtwarzanie dźwięku i rysowanie na canvas.

Drugie ograniczenie uniemożliwia takim skryptom długotrwały zapis, między innymi w ciasteczkach i localStorage. Trzecie dotyczy dostępu do informacji o nawigacji, takich jak parametry zapytania i document.referrer. To oddzielne skutki: skrypt może zostać poprawnie załadowany, a mimo to otrzymać mniej danych.

Przypisywanie wizyt na podstawie brakujących danych może stać się mniej dokładne. Nie oznacza to utraty każdej możliwości określenia źródła: informacje o kampanii mogą nadal pochodzić z dozwolonego żądania lub innego niezależnie uzasadnionego źródła. Ochrona przeglądarki i wymagania dotyczące zgody pozostają odrębnymi zagadnieniami.

Usunięcie z URL a dostęp skryptu

Opis ochrony wprowadzonej w Safari 17 rozróżnia dwa działania. Link Tracking Protection usuwa wybrane parametry śledzące przed nawigacją, więc te wartości nie trafiają do serwera docelowego. Oddzielnie chroniony dostęp skryptów po przejściu między witrynami może ukrywać parametry zapytania i fragment, mimo że żądanie docelowe nadal zawiera zapytanie.

WebKit odróżnia parametry kampanii od identyfikatorów konkretnych osób lub kliknięć. Nie daje to gwarancji odczytu wszystkich parametrów utm_ przez każdy skrypt. Parametr może pozostać w żądaniu, a jednocześnie być niedostępny dla określonego skryptu. Znaczenie mają nawigacja i kontekst wykonania.

Porównanie wymaga kontrolowanych warunków

Opis wydania Safari 26 nie zawiera pełnej klasyfikacji dostawców ani interfejsu do sprawdzania przypisania. Lista blokowanych żądań sieciowych nie musi odpowiadać klasyfikacji używanej do ograniczania poszczególnych skryptów.

Wyrażenie wykonane w konsoli nie gwarantuje odczytu fizycznego parametru urządzenia ani tego samego kontekstu co osadzony skrypt. Równe wyniki nie dowodzą braku ochrony, a różne wyniki nie dowodzą klasyfikacji. Wpływ mogą mieć również rozmiar okna, ramka, moment odczytu, rozszerzenia, przetwarzanie przez aplikację i inne zabezpieczenia.

1. Zapisane warunki: dokładna wersja Safari i systemu, tryb zwykły lub prywatny, istotne ustawienia, rozszerzenia, stan zgody i droga nawigacji.
2. Kontrolowane wejście: testowy adres docelowy z nieosobowymi wartościami kampanii; osobne sprawdzenie wejścia bezpośredniego i odnośnika z innej witryny.
3. Oddzielne obserwacje: żądanie docelowe, wartość odczytana w rzeczywistym miejscu odczytu integracji oraz wynikowe żądanie wychodzące. Pomocne mogą być punkty przerwania w Web Inspector lub diagnostyka dostawcy.
4. Powtarzane porównanie: ten sam przebieg ze zmianą jednego warunku naraz, ewentualnie z dozwolonym tymczasowym ograniczeniem ochrony w środowisku testowym. Zmieniony wynik opisuje daną konfigurację, a nie uniwersalną klasyfikację dostawcy.

Skopiowany fragment diagnostyczny może działać w innych warunkach niż pierwotna integracja. Osobny wynik z konsoli nie zastępuje więc obserwacji rzeczywistego skryptu. Samo wysłanie żądania nie dowodzi również poprawnego przypisania w raporcie odbiorcy.

Starsze zabezpieczenia mają własny zakres

Safari wprowadziło pełną blokadę ciasteczek stron trzecich w 2020 roku; mechanizmy takie jak Storage Access API mogą zapewnić dostęp w określonych warunkach. Pamięć zapisywalna przez skrypty podlega usuwaniu po siedmiu dniach używania Safari bez interakcji z witryną, a nie po prostu po siedmiu dniach kalendarzowych. WebKit dokumentuje wyjątek od tej reguły ITP dla aplikacji webowych z ekranu początkowego.

Ciasteczka ustawiane przez serwer podlegają innym regułom. WebKit ogranicza ciasteczka w odpowiedziach rozpoznanych jako maskowanie strony trzeciej przez CNAME lub adres IP. Nie każdy CNAME spełnia te warunki: znaczenie ma relacja do własnej domeny i CNAME hosta strony najwyższego poziomu. Wykrywanie na podstawie IP korzysta z poszlak wskazujących na możliwe maskowanie; nie ustala bezpośrednio operatora usługi. Hosting w chmurze lub sam inny adres IP nie wystarczają do postawienia diagnozy.

Te mechanizmy nie dotyczą wszystkich skryptów identycznie i nie dowodzą końca wszelkiego długotrwałego rozpoznawania. Selektywne zabezpieczenia istniały już przed Safari 26, między innymi blokowanie żądań do znanych trackerów w trybie prywatnym.