Fingerprinting-Schutz in Safari 26: Welche Schnittstellen für bekannte Skripte eingeschränkt werden

Safari 26 bringt einen erweiterten Schutz gegen Fingerprinting mit, der ohne Zutun aktiv ist. Die Beschreibung bei WebKit ist ungewöhnlich genau darin, was er tut – und noch genauer in einem Wort, das in jedem Satz darüber vorkommt: Er richtet sich gegen bekannte Fingerprinting-Skripte.

Dieses Wort trägt die ganze Maßnahme. Es entscheidet darüber, ob dieselbe Schnittstelle einen echten oder einen unbrauchbaren Wert zurückgibt, und es macht diesen Schutz zum ersten in Safaris Geschichte, der zwei Skripte auf derselben Seite unterschiedlich behandelt.

Was der Schutz einem erkannten Skript entzieht

WebKit nennt drei Gruppen. Die erste sind Schnittstellen, aus denen sich Geräteeigenschaften ablesen lassen: Bildschirmmaße, die Zahl der Rechenkerne, die Liste der über die SpeechSynthesis verfügbaren Stimmen, Zahlungsfähigkeiten, die Rückgabe aus Web Audio und das 2D-Canvas. Ein erkanntes Skript bekommt hier keine verlässlichen Werte mehr.

Die zweite ist die Speicherung. Ein solches Skript kann keine langlebige skriptgeschriebene Ablage mehr anlegen, weder als Cookie noch im localStorage. Die dritte ist die Herkunft: Abfrageparameter und document.referrer lassen sich nicht mehr auslesen, weil sich über beide eine Wiedererkennung beim Seitenwechsel bauen lässt.

Die dritte Gruppe ist für die Messung die interessanteste, denn sie betrifft nicht die Wiedererkennung eines Geräts, sondern die Zuordnung eines Besuchs. Wer die Herkunft nicht lesen kann, kann keine Quelle bestimmen – unabhängig davon, ob er je vorhatte, jemanden wiederzuerkennen.

Das Wort, an dem alles hängt

Wie ein Skript auf die Liste gerät, beschreibt WebKit nicht öffentlich, und eine einsehbare Liste gibt es nicht. Das ist aus Sicht des Schutzes folgerichtig, denn eine veröffentlichte Liste wäre eine Anleitung zum Ausweichen. Für die Betreiberseite bedeutet es allerdings, dass sich die Frage, ob ein bestimmtes Werkzeug betroffen ist, nicht nachschlagen lässt.

Beantworten lässt sie sich nur durch Messen. Ein kurzer Vergleich in Safari zeigt, ob die Rückgaben auseinandergehen: die Werte aus der Konsole gegen die, die das Skript selbst ausliest oder versendet. Sinnvoll ist das für jedes eingebundene Skript, das Geräteeigenschaften abfragt – und das sind mehr, als die meisten Übersichten ausweisen, weil Betrugserkennung, Bot-Abwehr und Personalisierung dieselben Schnittstellen benutzen wie Fingerprinting.

Gegenprobe im Entwicklerfenster von Safari

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

  Die Konsole zeigt die echten Werte, denn dort eingegebener
  Code stammt aus keinem Skript auf der Liste. Weicht davon ab,
  was das eingebundene Skript ausliest oder im Netzwerkbereich
  des Web Inspectors versendet, steht es vermutlich auf der
  Liste. Gleiche Werte heißen das Gegenteil.

Warum trotzdem kaum etwas kaputtgegangen ist

Nach der Veröffentlichung blieb die erwartete Welle an Ausfällen aus, und das hat einen einfachen Grund: Gewöhnliche Analyse- und Werbeskripte stehen nicht auf der Liste. Sie messen Seitenaufrufe, Ereignisse und Kampagnen, und dafür brauchen sie keine merkmalsreichen Schnittstellen. Auch die Kampagnenparameter in der utm-Form sind nicht betroffen, weder von diesem Schutz noch von der älteren Entfernung bekannter Klickkennungen.

Wer nach der Aktualisierung einen Einbruch in den Zahlen sah, hatte deshalb mit hoher Wahrscheinlichkeit ein anderes Problem. Das lohnt sich festzuhalten, weil eine neue Browserfunktion in solchen Wochen zur bequemen Erklärung wird und die tatsächliche Ursache dann ungeprüft stehen bleibt.

Was die älteren Schichten längst genommen hatten

Der Grund, warum dieser Schutz so wenig Wirkung auf gewöhnliche Messung hat, liegt darin, dass die Verluste vorher eingetreten sind. Drittanbieter-Cookies sind in Safari seit 2020 standardmäßig blockiert. Aus JavaScript gesetzte Cookies und andere skriptgeschriebene Ablagen verschwinden nach sieben Tagen Nutzung ohne Interaktion auf der betreffenden Seite. Bekannte Klickkennungen werden im erweiterten Schutz seit Safari 17 aus der Adresse gestrichen.

Diese drei Schichten treffen jedes Skript ausnahmslos, und sie haben die Wiedererkennung über längere Zeiträume in Safari bereits beendet. Der neue Schutz ergänzt eine vierte Schicht, die sich an eine benannte Gruppe richtet – er ist deshalb die auffälligste Ankündigung der Reihe und die mit der geringsten Breitenwirkung.

Was daraus folgt

Für die meisten Auftritte lautet die richtige Antwort auf Safari 26: nichts tun, aber wissen, warum. Die Werkzeuge, die messen, sind nicht betroffen; die Werkzeuge, die erkennen wollen, sind es womöglich, und ob sie es sind, steht in keiner Liste, sondern nur in einem Vergleich.

Zwei Dinge lohnen sich dennoch. Das erste ist die Bestandsaufnahme, welche eingebundenen Skripte Geräteeigenschaften abfragen – eine Frage, die unabhängig von Safari 26 zu beantworten ist, weil sie auch für die Einwilligungsdokumentation gilt. Das zweite ist die Erkenntnis aus der dritten Gruppe: Wo die Herkunft eines Besuchs zur Ware wird, hängt die Zuordnung an einer Angabe, die ein Browser inzwischen unterschlagen darf. Wer das für ein Randproblem hält, sollte nachzählen, wie viele Zuordnungsentscheidungen im eigenen Aufbau allein auf document.referrer beruhen.