English
Deutsch
PolskiFingerprinting-Schutz in Safari 26: Welche Schnittstellen für bekannte Skripte eingeschränkt werden
Management Summary
Fingerprinting erkennt Browser anhand kombinierter Gerätemerkmale statt allein über gespeicherte Cookies. Safari 26 begrenzt Informationen für bekannte Programme, die diese Technik einsetzen. Das kann neben Tracking auch Website-Analysen und Betrugsprüfungen beeinflussen. Der Beitrag erklärt, warum die Wirkung vom jeweiligen Dienst und den Nutzungsbedingungen abhängt. Veränderte Berichte nach einem Browserupdate belegen deshalb noch keine einzelne Ursache; ein Server stellt zuvor entfernte Angaben nicht wieder her.
Inhalt
Safari 26 beschränkt bekannte Fingerprinting-Skripte: Code, der Browser anhand einer Kombination von Gerätemerkmalen wiedererkennen soll. WebKit beschreibt Einschränkungen bei Geräte-APIs, langlebiger skriptgeschriebener Speicherung und Navigationsinformationen. Apple nennt für iOS 26 außerdem einen erweiterten Fingerprinting-Schutz beim gewöhnlichen Surfen.
Die Wirkung auf eine konkrete Integration hängt von Skript, Ausführungskontext, Safari-Version und Datenschutzeinstellungen ab. Die Bezeichnung „Analysewerkzeug“ garantiert keine Ausnahme. Eine Browseraktualisierung allein belegt auch nicht die Ursache veränderter Zugriffszahlen.
Drei Einschränkungen mit unterschiedlichen Folgen
WebKit nennt zunächst Schnittstellen für Gerätemerkmale: Bildschirmmaße, Prozessorparallelität, verfügbare Sprachsynthese-Stimmen, Apple-Pay-Fähigkeiten, Auslesen berechneter Audiodaten und 2D-Canvas. Bekannte Fingerprinting-Skripte erhalten keinen verlässlichen Zugriff auf diese Merkmale. Daraus folgt weder ein stets leerer Rückgabewert jeder betroffenen API noch ein Ausfall gewöhnlicher Audiowiedergabe oder Canvas-Darstellung.
Zweitens verhindert der Schutz langlebige skriptgeschriebene Speicherung durch solche Skripte, etwa Cookies und localStorage. Drittens wird der Zugriff auf Navigationsinformationen wie Abfrageparameter und document.referrer beschränkt. Das sind getrennte Wirkungen: Ein Skript kann erfolgreich laden und trotzdem weniger Informationen erhalten.
Eine darauf gestützte Zuordnung von Besuchen kann ungenauer werden. Damit wird nicht jede Quellenzuordnung unmöglich: Kampagneninformationen aus einer zulässigen Anfrage oder einer anderen unabhängig begründeten Quelle können weiterhin vorliegen. Browserschutz und Einwilligungsanforderungen bleiben getrennte Fragen.
Entfernen aus der URL und Auslesen durch Skripte
WebKits Beschreibung des mit Safari 17 eingeführten Schutzes unterscheidet zwei Vorgänge. Link Tracking Protection entfernt ausgewählte Trackingparameter vor der Navigation; diese Werte erreichen den Zielserver nicht. Zusätzlich kann geschützter Skriptzugriff nach einem websiteübergreifenden Wechsel Abfrageparameter und Fragmente verbergen, obwohl die Zielanfrage die Abfrage noch enthält.
WebKit unterscheidet kampagnenbezogene Parameter von Kennungen einzelner Personen oder Klicks. Daraus entsteht keine Garantie, dass jedes Skript sämtliche utm_-Parameter lesen kann. Ein Parameter kann in der Anfrage erhalten bleiben und einem bestimmten Skript trotzdem fehlen. Navigation und Ausführungskontext sind entscheidend.
Eine Gegenprobe braucht kontrollierte Bedingungen
Die Safari-26-Veröffentlichung enthält keine vollständige Anbieterklassifikation und keine API zur Abfrage einer Einstufung. Eine Liste blockierter Netzwerkanfragen entspricht nicht automatisch der Klassifikation hinter Beschränkungen einzelner Skripte.
Ein Konsolenausdruck liefert weder garantiert den physischen Gerätewert noch denselben Ausführungskontext wie ein eingebundenes Skript. Gleiche Ergebnisse beweisen keinen fehlenden Schutz; unterschiedliche Ergebnisse beweisen keine Einstufung. Auch Fenstergröße, Frame-Kontext, Zeitpunkt, Erweiterungen, Anwendungsverarbeitung und andere Schutzmaßnahmen können Werte verändern.
- Dokumentierte Bedingungen: genaue Safari- und Betriebssystemversion, gewöhnliches oder privates Surfen, relevante Einstellungen, Erweiterungen, Einwilligungszustand und Navigationsweg.
- Kontrollierte Eingabe: eine Test-Zieladresse mit nicht personenbezogenen Kampagnenwerten; Direktaufruf und websiteübergreifenden Link getrennt untersuchen.
- Getrennte Beobachtungen: Zielanfrage, tatsächlich an der Lesestelle der Integration erfasster Wert und daraus erzeugte ausgehende Anfrage. Haltepunkte im Web Inspector oder Diagnosewerkzeuge des Anbieters helfen beim Auffinden der Lesestelle.
- Wiederholter Vergleich: derselbe Ablauf mit jeweils einer veränderten Bedingung, gegebenenfalls einer zulässigen vorübergehenden Schutzreduzierung in einer Testumgebung. Eine Änderung belegt Verhalten dieser Konfiguration, keine universelle Anbieterklassifikation.
Ein kopierter Diagnoseausschnitt kann unter anderen Bedingungen laufen als die ursprüngliche Integration. Ein isolierter Konsolenwert ersetzt deshalb keine Beobachtung des tatsächlichen Skripts. Eine versendete Anfrage beweist außerdem keine korrekte Zuordnung im empfangenden Bericht.
Ältere Schutzmaßnahmen haben eigene Grenzen
Safari führte 2020 die vollständige Drittanbieter-Cookie-Blockade ein; Mechanismen wie die Storage Access API können unter definierten Bedingungen Zugriff ermöglichen. Skriptbeschreibbarer Speicher wird nach sieben Tagen Safari-Nutzung ohne Interaktion mit der Website gelöscht, nicht einfach nach sieben Kalendertagen. Für Home-Screen-Web-Apps dokumentiert WebKit eine Ausnahme von dieser ITP-Regel.
Für servergesetzte Cookies gelten andere Regeln. WebKit begrenzt Cookies in Antworten, die als Drittanbieter-CNAME- oder IP-Verschleierung erkannt werden. Nicht jeder CNAME fällt darunter: Die Beziehung zur eigenen Domain und zum CNAME des obersten Seitenhosts zählt. Die IP-Erkennung schließt aus Indizien auf mögliche Verschleierung; der Betreiber eines Dienstes wird damit nicht unmittelbar festgestellt. Cloud-Hosting oder eine abweichende IP allein ergeben deshalb noch keine belastbare Diagnose.
Diese Mechanismen treffen nicht jedes Skript identisch und belegen kein Ende sämtlicher langfristiger Wiedererkennung. Selektive Schutzmaßnahmen gab es bereits vor Safari 26, darunter das Blockieren von Netzwerkanfragen an bekannte Tracker im privaten Modus.
Fragen und Antworten
Bleiben gewöhnliche Analyse- und Werbewerkzeuge unberührt?
Aus der veröffentlichten Beschreibung folgt keine allgemeine Ausnahme. Verhalten und Einstufung des Skripts zählen mehr als die Produktkategorie. Bei sinkenden Messwerten gehören Anfragen, Einwilligung, Veröffentlichungen und Berichte ebenso zur Prüfung wie Browsereffekte. Ein fehlender dokumentierter Ausfall beweist keinen unveränderten Betrieb jeder Integration.
Können Betrugserkennung und Bot-Abwehr betroffen sein?
Ja, sofern ein System auf beschränkte Geräteinformationen angewiesen ist. Zusätzliche Prüfungen oder gescheiterte Vorgänge sind mögliche, keine zwangsläufigen Folgen. Ein Browservergleich braucht vergleichbare Zugriffe und Abläufe. Ein Anstieg nur in Safari liefert einen Hinweis, aber keinen Ursachenbeweis.
Bleibt die Herkunft bei serverseitiger Auswertung erhalten?
Der Server erhält die tatsächlich eintreffende Abfrage nach möglichen Parameterentfernungen und Weiterleitungen. Ein Fragment ist der URL-Teil nach # und gehört nicht zur HTTP-Anfrage. Der Header Referer kann nur den Ursprung enthalten (Schema, Hostname und gegebenenfalls einen abweichenden Port, ohne Pfad und Abfrage) oder fehlen, etwa durch Referrer-Policy oder einen Direktaufruf. Serverseitige Verarbeitung stellt entfernte Werte daher nicht wieder her und garantiert keine vollständige Herkunftsgeschichte.
Was folgt für den Betrieb?
Eine Liste der Daten, die jede Funktion benötigt, und kontrollierte Tests wichtiger Abläufe liefern eine bessere Grundlage als pauschales Nichtstun. Fehlende Herkunftsinformation sollte als fehlend erkennbar bleiben; ein leerer Referrer allein beweist keinen Direktzugriff. Produktive Schutzeinstellungen sollten nicht allein zur Wiederherstellung der Messung abgeschwächt werden.
Passend dazu
