Warum CNAME-Cloaking Tracker nicht mehr vor Safari oder Brave versteckt

Was ist CNAME-Cloaking?

Ein Tracking-Anbieter nutzt CNAME-Cloaking, wenn ein Website-Betreiber eine der eigenen Subdomains der Site, etwa metrics.example.com, über einen DNS-CNAME-Eintrag auf den Server des Anbieters zeigen lässt, sodass der Browser die Requests des Anbieters als First Party behandelt. Browser entscheiden über First Party oder Third Party anhand der registrierbaren Domain, und ein CNAME versteckt das echte Ziel eine Ebene unterhalb des Webs, im DNS. Der Anbieter bekommt den Cookie-Zugriff Ihrer eigenen Site, ohne als separate Domain aufzutauchen.

John Wilander von WebKit erklärte die Wirkung in einem Beitrag vom 12. November 2020: Die Third-Party-Domain "is cloaked as sub.blog.example and thus has the same powers as the true first party." Der Leitfaden zum Safari Privacy Report führt CNAME-getarnte Endpunkte als etwas auf, das Sie prüfen sollten.

Wie lässt ein CNAME-Eintrag einen Tracker wie First Party aussehen?

Ein CNAME-Eintrag lässt einen Tracker wie First Party aussehen, indem er einen Namen unter Ihrer Domain auf den Hostnamen des Trackers umleitet, bevor der Browser überhaupt eine IP-Adresse sieht, sodass jede Prüfung des Browsers nur Ihre Domain sieht. Die Kette sieht so aus:

1. Die Seite auf www.example.com lädt ein Skript oder sendet einen Request an metrics.example.com.
2. DNS antwortet, dass metrics.example.com ein CNAME für collect.tracker.example ist.
3. DNS löst collect.tracker.example zur IP-Adresse des Anbieters auf.
4. Der Browser verbindet sich, aber die URL, der Name im TLS-Zertifikat und der Cookie-Geltungsbereich lauten alle metrics.example.com.

Zwei Cookie-Regeln machen das für einen Tracker lohnend. Requests an metrics.example.com tragen jedes Cookie, das für example.com gilt, und dazu zählen laut WebKit "login cookies and user identity cookies." Außerdem kann die Antwort über einen Set-Cookie-Header neue Cookies für example.com setzen, die der Browser als First-Party-Cookies ablegt.

Diese zweite Regel ist der Grund, warum Tracker das Setup vorangetrieben haben. Intelligent Tracking Prevention in Safari löscht per JavaScript erstellte Cookies nach 7 Tagen ohne Nutzerinteraktion auf der Site, was der Leitfaden zum 7-Tage-Cookie-Limit in Safari ausführlich behandelt. Vor November 2020 fielen Cookies, die ein Server in einer HTTP-Antwort setzte, nicht unter diese Grenze. WebKit formulierte es unverblümt: "Cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking prevention."

Wie erkennt Safari CNAME-Cloaking?

Safari erkennt CNAME-Cloaking, indem es den CNAME, über den eine First-Party-Subressource aufgelöst wird, mit der eigenen Domain der Site und dem CNAME des Top-Frames vergleicht, und es begrenzt jedes Cookie, das in einer abweichenden Antwort gesetzt wird, auf 7 Tage. WebKit lieferte die Abwehr in Safari 14 auf macOS Big Sur sowie in iOS 14 und iPadOS 14 aus, angekündigt am 12. November 2020: "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days."

WebKit definiert den Auslöser genau: "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists." Die letzte Bedingung deckt Sites hinter einem CDN oder Edge-Host ab, bei denen die ganze Site über einen CNAME aufgelöst wird. Die eigene Tabelle von WebKit deckt diese Fälle ab:

Haupt-Site (www.blog.example)	Tracking-Subdomain (track.blog.example)	Cookie-Ablauf
Kein Cloaking	Kein Cloaking	Keine Begrenzung
Kein Cloaking	Zeigt auf other.blog.example	Keine Begrenzung
Kein Cloaking	Zeigt auf tracker.example	Begrenzung auf 7 Tage
Zeigt auf abc123.edge.example	Kein Cloaking	Keine Begrenzung
Zeigt auf abc123.edge.example	Zeigt auf dasselbe abc123.edge.example	Keine Begrenzung
Zeigt auf abc123.edge.example	Zeigt auf other.blog.example	Keine Begrenzung
Zeigt auf abc123.edge.example	Zeigt auf tracker.example	Begrenzung auf 7 Tage

