Safari ITP, CNAME-Cloaking und die Herausforderungen im First-Party-Tracking

Eine Subdomain der eigenen Website garantiert keine dauerhaften Analyse-Cookies. Safari kann auch Cookies aus HTTP-Antworten begrenzen, wenn der Endpunkt als verschleierter Drittanbieter erkannt wird. Für eine belastbare Prüfung sind Setzverfahren, DNS-Ziel, Browsermodus und gespeicherte Laufzeit getrennt zu betrachten.

1. Was CNAME-Cloaking bedeutet

Ein CNAME macht einen Hostnamen zum Alias eines anderen Namens: data.example.com kann etwa auf collector.vendor.example verweisen. Der Browser ruft weiterhin den ersten Namen auf. Bei Tracking kann dadurch fremde Infrastruktur unter einer Subdomain der besuchten Website erscheinen. Ein CNAME ist aber auch ein gewöhnliches Hosting-Werkzeug und allein kein Beweis für Tracking.

WebKit beschreibt die Erkennung anhand der DNS-Beziehung zur Website und zum CNAME des Hauptdokuments. Das ist eine technische Regel, keine Prüfung der Eigentumsverhältnisse eines Unternehmens. Die Cookie-Domain und das tatsächliche DNS-Ziel sind deshalb unterschiedliche Prüfpunkte.

2. Welche Sieben-Tage- und 24-Stunden-Regeln gemeint sind

• JavaScript-Cookies: WebKit führte mit ITP 2.1 eine Obergrenze von sieben Tagen für persistente Cookies aus document.cookie ein. Ein kürzeres eigenes Ablaufdatum bleibt kürzer.
• Link-Dekoration: ITP 2.2 beschreibt eine Begrenzung auf einen Tag für solche Cookies auf der Zielseite, wenn eine als Cross-Site-Tracker klassifizierte Domain die Navigation ausgelöst hat und die Zieladresse Query-Parameter oder ein Fragment enthält. Ein einzelnes utm_source beweist diese Kombination nicht.
• Weiterer Browserspeicher: Die 2020 beschriebene Löschung skriptbeschreibbarer Daten wie LocalStorage und IndexedDB berücksichtigt sieben Tage Safari-Nutzung ohne Interaktion mit der Website. Das ist ein anderer Mechanismus als die Kappung eines Cookie-Ablaufdatums.
• CNAME-/IP-Cloaking: Bei erkannten verschleierten Drittanbieter-Endpunkten kann auch die HTTP-Antwort nur Cookies mit höchstens sieben Tagen Laufzeit setzen. HttpOnly verhindert diese Kappung nicht.

Zusätzlich dokumentiert WebKit eine IP-Heuristik. Die 2024 beschriebene Fassung vergleicht unter anderem IPv4-/IPv6-Adressarten und gemeinsame Adresspräfixe. Solche Heuristiken können sich ändern; ein festes Rezept für unbegrenzte Laufzeit lässt sich daraus nicht ableiten.

3. Auswirkungen auf die Messung

Geht eine Analysekennung verloren, kann ein späterer Besuch als neuer Browser erscheinen. Frühere Kontakte lassen sich dann möglicherweise nicht mehr mit einer Conversion verbinden. Ausmaß und Richtung der Verzerrung hängen jedoch vom System, den verfügbaren Kennungen und dem Attributionsmodell ab.

Eine Abwesenheit von acht Tagen führt deshalb nicht zwingend in jeder Konfiguration zu einer neuen ID. Ebenso verlieren nicht sämtliche Kohorten oder A/B-Tests automatisch ihre statistische Aussagekraft. Ein Safari-Chrome-Vergleich liefert Hinweise, aber keinen isolierten Kausalnachweis: Geräte, Kampagnen, Einwilligungen und Nutzungsverhalten können ebenfalls verschieden sein.

4. Eigene Endpunkte und Cookie-Attribute richtig einordnen

Ein Reverse Proxy unter demselben Host kann einen kontrollierten Datenweg bereitstellen. Ein CDN kann dabei die TLS-Verbindung terminieren; das bedeutet nicht, dass dessen IP-Adressen dem Websitebetreiber gehören. Gleiche Origin, gleiche Site und organisatorische Kontrolle sind verschiedene Begriffe.

HttpOnly sperrt den JavaScript-Zugriff auf ein Cookie. Secure beschränkt die Übertragung auf HTTPS, SameSite beeinflusst die Übermittlung bei websiteübergreifenden Anfragen. Keines dieser Attribute garantiert eine bestimmte Lebensdauer. Ein Server kann außerdem ein Cookie ohne HttpOnly setzen. Für den Setzweg ist die tatsächliche Set-Cookie-Antwort entscheidend.

Legitime Sitzungen und zulässige Messung benötigen zweckgerechte Kennungen, angemessene Laufzeiten und gegebenenfalls Einwilligung. Eine eigene Domain macht Tracking weder automatisch zulässig noch immun gegen Browser-Schutz. WebKit veröffentlichte am 19. Oktober 2026 zusätzlich die domainbasierte Blockierung von Identity-Resolution-Infrastruktur in den Betriebssystemversionen 27. Diese Netzwerkmaßnahme ist von den Cookie-Fristen zu unterscheiden.

5. Eine konkrete Installation prüfen

1. Safari-Version, Betriebssystem, normalen oder privaten Modus und relevante Schutzoptionen festhalten.
2. Hostnamen und DNS-Auflösung von Hauptdokument und Messendpunkt dokumentieren.
3. Im Web Inspector die Cookie-setzende Antwort beziehungsweise den Skriptzugriff ermitteln. Attribute und tatsächlich gespeichertes Ablaufdatum vergleichen.
4. Wiederkehr, Interaktion, vorhandene Einwilligung und gegebenenfalls Cookie-Erneuerung als getrennte Testfälle behandeln.
5. Fehlende Kennungen, blockierte Requests und fachliche Ereignisse getrennt auswerten. Ein Einzelabruf bestätigt keine mehrtägige Beständigkeit.