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

Safari 26 przynosi rozszerzoną ochronę przed odciskiem palca, która działa bez niczyjego włączania. Opis w WebKicie jest niezwykle dokładny w tym, co ona robi – a jeszcze dokładniejszy w jednym słowie powracającym w każdym zdaniu na jej temat: wymierzona jest w znane skrypty do odcisku palca.

To słowo dźwiga cały mechanizm. Rozstrzyga, czy ten sam interfejs zwróci wartość prawdziwą, czy bezużyteczną, i czyni tę ochronę pierwszą w dziejach Safari, która traktuje dwa skrypty na tej samej stronie odmiennie.

Co ochrona odbiera rozpoznanemu skryptowi

WebKit wymienia trzy grupy. Pierwsza to interfejsy, z których dają się odczytać właściwości urządzenia: wymiary ekranu, liczba rdzeni obliczeniowych, lista głosów dostępnych przez SpeechSynthesis, możliwości płatnicze, odczyt z Web Audio oraz canvas 2D. Rozpoznany skrypt nie otrzymuje już stąd wiarygodnych wartości.

Druga to zapis. Taki skrypt nie może już założyć długowiecznego zapisu skryptowego, ani jako ciasteczko, ani w localStorage. Trzecia to pochodzenie: parametrów zapytania i document.referrer nie da się już odczytać, bo na obu daje się zbudować rozpoznawanie przy przejściu między stronami.

Dla pomiaru najciekawsza jest grupa trzecia, bo dotyczy nie rozpoznania urządzenia, lecz przypisania wizyty. Skrypt, który nie potrafi odczytać pochodzenia, nie potrafi ustalić źródła – niezależnie od tego, czy kiedykolwiek zamierzał kogokolwiek rozpoznać.

Słowo, na którym wszystko wisi

Tego, jak skrypt trafia na listę, WebKit publicznie nie opisuje, a listy do wglądu nie ma. Z punktu widzenia ochrony jest to konsekwentne, bo lista opublikowana byłaby instrukcją omijania. Dla strony prowadzącej witrynę oznacza to jednak, że pytania, czy dane narzędzie jest objęte, nie da się sprawdzić w wykazie.

Odpowiedź daje wyłącznie pomiar. Krótkie zestawienie w Safari pokazuje, czy zwroty się rozchodzą: wartości z konsoli wobec tych, które skrypt sam odczytuje lub wysyła. Warto to zrobić dla każdego osadzonego skryptu odpytującego właściwości urządzenia – a jest ich więcej, niż notują zwykłe zestawienia, bo wykrywanie oszustw, obrona przed botami i personalizacja używają tych samych interfejsów co odcisk palca.

Sprawdzenie w konsoli Safari

  screen.width + "x" + screen.height
  navigator.hardwareConcurrency
  speechSynthesis.getVoices().length
  document.referrer
  new URLSearchParams(location.search).get("gclid")

  Konsola pokazuje prawdziwe wartości, bo wpisany tam kod
  nie pochodzi z żadnego skryptu z listy. Jeżeli to, co osadzony
  skrypt odczytuje lub - według panelu sieci Web Inspectora - wysyła,
  różni się od nich, skrypt stoi prawdopodobnie na liście.
  Wartości równe znaczą odwrotnie.

Dlaczego mimo to prawie nic się nie zepsuło

Po wydaniu spodziewana fala awarii nie nadeszła, a powód jest prosty: zwyczajne skrypty analityczne i reklamowe nie stoją na liście. Mierzą odsłony, zdarzenia i kampanie, a do tego interfejsy bogate w cechy nie są potrzebne. Parametry kampanii w postaci utm również nie są objęte, ani tą ochroną, ani starszym usuwaniem znanych identyfikatorów kliknięć.

Kto zobaczył po aktualizacji załamanie w liczbach, miał zatem z dużym prawdopodobieństwem inny kłopot. Warto to odnotować, bo w takich tygodniach nowa funkcja przeglądarki staje się wygodnym wyjaśnieniem, a rzeczywista przyczyna zostaje wtedy niezbadana.

Co warstwy starsze zabrały już dawno

Powód, dla którego ta ochrona ma tak mały wpływ na zwyczajny pomiar, leży w tym, że straty nastąpiły wcześniej. Ciasteczka obce są w Safari domyślnie blokowane od 2020. Ciasteczka ustawiane z JavaScriptu i inne zapisy skryptowe znikają po siedmiu dniach używania bez interakcji na danej stronie. Znane identyfikatory kliknięć są w ochronie rozszerzonej wycinane z adresu od Safari 17.

Te trzy warstwy trafiają każdy skrypt bez wyjątku i już zakończyły w Safari rozpoznawanie w dłuższym czasie. Nowa ochrona dokłada czwartą warstwę skierowaną do nazwanej grupy – jest więc najgłośniejszą zapowiedzią z całego szeregu i tą o najmniejszym zasięgu.

Co z tego wynika

Dla większości witryn właściwą odpowiedzią na Safari 26 jest: nie robić nic, ale wiedzieć dlaczego. Narzędzia, które mierzą, nie są objęte; narzędzia, które chcą rozpoznawać, być może są, a to, czy są, nie stoi w żadnym wykazie, lecz wyłącznie w zestawieniu.

Dwie rzeczy i tak się opłacają. Pierwsza to spis, które osadzone skrypty odpytują właściwości urządzenia – pytanie warte odpowiedzi niezależnie od Safari 26, bo dotyczy także dokumentacji zgód. Druga to wniosek z trzeciej grupy: tam, gdzie pochodzenie wizyty staje się towarem, przypisanie opiera się na wartości, którą przeglądarka może już zataić. Kto uważa to za problem poboczny, niech policzy, ile decyzji przypisania we własnej konfiguracji opiera się wyłącznie na document.referrer.