Die aktuelle Seite zur Tracking Prevention von WebKit dehnt dieselbe Regel auf Adress-Tricks aus, die ganz ohne DNS-Namen auskommen: "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." Das deckt die Variante ab, bei der der Adresseintrag einer Subdomain auf die IP-Adresse eines Anbieters zeigt statt auf einen Hostnamen des Anbieters.

Ein Cookie aus einer getarnten Antwort läuft jetzt 7 Tage nach dem Setzen ab, dieselbe Grenze, die für JavaScript-Cookies gilt. Cloaking verschafft in Safari also keine langlebigere ID mehr.

Wie enttarnen Brave und uBlock Origin CNAME-Tracker?

Brave und uBlock Origin enttarnen CNAME-Tracker, indem sie den Hostnamen selbst auflösen, den kanonischen Namen gegen ihre Tracker-Filterlisten prüfen und den Request blockieren, wenn das echte Ziel gelistet ist.

uBlock Origin in Firefox. uBlock Origin 1.25.0 fordert zusätzlich die Berechtigung dns von Firefox an, und die Release Notes sagen: "From now on uBO will CNAME-uncloak network requests." Die Funktion hängt an der API browser.dns von Mozilla, und das Forschungsteam von Brave merkte an, dass "this solution only works in Firefox, as Chromium does not provide the browser.dns API." Laut dem Wiki von uBlock Origin ist die Einstellung "Uncloak canonical names" seit uBO 1.34.0 eine reguläre Einstellung, ist "default enabled" und "is currently supported only on Firefox." uBlock Origin in Chrome kann den CNAME überhaupt nicht sehen.

Brave Shields. Brave kündigte das CNAME-basierte Blockieren am 20. Juli 2020 an und lieferte es mit Brave 1.17 an alle Nutzer aus. Brave prüft für jeden Request an einen Host mit CNAME zwei URLs: "first, the original URL requested by the page, and second, the same URL, but with the CNAME'ed domain name replaced with the resolved 'canonical' domain name." Das Beispiel war 16ao.mathon.fr, eine Subdomain, die nach First Party aussah und deren kanonischer Name et5.eulerian.net war, ein Third-Party-Tracker.

Ein Detail bei Brave bringt Website-Betreiber ins Straucheln. Seit Version 1.30 wendet der Standardmodus "standard" der Shields von Brave die Netzwerk-Filterlisten nicht auf Same-Site-Subressourcen an, während der Modus "aggressive" sie auf "all sub-resource requests, first and third-party alike" anwendet. Die Beiträge von Brave sagen nicht, wie der Standardmodus eine getarnte Subdomain behandelt, nachdem sie enttarnt wurde. Testen Sie Ihre eigene Site daher im Modus "aggressive", bevor Sie sich auf eines der beiden Ergebnisse verlassen. Werbeblocker und Privacy-Browser drücken die Analytics-Zahlen ohnehin, wie der Leitfaden zu den Auswirkungen von Werbeblockern auf die Genauigkeit von Analytics erklärt. CNAME-Cloaking holt diese Daten nicht zuverlässig zurück.

Drei Browser, drei Reaktionen auf eine getarnte Subdomain

Safari 14 Lässt die Anfrage durch und begrenzt Cookies aus der Antwort auf 7 Tage

Brave 1.17 Prüft den kanonischen Namen gegen seine Filterlisten und blockiert die Anfrage, wenn der Tracker gelistet ist

uBlock Origin Enttarnt den CNAME und blockiert Treffer in Firefox, sieht den CNAME in Chrome aber nicht

Welche Sicherheitsrisiken hat CNAME-Cloaking?

CNAME-Cloaking holt den Server eines Anbieters in Ihren Cookie-Geltungsbereich, sodass jedes Cookie, das Ihre Site auf die Root-Domain bezieht, Login- und Session-Cookies eingeschlossen, bei jedem Request an diesen Anbieter geht. Das ist ein Datenschutzrisiko für Besucher und ein Sicherheitsrisiko für Sie. Der Beitrag von WebKit nennt zwei Probleme. Website-Betreiber, die eine getarnte Subdomain nach Vertragsende stehen lassen, "risk full website takeovers or customer cookie hijacking if the CNAME records aren't properly managed." Außerdem verweist er auf einen Bericht über 250 Websites "of banks, healthcare companies, restaurant chains, and civil rights groups", die über schlecht verwaltetes CNAME-Cloaking kompromittiert wurden. Ein Besucher, der die Requests in den DevTools prüft, sieht zudem nur metrics.example.com, ohne Hinweis darauf, dass die Daten an eine externe Firma gehen.

