1. Situation
Mike hatte im November 2019 auf eine Trackingtechnik mit der Bezeichung CNAME-Cloaking (auch bekannt als DNS Delegation oder DNS Alias) hingewiesen. Bereits 2014 hatten sich Lukasz Olejnik und Claude Castelluccia in der Studie »Analysis of OpenX-Publishers Cooperation« mit den Risiken von DNS Alias und Cookie Leaking bei Real-Time-Bidding-(RTB-)Auktionen beschäftigt. Um die Ausgangssituation rund um das CNAME-Cloaking verständlicher zu machen, beginnen wir mit einem kurzen Blick zurück. Bisher war es für viele Webseiten gang und gäbe, Drittanbieter-Elemente (sogenannte 3rd Party Ressourcen) einzubinden. Dabei werden bei einem Seitenaufruf u. U. Dutzende dieser Drittanbieter-Anfragen (auch weltweit) durchgeführt und eine Verbindung mit einer Vielzahl von Akteuren (hauptsächlich Tracking-Unternehmen) im Internet hergestellt. Menschen, die eine Webseite ansurften, bekamen davon nichts oder nur wenig mit. Meist war das Ziel der Übung, das Verhalten von Menschen zu tracken (mittels z. B. Tracking-Pixeln, -Skripten, -Cookies) und Nutzerprofile anzulegen – dies meist in Verbindung mit Drittanbieter-Cookies (3rd-Party Cookies). Mit zunehmender Regulierung (z. B. Anwendbarkeit der DSGVO) und Rechtsprechung (z. B. Planet49-Urteil), wurde zunächst versucht, mittels (teils unübersichtlicher) Consent-Banner (auch fälschlicherweise Cookie-Banner genannt) eine möglichst weit gefasste Einwilligung für ebenjene Drittanbieter-Elemente einzuholen. In den letzten Jahren begannen die Browserhersteller allerdings zunehmend Anti-Tracking-Funktionen, wie beispielsweise Apples Intelligent Tracking Protection (ITP) oder Firefox Enhanced Tracking Protection (ETP), in ihre Produkte zu integrieren. Hinzu kamen Anti-Tracking-Browser-Erweiterungen wie z. B. uBlock Origin. Dies führte dazu, dass Drittanbieter-Anfragen zunehmend durch den Browser blockiert wurden und Tracking-Geschäftsmodelle in Gefahr gerieten.
[…] Browser-Hersteller neigen zunehmend dazu, ihre technologische Sonderrolle als De-facto-Regulator einzusetzen. Dies kann durchaus als Missbrauch von Marktmacht betrachtet werden, jedenfalls ist die entsprechende Legitimation fraglich, da kaum mehr als vier oder fünf Unternehmen den globalen Markt beherrschen. An dieser Stelle ist Sensibilität und Offenheit für die gesamte digitale Wirtschaft im Interesse aller Marktteilnehmer gefragt, hier ist möglicherweise die Politik gefordert. […]
Quelle: »Kampf um die Daten« der BVDW e.V. Vizepräsident in der c’t 1 21.12.19 Seite 98
Für viele in der Online-Werbebranche scheint daher die »Cookie Apocalypse« bevorzustehen (ähnlich wie das Ende des Internets bei der Anwendbarkeit der DSGVO vorausgesagt wurde).
IAB Chair: The Cookie Is Dead. Long Live “The Next Web”
Quelle: WARC, zititiert in Interactive Advertising Bureau (IAB), Annual Report 2020
In obig geschildertem Gesamtkontext ist nun die Verwendung von CNAME-Cloaking zu sehen. Denn um Drittanbieter-Aufrufe zu unterbinden, werden meist Blockierlisten verwendet, die bekannte Tracking-Domänen enthalten. Genau hier setzt das CNAME-Cloaking an, denn es verschleiert die Tracking-Domäne, die eigentlich blockiert werden soll. Dazu muss der Webseiten-Betreiber eine sogenannte Subdomäne (z. B. xy.example.de) im DNS Resource Record seiner Domain (z. B. example.de) anlegen. Dieser Alias verweist im CNAME Resource Record auf die Subdomäne eines Tracking-Anbieters. Die schlussendliche IP-Adresse, auf die die Subdomäne verweist und bis zu der aufgelöst wird, gehört demnach nicht zum Webserver des Webseitenbetreibers, sondern zu einem Tracking-Server. Für den Webbrowser sieht der Aufruf der getarnten Subdomäne xy.example.de allerdings aus, als handele es sich um die ursprünglich angesurfte Webseite und den dazugehörigen Webserver. Da Browser-Erweiterungen z. B. bei Google Chrome keinen Zugriff auf den DNS Layer des Web Request haben, kann auch die Anti-Tracking-Erweiterung uBlock in der Chrome-Version dies nicht erkennen. Hingegen ist es mit der Firefox DNS API möglich, dass ein Addon wie z. B. uBlock Origin (ab der Version 1.24 bzw. Version 1.25.0) bei Firefox auf den DNS-Layer zugreift und das CNAME enttarnt. Der Chromium-basierte Browser Brave kann inzwischen, nach eigenem Bekunden, ebenso ein DNS Alias aufdecken.
Um CNAME-Cloaking zu verstehen, müssen zunächst einige technische Einzelheiten erklärt werden. Denn wenn Sie das Internet nutzen, werden Sie unweigerlich auch diese Technik verwenden.
Gastbeitrag von lacrosse
Lacrosse ist betrieblicher Datenschutzbeauftragter in der Konzerndatenschutzorganisation einer deutschen Unternehmensgruppe. In seiner Freizeit engagiert er sich ehrenamtlich, um gemeinnützigen Vereinen bei der Umsetzung der DSGVO zu helfen.
Feedback und Fragen können direkt an ihn gerichtet werden. Spenden für seine Arbeit möchte er direkt dem Kuketz-Blog zukommen lassen. Ihr könnt also direkt an den Kuketz-Blog spenden.
2. Das Domain Name System
In der grauen Vorzeit mussten Fernsprechverbindungen von Telefonoperatoren manuell vermittelt werden. Damit heutzutage Verbindungen zwischen Geräten im Internet vermittelt werden können, gibt es das Domain Name System (DNS). Denn für die Verbindungen zwischen zwei Geräten benötigt man deren IP-Adressen (in Form einer IPv4– oder IPv6-Adresse). Diese Ziffernfolgen haben allerdings den Nachteil, dass Menschen sie sich nur schwer merken können – im Gegensatz zu namentlichen Bezeichnungen.
Der weltweite Verzeichnisdienst Domain Name System verwaltet daher die Verbindungen zwischen Namen und IP-Adressen, ähnlich einem althergebrachten Telefonbuch. Der Aufbau des DNS ist eine hierarische Baumstruktur. Die Wichtigkeit des DNS für Internetdienste ist enorm, denn es verwaltet (i) die Namensauflösung von merkbaren Domänennamen in IP-Adressen und ii) ist ein sogenannter trust anchor, dessen Vertrauenswürdigkeit systembedingt vorausgesetzt wird (zu Authentizität und Integrität des DNS siehe DNSSEC).
Quelle Bild: wikipedia.de / Creative Commons License / CC BY-SA 2.5
Dementsprechend sind Webseiten ebenso hierarisch aufgebaut. Bezogen auf Mikes Blog ist die Subdomäne forum.kuketz-blog.de eine Untergliederung unterhalb der Domain kuketz-blog.de, die wiederum unterhalb der Top-Level Domain (TLD) »de« angesiedelt ist. Anmerkung: Die Leserichtung ist von rechts nach links (rechts am höchsten in der Baumhierachie, links am niedrigsten). Die Domain www.kuketz-blog.de kann ebenso eine Subdomäne sein und kennzeichnet i. d. R. einen Webserver (www).
Quelle Bild: Durch den Autor erstellt / Anmerkung: Für einen Fully Qualified Domain Name (FQDN) folgt am Ende ein Punkt (nach example.comPUNKT). Dieser Punkt trennt die (»leere«) Root Domain von der Top Level Domain (TLD). Nach dem Punkt folgen die TLD wie zum Beispiel ».com« (com stand für commercial).
In diesem Zusammenhang sei vorausgeschickt, dass auch die Reichweite (Scope) von Cookies diesem Strukturierungsprinzip folgt, also z. B. welche Domäne oder Subdomäne den Cookie auslesen darf. Wir kommen weiter unten darauf zurück.
2.1 Der DNS Resource Record mit A Record, CNAME Record
Wir konzentrieren uns auf die für diesen Beitrag relevanten Felder des Resource Record. Der Resource Record ist eine Art »Informationstabelle«, die Datenfelder enthält. Diese Datenfelder »verbinden« u. a. Informationseinträge mit Geräten. Wichtig sind die Informationseinträge des A Record der einen DNS-Namen einer IP-Adresse (IPv4) zuordnet und der Canonical Name Record oder CNAME. Der Canonical Name verweist einen Subdomänen-Namen auf eine andere Subdomänen-Bezeichnung, der dann wiederum dieser Bezeichung bis zur IP-Adresse im jeweiligen A-Record folgt.
Quelle Bild: wikipedia.de / Creative Commons License / CC BY-SA 2.5 / die Änderungen durch den Autor sind mit den Farben Rot / Orange markiert
2.1.1 CNAME Record, der eigentliche technische Zweck
Bezogen auf das Internet möchte man heutzutage fast sagen, kein technischer Zweck, der nicht für das Tracking zweckentfremdet wird. Ähnlich wie Cookies, hat ein CNAME-Record jedoch eine technisch funktionale Daseinsberechtigung. Beispielsweise ist er von Nutzen, wenn sich die IP-Adresse der Domäne auf die die CNAME Records verweisen, ändert – diese Änderung muss nur einmal im A-Record angepasst werden. Auch können mit Hilfe eines CNAME unterschiedliche Services (z. B. Webserver, Mailserver) von einer IP-Adresse aus betrieben werden.
Folgender Umstand ist dabei wichtig. Der CNAME-Record verbindet zwei Subdomänen und keine IP-Adressen. D. h., dass die Subdomäne des Webseitenbetreibers auf die Subdomäne des Tracking-Anbieters verweist und anschließend beim Seitenaufruf bis zur IP-Adresse im A-Record der Domain des Tracking-Anbieters auflöst.
2.1.2 Das Risiko eines verwaisten DNS Eintrages
Erkennen Sie das Risiko, das diesem Konstrukt zu Grunde liegt? Jeder Webseitenbetreiber, der eine fremde Subdomänen derart einbindet, vertraut einem Dritten (und dessen Arbeitsabläufen) blind. Denn die Registrierung einer Domain (und damit der dazugehörigen Subdomänen) kann ablaufen sowie erneut an eine beliebige andere Person/Organisation vergeben werden.
Das Sicherheitsrisiko eines solchen verwaisten oder „in der Luft hängenden“ DNS-Eintrages (Dangling DNS) haben Daiping Lui, Shuai Hao und Hainan Wang in ihrer Veröffentlichung „All your DNS Records Point to US“ 2016 dargestellt.
2.1.3 Beispiele für das CNAME Cloaking
Der Einsatz von CNAME-Cloaking sei hier beispielhaft anhand von zwei deutschen eCommerce-Seiten dargestellt. Beide wurden sowohl mit dem Browser Chrome als auch mit Firefox – hier war uBlock Origin installiert – besucht. Vorweg ein Hinweis, sofern man dies selbst mit den Entwicklerwerzeugen (f12) eines Browser und / oder uBlock Origin überprüfen möchte.
- Es ist möglich, dass die Webseite das Tracking-JavaScript erst lädt, nachdem das Consent-Banner bestätigt wurde
- uBlock Origin blockiert u. U. das Consent-Banner, sofern ein Drittanbieter zum Einsatz kommt
- uBlock Origin blockiert das CNAME-Cloaking, sofern es erkannt wird
- uBlock Origin zeigt das CNAME-Cloaking am besten innerhalb des Protokolls (hier das Aktualisieren nicht vergessen)
uBlock wurde daher temporär abgeschaltet und die Webseite besucht, um obige Punkte zu vermeiden und eindeutigeres Ergebnis zu erzielen. Die Ergebnisse beider Whois-Anfragen – also auf wen eine Domäne registriert ist – können hier und dort erneut abgerufen werden. Die CNAME-Abfolgen können anhand der Übersichten nachvollzogen werden. Diese sind wie folgt strukturiert:
- Screenshot des Request der Subdomäne bei einem Webseitenbesuch
- CNAME-Kette, gegliedert nach:
- Lookup-Abfrage der gefundenen Subdomäne
- uBlock-Origin-Protokoll der Subomäne zur Überprüfung der Lookup-Abfrage
- Whois-Abfrage der Tracking-Domäne
- Ggf. weitere Websuche, um das Trackingunternehmen zu identifizieren
Beispiel 1
Quelle Bild: Durch den Autor erstellt / Javascript / Subdomäne
Quelle Bild: Durch den Autor erstellt / CNAME-Kette
Beispiel 2
Quelle Bild: Durch den Autor erstellt
Quelle Bild: Durch den Autor erstellt / CNAME-Kette
3. Cookies
In vielen Datenschutzinformationen ist folgender Satz zu lesen: »Cookies sind kleine Textdateien, die auf Ihrem Rechner gespeichert werden.«. Die Aussage ist zwar nicht falsch, aber nicht notwendigerweise korrekt. Zunächst muss man sich vergegenwärtigen, dass Cookies eine wichtige Funktion im Internet spielen. Ähnlich wie der CNAME-Record haben sie eine Zweckbestimmung, die nichts mit Tracking zu tun hat. Beispiele für diese Zwecke sind die Authentifzierung beim Login oder der Warenkorb einer e-commerce-Webseite, in dem sich die ausgewählten Produkte befinden. Dementsprechend enthalten Cookies Daten / Informationen eines Webservers, die mittels eines Browsers, auf einem Endgerät gespeichert werden und das „Verhalten“ jenes Gerätes beeinflussen können.
Cookies können nur von der Domäne ausgelesen werden, von der sie auch gesetzt wurden. Folgender Umstand ist dabei entscheidend: Sobald eine Webseite einen Cookie gesetzt hat, werden die Cookies automatisch bei jedem folgenden Aufruf der Webseite an diese übermittelt.
Was haben Cookies nun mit CNAME-Cloaking zu tun? Die Antwortet lautet: Eine ganze Menge! Denn i) sind Cookies ein beliebtes Trackinginstrument und ii) können Cookies u. U. auch an Subdomänen versandt werden. Zusätzlich muss man feststellen, dass iii) eine Funktionsüberschneidung beim Einsatz von Cookies vorhanden ist – einige dienen dem Tracking, andere erfüllen funktionelle Aufgaben für den Betrieb einer Webseite.
Was nun folgt, könnte man so formulieren: Einfache, kleine Textdateien, für die komplizierte Regeln gelten. Diese komplexen Regeln muss allerdings derjenige beachten und kennen, dessen Webseite die Cookies setzt. Denn sie beeinflussen das automatische Verhalten jedes Webbrowsers der diese Seite aufruft.
3.1 Die Same Origin
Die Same Origin besteht aus einer Kombination aus dem Protokoll (Scheme), das z. B. der Browser benutzen soll, dem Host-Namen und dem Port (optional), sofern dieser angegeben ist (in untenstehendem Beispiel muss es der Port 443 sein, da das https-Protokoll benutzt wird).
Webseiten die eine identische Kombination dieser drei Bestandteile (Scheme, Hostname, Port) aufweisen, werden als Same Orgin eingestuft. Alles was nicht dieser Kombination entspricht, wird als Cross Origin betrachtet.
Die Same Origin Policy (SOP)
Diese altehrwürdige Sicherheitsfunktion beschränkt / regelt die Interaktion von z. B. Skripten einer Herkunft (Origin: Webseite A) mit Inhalten einer anderen Herkunft (Origin: Webseite B). Dies betrifft hauptsächlich das Auslesen von Informationen – wobei es auch Ausnahmen gibt. Die SOP gilt nicht ausschließlich für Cookies, hat aber Auswirkungen auf diese. Dies sei an einem einfachen Beispiel kurz erklärt. Allgemein bekannt ist die Komfortoption „Angemeldet bleiben“ bei Webseiten. Letztlich bedeutet dies, dass z. B. ein Authentifizierungscookie auch dann noch gültig bleibt, wenn der Browser geschlossen wird und man später die jeweilige Webseite erneut besucht – man muss sich nicht mehr mit seinen Credentials anmelden. Das bedeutet aber auch, dass jeder erneute Zugriff auf diese Webseite automatisch auch einen gültigen Authentifizierungscookie enthält. Was hindert nun eine andere Webseite, die z. B. in einem anderen Tab geöffnet ist, diesen Cookie auszulesen? Die Antwort: Die Same Origin Policy, mit deren Hilfe der Browser das Auslesen von Informationen eingeschränkt. Beispiele, was Same Origin und Cross Origin sind, finden sich hier.
Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
3.2 Das Same Site Attribute
Das Same Site Attribute definiert die „Reichweite“ eines Cookies und wurde 2020 eingeführt. Ziel ist es, gestaffelte Sicherheitsebenen gegen Bedrohungen wie z. B. Cross-Site-Request-Forgery-Angriffe zu schaffen. Zur Erinnerung: SOP beschränkt das Auslesen über Webseiten hinweg (Cross Domain), sie unterbindet nicht das Schreiben / Senden von Information (wie z. B. Anlegen, Verändern, Löschen). Same Site und Same Origin sind nicht miteinander zu verwechseln. Das Same Site Attribute gibt dem Browser ein feineres Werkzeug an die Hand, z. B. den Versand von Cookies zu steuern. Damit dies funktioniert, muss der Empfänger innerhalb der DNS-Struktur klar sein. Entscheidend ist, ob es sich um dieselbe Ressource (Same Site) oder eine andere Ressource (Cross Site) handelt.
Um die Sache noch etwas komplizierter zu machen, gibt es eine sogenannte Public Suffix List von registrierten Top-Level Domains. Diese werden auch effective Top-Level Domain genannt (eTLD).
Die Regel ist nun, dass effective Top-Level Domains plus eins (eTLD+1) als Same Site angesehen werden. Ressourcen, die eine unterschiedliche eTLD+1 haben, werden als Cross Site betrachtet. Damit erhält ein Browser ein Filterkriterium (Unterschied eTLD+1), nach dem er zwischen Same Site und Cross Site unterscheiden kann.
Die Werte Strict, Lax, None des Domain Attribute
Wir erinnern uns, dass der Browser bestimmen muss, welche Cookies er einem HTTP-Request hinzufügt und das zu den Empfängern auch Subdomänen (unterhalb der eTLD+1) gehören können. An dieser Stelle kommt das Domain Attribute innerhalb eines Cookies und die Einstellungen für das Same Site Attribute ins Spiel: Strict, Lax, None. Die Kombination dieser Werte beeinflusst das automatische Verhalten eines Browsers – vergleichbar mit der Wirkung eines Filters.
- Strict = Sicherste Einstellung. Cookies werden nur Same Site versandt, d. h. im sogenannten 1st-Party Kontext
- Lax = Teilweise sichere Einstellung. Bei bestimmten Cross-Site-Anfragen von Dritten (z. B. Links) werden Cookies versandt
- None = Kaum Sicherheit. Cookies werden Same Site und Cross Site versandt. Sie müssen allerdings das Kriterium „Secure“ haben (nur HTTPS-Verbindungen)
3.2.3 Host Only Cookie
Beibt das Domain Attribute eines Cookies leer, wird ein sogenannter Host Only Flag gesetzt. Dies bewirkt, dass nur exakt die Ressource, die den Cookie auch gesetzt hat, diesen auslesen kann. Als Resultat erhält keine Subdomäne diesen Cookie (es sei denn, eine Sudomäne hat den Cookie gesetzt).
3.2.4 Das Risiko: CNAME-Cloaking und Browser-Verhalten
Für den Browser erscheint das CNAME-Cloaking wie eine Subdomäne der eigentlichen Webseite. Bei einem HTTP-Request wird der Browser daher davon ausgehen, dass es sich um diesselbe (Same Site) Ressource handelt. Nun muss man sich erneut vergegenwärtigen, dass verschiedene Cookies unterschiedlichste Funktionen (Login, Warenkorb usw.) erfüllen. Aber: für alle Cookies gelten die gleichen Regeln, nach denen der Browser sie einem HTTP-Request hinzufügt. Das CNAME-Cloaking verschleiert nun die Herkunft der Drittanbieter-Anfrage. Daher können die Sicherheitsmechanismen des Browsers und zwar für alle Cookies einer Webseite u. U. nicht greifen und im schlimmsten Fall sicherheitsrelevante Cookies einem Dritten gegenüber offenlegen.
Beispiel: CNAME-Cloaking und Browser-Verhalten
Dieses Zusammenspiel der Browser-Sicherheitsmechanismen lässt sich auch während eines CNAME-Cloakings mit den Browser-Entwicklerwerkzeugen beobachten.
Quelle Bild: Durch den Autor erstellt / Anmerkung: Der Cookie »sid« wird durch den Browser blockiert, obwohl es sich um Same Site handelt
Der Webbrowser fügt bei einem HTTP-Request Cookies entsprechend ihrer Reichweite hinzu. Allerdings wird ein Cookie mit der Bezeichung »sid« durch den Browser blockiert – vermutlich handelt es sich um einen Session-Cookie. Der Browser unterbindet den Versand des Cookies an dii2.zooplus.de, weil es ein Host Only Cookie ist und eine exakte Übereinstimmung mit dem Domain Attribute www.zooplus.de erforderlich ist.
Quelle Bild: Durch den Autor erstellt / der Http Only-Flag bewirkt, dass der Cookie nicht durch ein Skript ausgelesen werden kann
4. Die Normalisierung der Abweichung
Den Begriff »Normalisierung der Abweichung« oder »Normalization of deviance« wurde von der Professorin und amerikanischen Soziologin Diane Vaughan geprägt. Sie hatte untersucht, welche Gründe zur Challenger-Katastrophe geführt hatten. Vereinfacht gesagt, versteht man unter einer »Normalisierung der Abweichung« z. B. in einer Organisation oder Unternehmenskultur, dass Abweichungen zu korrekten Verhalten / Prozessen toleriert werden. Die Menschen gewöhnen sich dabei an diese Abweichung, bis zu dem Punkt, in dem sie diese nicht mehr als unsicher wahrnehmen – die Abweichung wird Bestandteil eines normalen Vorgehens. Ein entscheidender Faktor für die Normalisierung ist, dass sich aus der Abweichung nicht unmittelbar erkennbare negative Folgen ergeben.
CNAME cloaking: CNAME cloaking refers to the practice of delegating a sub-domain to a third party and then enabling the third party to deploy cookies appearing as “first-party” instead of “third-party,” which the CNIL states is not contrary to the GDPR and the French Data Protection Act. The CNIL highlights, however, that such practice can induce security vulnerabilities and incidents, and must be implemented with care and strict respect of applicable rules and appropriate security measures. During audits, the CNIL would therefore certainly look for websites practicing CNAME cloaking.
Die französische Datenschutzaufsicht (CNIL) hat in ihrer FAQ auf die Unsicherheit dieses Vorgehens hingewiesen und davon abgeraten. Auch wenn diese Abweichung, nach Ansicht der CNIL, nicht notwendigerweise gegen die Vorgaben der DSGVO verstößt.
The Commission also encourages against the use of entity identity masking techniques using trackers, such as CNAME cloaking.
Quelle: ON THE PRACTICAL PROCEDURES FOR COLLECTING THE CONSENT PROVIDED FOR IN ARTICLE 82 OF THE FRENCH DATA PROTECTION ACT, CONCERNING OPERATIONS OF STORING OR GAINING ACCESS TO INFORMATION IN THE TERMINAL EQUIPMENT OF A USER (RECOMMENDATION „COOKIES AND OTHER TRACKERS“) / Draft Recommendations / 14. Januar 2020
Dennoch ist festzustellen, dass CNAME-Claoking nicht als »good practice« bezeichnet werden kann. Denn es findet eine Abweichung zu Ungunsten der Sicherheitsstandards von Web-Browsern statt. Gleichzeitig führt es innerhalb einer Organisation zu Intransparenzen, denn ein mögliches Sicherheitsproblem (z. B. Dangling DNS) könnte nicht erkannt werden, da es außerhalb der Organisation liegt. Zudem handelt es sich um automatisierte Vorgänge (z. B. HTTP-Request Cookies), d. h. die Detektion eines Cookie-Leaks würde eine ständige Überprüfung erfordern. Gemäß der »Normalisierung der Abweichung« ist diese allerdings kaum zu erwarten, da bisher noch keine negativen Folgen eingetreten sind.
Wie in Punkt 1.) geschildert, handelt es sich um eine Abweichung, um Tracking weiterhin zu ermöglichen, und ist eine Reaktion auf Browser Anti-Tracking-Funktionen. Daher ist die Abweichung als Abkürzung oder »workaround« anzusehen, um unter Zeitdruck ein Problem zu lösen. Auch hierbei wirkt das unmittelbare Ausbleiben negativer Folgen als rechtfertigender Verstärker. Der »Workaround«, als Abweichung, wird daher zur Normalität.
Und wie heißt es im digitalen Arbeitsalltag so schön? Nichts ist so langlebig wie ein »Workaround« …
Bildquellen:
Cloaking: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Gastbeitrag
Gastbeiträge werden von Autoren verfasst, die nicht zum festen Redaktionsteam des Kuketz-Blogs gehören. Bevor ein Gastbeitrag veröffentlicht wird, findet eine inhaltliche Abstimmung mit mir statt. Dabei übernehme ich die redaktionelle Bearbeitung des Textes, prüfe den Inhalt und bereite den Beitrag sorgfältig für die Veröffentlichung im Blog vor.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Der TC-String des Interactive Advertising Bureau (IAB) – Teil2
Firefox: First Party Isolation – Firefox-Kompendium Teil4
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
Wer erlaubt Analysetracking in Deutschland und Europa – das TTDSG Teil2
Abschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.