{"id":10565,"date":"2026-09-24T12:30:00","date_gmt":"2026-09-24T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10565"},"modified":"2026-09-09T17:16:52","modified_gmt":"2026-09-09T15:16:52","slug":"fingerprinting-schutz-in-safari-26-welche-schnittstellen-fur-bekannte","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/data-privacy-de\/fingerprinting-schutz-in-safari-26-welche-schnittstellen-fur-bekannte\/","title":{"rendered":"Fingerprinting-Schutz in Safari 26: Welche Schnittstellen f\u00fcr bekannte Skripte eingeschr\u00e4nkt werden"},"content":{"rendered":"

Safari 26 bringt einen erweiterten Schutz gegen Fingerprinting mit, der ohne Zutun aktiv ist. Die Beschreibung bei WebKit ist ungew\u00f6hnlich genau darin, was er tut – und noch genauer in einem Wort, das in jedem Satz dar\u00fcber vorkommt: Er richtet sich gegen bekannte<\/em> Fingerprinting-Skripte.<\/p>\n

Dieses Wort tr\u00e4gt die ganze Ma\u00dfnahme. Es entscheidet dar\u00fcber, ob dieselbe Schnittstelle einen echten oder einen unbrauchbaren Wert zur\u00fcckgibt, und es macht diesen Schutz zum ersten in Safaris Geschichte, der zwei Skripte auf derselben Seite unterschiedlich behandelt.<\/p>\n

\n\"Vier
Die drei oberen Schichten treffen jedes Skript. Die unterste trifft nur die Skripte, die auf einer Liste stehen – und das ist der einzige Unterschied zwischen den beiden Sonden.<\/figcaption><\/figure>\n

Was der Schutz einem erkannten Skript entzieht<\/h2>\n

WebKit nennt drei Gruppen. Die erste sind Schnittstellen, aus denen sich Ger\u00e4teeigenschaften ablesen lassen: Bildschirmma\u00dfe, die Zahl der Rechenkerne, die Liste der \u00fcber die SpeechSynthesis verf\u00fcgbaren Stimmen, Zahlungsf\u00e4higkeiten, die R\u00fcckgabe aus Web Audio und das 2D-Canvas. Ein erkanntes Skript bekommt hier keine verl\u00e4sslichen Werte mehr.<\/p>\n

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<\/code> lassen sich nicht mehr auslesen, weil sich \u00fcber beide eine Wiedererkennung beim Seitenwechsel bauen l\u00e4sst.<\/p>\n

Die dritte Gruppe ist f\u00fcr die Messung die interessanteste, denn sie betrifft nicht die Wiedererkennung eines Ger\u00e4ts, sondern die Zuordnung eines Besuchs. Wer die Herkunft nicht lesen kann, kann keine Quelle bestimmen – unabh\u00e4ngig davon, ob er je vorhatte, jemanden wiederzuerkennen.<\/p>\n

Das Wort, an dem alles h\u00e4ngt<\/h2>\n

Wie ein Skript auf die Liste ger\u00e4t, beschreibt WebKit nicht \u00f6ffentlich, und eine einsehbare Liste gibt es nicht. Das ist aus Sicht des Schutzes folgerichtig, denn eine ver\u00f6ffentlichte Liste w\u00e4re eine Anleitung zum Ausweichen. F\u00fcr die Betreiberseite bedeutet es allerdings, dass sich die Frage, ob ein bestimmtes Werkzeug betroffen ist, nicht nachschlagen l\u00e4sst.<\/p>\n

Beantworten l\u00e4sst sie sich nur durch Messen. Ein kurzer Vergleich derselben Werte in Safari und in einem anderen Browser zeigt, ob die R\u00fcckgaben auseinandergehen. Sinnvoll ist das f\u00fcr jedes eingebundene Skript, das Ger\u00e4teeigenschaften abfragt – und das sind mehr, als die meisten \u00dcbersichten ausweisen, weil Betrugserkennung, Bot-Abwehr und Personalisierung dieselben Schnittstellen benutzen wie Fingerprinting.<\/p>\n

Gegenprobe im Entwicklerfenster, in Safari und daneben\n\n  screen.width + \"x\" + screen.height\n  navigator.hardwareConcurrency\n  speechSynthesis.getVoices().length\n  document.referrer\n  new URLSearchParams(location.search).get(\"gclid\")\n\n  Weichen die Werte zwischen zwei Browsern ab, ohne dass sich\n  am Gerät etwas geändert hat, steht das ausführende Skript\n  vermutlich auf der Liste. Gleiche Werte heißen das Gegenteil.<\/code><\/pre>\n
Warum trotzdem kaum etwas kaputtgegangen ist<\/h2>\n
Nach der Ver\u00f6ffentlichung blieb die erwartete Welle an Ausf\u00e4llen aus, und das hat einen einfachen Grund: Gew\u00f6hnliche Analyse- und Werbeskripte stehen nicht auf der Liste. Sie messen Seitenaufrufe, Ereignisse und Kampagnen, und daf\u00fcr brauchen sie keine merkmalsreichen Schnittstellen. Auch die Kampagnenparameter in der utm<\/code>-Form sind nicht betroffen, weder von diesem Schutz noch von der \u00e4lteren Entfernung bekannter Klickkennungen.<\/p>\n
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\u00e4rung wird und die tats\u00e4chliche Ursache dann ungepr\u00fcft stehen bleibt.<\/p>\n
Was die \u00e4lteren Schichten l\u00e4ngst genommen hatten<\/h2>\n
Der Grund, warum dieser Schutz so wenig Wirkung auf gew\u00f6hnliche Messung hat, liegt darin, dass die Verluste vorher eingetreten sind. Drittanbieter-Cookies sind in Safari seit 2020 standardm\u00e4\u00dfig 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.<\/p>\n
Diese drei Schichten treffen jedes Skript ausnahmslos, und sie haben die Wiedererkennung \u00fcber l\u00e4ngere Zeitr\u00e4ume in Safari bereits beendet. Der neue Schutz erg\u00e4nzt eine vierte Schicht, die sich an eine benannte Gruppe richtet – er ist deshalb die auff\u00e4lligste Ank\u00fcndigung der Reihe und die mit der geringsten Breitenwirkung.<\/p>\n
Was daraus folgt<\/h2>\n
F\u00fcr 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\u00f6glich, und ob sie es sind, steht in keiner Liste, sondern nur in einem Vergleich.<\/p>\n
Zwei Dinge lohnen sich dennoch. Das erste ist die Bestandsaufnahme, welche eingebundenen Skripte Ger\u00e4teeigenschaften abfragen – eine Frage, die unabh\u00e4ngig von Safari 26 zu beantworten ist, weil sie auch f\u00fcr die Einwilligungsdokumentation gilt. Das zweite ist die Erkenntnis aus der dritten Gruppe: Wo die Herkunft eines Besuchs zur Ware wird, h\u00e4ngt die Zuordnung an einer Angabe, die ein Browser inzwischen unterschlagen darf. Wer das f\u00fcr ein Randproblem h\u00e4lt, sollte nachz\u00e4hlen, wie viele Zuordnungsentscheidungen im eigenen Aufbau allein auf document.referrer<\/code> beruhen.<\/p>\n
\n
Quellen<\/h2>\n