Ist ein Reverse Proxy dasselbe wie CNAME-Cloaking?

Ein Reverse Proxy ist kein CNAME-Cloaking, weil Ihr eigener Server den Request auf Ihrer Domain annimmt und an den Anbieter weiterleitet, sodass der DNS-Eintrag für diesen Hostnamen auf Ihre Infrastruktur auflöst und nicht auf die des Anbieters. Nach der Definition von WebKit bedeutet Cloaking, dass die Subressource "resolves through a CNAME that differs from the first-party domain." Ein Pfad wie example.com/api/track, den Ihr eigener Webserver verarbeitet, tut das nicht.

Die Unterschiede, die für Analytics zählen:

Frage	CNAME-Cloaking	Reverse Proxy auf Ihrem Server
Wohin zeigt der DNS-Eintrag?	Auf den Hostnamen des Anbieters	Auf Ihren eigenen Server
Wer bekommt Ihre Root-Domain-Cookies?	Der Anbieter, direkt	Ihr Server, der entscheidet, was er weiterleitet
Begrenzt Safari Cookies aus der Antwort?	Ja, auf 7 Tage	Nicht nach den Regeln zu CNAME- oder IP-Cloaking
Sehen Brave oder uBO eine Tracker-Domain?	Ja, nach dem Enttarnen	Kein Tracker-Hostname zum Enttarnen, pfadbasierte Filterregeln greifen aber weiterhin
Müssen Sie den Anbieter weiterhin offenlegen?	Ja	Ja

Ein Proxy ändert nichts daran, wer die Daten verarbeitet. Ein Anbieter, der Cross-Site-Profile aufbaut, ist hinter beiden Setups dasselbe Datenschutzproblem. Der Leitfaden zum serverseitigen Tracking behandelt Tagging-Server, die hinter einem CNAME stehen.

Wie prüfen Sie, ob Ihre Site CNAME-Cloaking nutzt?

Sie prüfen auf CNAME-Cloaking, indem Sie jede Subdomain auflisten, an die Ihre Seiten Requests senden, jede davon auflösen und alle markieren, die zu einer Firma auflösen, die Sie nicht selbst betreiben:

1. Öffnen Sie Ihre Site in den Chrome DevTools, gehen Sie zum Network-Panel, laden Sie neu und notieren Sie jeden Request an eine Subdomain Ihrer eigenen Domain, die nicht Ihr Haupt-Host ist.
2. Führen Sie für jede davon dig CNAME metrics.example.com oder nslookup -type=CNAME metrics.example.com in einem Terminal aus.
3. Vergleichen Sie die Antwort mit Ihrer eigenen Infrastruktur. Ihr CDN oder Hosting-Anbieter ist zu erwarten. Ein Analytics-, Ad-Tech- oder Customer-Data-Anbieter ist ein getarnter Tracker.
4. Prüfen Sie die Response-Header dieser Requests auf Set-Cookie. Ein Cookie für Ihre Root-Domain von einem Anbieter-Host ist das Muster, das Safari begrenzt.
5. Löschen Sie CNAMEs, die auf Anbieter zeigen, die Sie nicht mehr nutzen.

Wie geht Flowsery mit Proxy-Setups um?

Die Dokumentation von Flowsery beschreibt ein Proxy-Setup, keinen CNAME: Sie leiten das Skript unter /js/main.js und den Endpunkt unter /api/track über Ihren eigenen Server, und "Flowsery Analytics auto-detects proxied setups. No data-api is needed if you proxy both /js/main.js and /api/track." Die Doku enthält Proxy-Anleitungen für Next.js, Express.js, PHP, Flask, FastAPI, Vue.js, Nginx, Caddy, Astro, Laravel und DigitalOcean. Das Tracking-Skript von Flowsery läuft cookieless mit einem täglich rotierenden Besucher-Hash und erhebt keine personenbezogenen Daten, in diesem Modus gibt es also gar kein Besucher-Cookie, das Safari begrenzen könnte. Die Feature-Seite zu datenschutzfreundlichem Analytics listet auf, was der Tracker speichert und was er weglässt.

Häufig gestellte Fragen

Spielt CNAME-Cloaking für cookieloses Analytics eine Rolle?

Die CNAME-Abwehr von Safari begrenzt Cookies, ein Skript ohne Cookie bietet Safari also nichts zum Begrenzen. uBlock Origin in Firefox löst den Hostnamen trotzdem auf und blockiert eine getarnte Subdomain, deren kanonischer Name auf seinen Listen steht, und Brave führt dieselbe Prüfung des kanonischen Namens durch. Ein cookieloses Skript, das über Ihren eigenen Server geleitet wird, gibt ihnen keinen Anbieter-Hostnamen zum Enttarnen.

Umgeht CNAME-Cloaking Werbeblocker?

CNAME-Cloaking umgeht listenbasierte Blocker, die nur den Hostnamen sehen, und dazu gehört uBlock Origin in Chrome. uBlock Origin in Firefox löst den kanonischen Namen auf und blockiert den Request, wenn er zu einem bekannten Tracker passt, und Brave führt dieselbe Prüfung seit Version 1.17 durch. Safari blockiert den Request nicht, begrenzt aber die Cookies, die er setzt, auf 7 Tage.

Mit welcher Safari-Version kam die Abwehr gegen CNAME-Cloaking?

Safari 14 brachte sie auf macOS Big Sur, iOS 14 und iPadOS 14, angekündigt von WebKit am 12. November 2020. Dieselbe Begrenzung auf 7 Tage gilt inzwischen auch für Third-Party-IP-Adress-Cloaking.

Zählt ein CDN-CNAME in Safari als Cloaking?

Nein, nicht wenn das CDN Ihre ganze Site ausliefert. Die Regel von WebKit nimmt eine Subdomain aus, deren CNAME mit dem CNAME des Top-Frame-Hosts übereinstimmt, sodass eine Site und ihre Subdomains auf demselben Edge-Host die normale Cookie-Laufzeit behalten. Die Begrenzung greift, wenn eine Subdomain zu einem anderen Host eines Drittanbieters auflöst.

Ist serverseitiges Tagging hinter einem CNAME vor ITP sicher?

Nein. Ein Tagging-Server, der über einen CNAME auf den gehosteten Dienst eines Anbieters erreicht wird, erfüllt die Definition von Third-Party-CNAME-Cloaking nach WebKit, sodass Safari seine Cookies auf 7 Tage begrenzt. Wenn Sie den Server auf Ihrer eigenen Infrastruktur betreiben und der DNS-Eintrag auf Ihre eigene IP zeigt, greift diese Regel nicht.

Wie entferne ich CNAME-Cloaking von meiner Site?

Löschen Sie den CNAME-Eintrag für die Anbieter-Subdomain in Ihrer DNS-Zone und entfernen Sie die Tags, die sie aufrufen. Wenn Sie den Anbieter weiterhin brauchen, leiten Sie seinen Endpunkt über einen Reverse Proxy, den Sie selbst betreiben, und nennen Sie den Anbieter in Ihrer Datenschutzerklärung.

Warum nutzen Tracker CNAME-Cloaking?

Der Browser behandelt eine Subdomain Ihrer Site als First Party. Anfragen an sie tragen die Cookies der Root-Domain, und die Antwort kann neue Cookies für diese Domain setzen. Vor November 2020 lagen Cookies, die ein Server in einer HTTP-Antwort setzte, außerhalb der 7-Tage-Grenze von Safari.

Blockiert Brave CNAME-Cloaking standardmäßig?

Brave prüft den kanonischen Namen seit Version 1.17 gegen seine Filterlisten. Seit Version 1.30 wendet der Standardmodus der Shields keine Netzwerk-Filterlisten auf Subressourcen derselben Site an, der aggressive Modus wendet sie auf alle Subressourcen-Anfragen an. Wie der Standardmodus eine getarnte Subdomain behandelt, sagen die Brave-Beiträge nicht. Testen Sie Ihre Site deshalb im aggressiven Modus.

Blockiert uBlock Origin CNAME-Cloaking in Chrome?

In Chrome nicht. Chromium bietet die browser.dns-API nicht an, deshalb sieht uBlock Origin in Chrome den CNAME nicht. In Firefox ist die Einstellung "Uncloak canonical names" standardmäßig aktiv und blockiert Anfragen, deren kanonischer Name zu einem bekannten Tracker passt.

Was ist IP-Adress-Cloaking?

IP-Adress-Cloaking ist die Variante, bei der der Adresseintrag einer Subdomain auf die IP-Adresse eines Anbieters zeigt statt auf einen Anbieter-Hostnamen. Im DNS erscheint kein CNAME. Laut WebKit erkennt ITP das und begrenzt Cookies aus der HTTP-Antwort auf 7 Tage, genau wie bei CNAME-Cloaking.