Drücke „Enter”, um zum Inhalt zu springen.
Ausprobieren
Online Webseiten-Check
sofort das Ergebnis sehen
Auf meiner Webseite sind externe Links mit dem Symbol gekennzeichnet. Datenschutzhinweise · Wissensartikel

Consent Management Plattformen (CMP): Wie zuverlässig sind Cookie-Tools für Webseiten?

0

Kann ein Consent Tool automatisch sicherstellen, dass auf einer Webseite, auf der das Tool eingebunden wurde, einwilligungspflichtige Vorgänge (Cookies, Google Fonts …) so lange unterdrückt werden, bis eine Einwilligung durch den Nutzer vorliegt? Ist der Datenschutz mit einem Cookie Blocker gewährleistet?

Einleitung

Consent Management Plattformen bieten einen Automatikmodus, den viele Betreiber von Webseiten nutzen. Die Betreiber meinen, wenn man ein Consent Tool einfach so einbindet, dann blockiert es wirkungsvoll Cookies und sogar Google Fonts. Das ist Bullshit, um es höflich zu formulieren.

Die Überschrift zu diesem Beitrag enthält den Begriff Cookie Tool. Dieser Begriff ist an sich falsch. Es geht beim Datenschutz nicht nur um Cookies, sondern auch um Cookies. Weil der Terminus so griffig ist, hat er sich durchgesetzt. Das liegt auch daran, weil einige Anbieter von Consent Management Plattformen so tun, als ginge es nur um Cookies. Das wird schön an den Namen einiger Tools deutlich, die beispielsweise Cookiebot oder Borlabs Cookie heißen.

Das Urteil des LG München vom 20.01.2022 zu Google Fonts rief ins Bewusstsein, dass Cookie Tools natürlich versagen, wenn es um Schriftarten geht. Das Urteil schwappte rüber bis nach Österreich, wo jetzt der Bär tobt. Dann gab es noch den Beschluss der Vergabekammer Baden-Württemberg zu Datentransfers in die USA allgemein. Auch das hat nichts mit Cookies zu tun. Ich erwähne diese Rechtsentscheidungen nur hilfsweise. Dem Datenschutzkundigen sind Themen wie Schrems II, Nutzerprofilbildung oder Datenverarbeitung außerhalb des berechtigten Interesses hinlänglich bekannt.

Ich wundere mich schon, dass manche glauben, eine Webseite durch bloßes Einbinden eines sogenannten Cookie-Tools rechtskonform gemacht werden (vielleicht noch ein paar Datenschutztexte einstreuen, und alles ist gut). Aber noch viel mehr wundere ich mich über naive Menschen aus der Webseiten-Branche, die meinen, Consent Management Plattformen könnten auch Google Fonts unterdrücken. Selbst wenn das zuverlässig möglich wäre, würde es doch die Optik einer Webseite zerstören, wenn ein Nutzer nicht in Schriftarten einwilligt. Solchen Internet-Beratern würde ich empfehlen, einen neuen Job zu suchen, der nichts mit Software-Technik und Web-Entwicklung zu tun hat.

Meine folgende Untersuchung zeigt, warum Consent Tools im Automatik-Modus nicht zuverlässig funktionieren können. Automatik-Modus heißt:

  1. Consent Tool scannt Webseite X
  2. Webmaster bindet Consent Tool auf Webseite X ein
  3. Alles ist gut (jedenfalls fast alles)

Untersuchung

Insbesondere geht es also um die Beantwortung folgender Frage:

Können Webseiten mit Hilfe von Consent Management Plattformen zuverlässig automatisch datenschutzkonform gemacht werden?

Es geht also um den oben genannten Automatik-Modus. Um die Betrachtung von Datenschutztexten geht es hier nicht. Gehen wir der Einfachheit davon aus, dass die Datenschutztexte in Gänze vorliegen (auch wenn dies in der Praxis nicht so ist, wie meine frühere Untersuchung zeigt).

Populäre Browser

Zwei populäre Browser sind Mozilla Firefox und Google Chrome, wie auch eine Statistik aus dem Jahr 2021 zeigt (Quelle: Studie zu Marktanteilen der meistgenutzten Browserversionen weltweit im Oktober 2021 von Statista, abrufbar unter der Internet-Adresse https://de.statista.com/statistik/daten/studie/158095/umfrage/meistgenutzte-browser-im-internet-weltweit/). Mozilla und Google sind die Hersteller und Anbieter der Browser. Deren beiden eben genannte Browser ziehe ich zur Beurteilung des Stands der Technik exemplarisch heran.

Der ebenfalls recht weit verbreitete, datenschutzfreundliche Tor-Browser basiert auf der Firefox-Technologie (Quelle: https://support.torproject.org/glossary/firefox/). Die Untersuchung sollte somit direkt auf den Tor-Browser übertragbar sein. Auf den Tor-Browser gehe ich nicht näher ein, weil dieser für meine Untersuchung nicht Ausschlag gebend ist. Auch andere Browser zeigen das relevante Verhalten in gleicher Weise.

Aufruf einer Webseite aus technischer Sicht

Ich beschreibe zunächst in Kürze und aus der Vogelperspektive, wie eine Webseite aufgerufen wird und was dabei technisch passiert.

Eine Webseite wird von einem Nutzer („Besucher“) besucht, indem der Nutzer einen Browser auf seinem Endgerät öffnet und die Adresse der Webseite eingibt. Alternativ kann der Nutzer auch eine Suchmaschine verwenden, um nach einer Webseite zu suchen und im Suchergebnis einen passenden Treffer auswählen. Ein Endgerät ist beispielsweise ein Desktop PC oder Smartphone.

Webseiten bestehen im Wesentlichen aus zwei technischen Komponenten:

  1. Server-Seite („Backend“)
  2. Client-Seite („Frontend“)

Die Server-Seite liegt beim Betreiber der Webseite. Der Server des Betreibers wird beim Besuch einer Webseite im Hintergrund aufgerufen (daher auch die Bezeichnung „Backend“). Der Server stellt nun die Inhalte zusammen, die beim Besucher im Browser dargestellt werden sollen. Sodann sendet der Server die Antwort auf die Anfrage (Aufruf der Webseite) an den Aufrufer (Besucher), wo die Inhalte dann im Browser dargestellt werden (also im „Frontend“).

Der Browser des Besuchers ist die Client-Seite. Überwiegend diese Seite wird folgend betrachtet, weil sie zur Beantwortung der Untersuchungsfrage fast ausschließlich relevant ist.

Technologien für Webseiten

Webseiten bestehen auf der Client-Seite im Wesentlichen aus zwei Technologien:

  1. HTML und CSS
  2. JavaScript

HTML ist eine Beschreibungssprache, mit der Inhalte und deren Darstellung definiert werden können. Zur Vereinfachung der Darstellungsdefinition können mit der Stilsprache CSS-Regeln definiert werden, beispielsweise in Form der Regel „Hauptüberschriften werden im Fettdruck dargestellt“.

JavaScript ist eine sogenannte Script-Sprache. Damit können (eher kleine) Programme geschrieben werden, die dann direkt im Browser des Besuchers ausgeführt werden.

Mit Hilfe von HTML können Dateien in eine Webseite eingebunden werden. Eine Datei kann eine Mediendatei, wie ein Bild oder ein Video sein. Eine Datei kann aber auch wiederum aus HTML und CSS bestehen, oder aus JavaScript-Code. Derart können Webseiten modular gestaltet werden. Der modulare Aufbau erlaubt es, dass Webseiten auf vorgefertigte Dienste zurückgreifen können, um für häufig benötigte Funktionen „das Rad nicht neu erfinden zu müssen“.

Ausführbarkeit von Diensten

Ein Dienst ist ein Script, ein Plugin, oder allgemeiner, ein Tool. Beispiele sind: Google Fonts, extern eingebundene Hilfsdatei, Facebook Pixel, Google Maps Plugin. Auch eine Consent Management Plattform (CMP) ist selbst ein Dienst. Eine CMP basiert auf der Client-Seite, also auf einer eingebundenen Webseite, insbesondere auf JavaScript.

Bevor ein Dienst fertig geladen wurde, steht er nicht zur Verfügung. Dies gilt insbesondere für JavaScript-Programme. Ein Dienst basierend auf JavaScript kann erst (im Browser des Besuchers) ausgeführt werden, nachdem es vollständig geladen wurde. Das geht einerseits aus meiner Erfahrung mit der Analyse von Webseiten hervor. Zweitens bestätigen mir dies meine Erfahrungen in der Programmierung von Web-Anwendungen. Drittens geht dies aus dem HTML Standard für Browser hervor. Der HTML Standard für die Verarbeitung von JavaScript-Diensten ist hier definiert: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-async. Es handelt sich laut dieser Quelle um eine gemeinsame Definition für den „lebenden Standard“ von HTML von den Firmen Apple, Google, Mozilla und Microsoft, die allesamt Anbieter populärer Browser sind. In dieser Quelle ist etwa in Abschnitt 4.12.1.1 in Nr. 26 beschrieben, dass ein Script (hier im Sinne von JavaScript-Dienst zu verstehen) erst geladen sein muss, bevor es für die Ausführung bereitsteht. Sowohl der Chrome Browser von Google als auch der Firefox Browser von Mozilla sind von dieser Regelung betroffen.

Prinzip einer Consent Management Plattform (CMP)

Übrigens heißt es oft in rein englischer Terminologie Consent Management Platform, statt „Plattform“ in Deutsch zu schreiben. Ich schreibe hier durchgängig „Plattform“, weil der Plural ansonsten im Deutschen entgleiten würde („Platforms“).

Eine CMP wird als JavaScript-Programm ausgeliefert und derart in eine Webseite eingebunden. Eine CMP ist somit, wie bereits erwähnt, selber ein Dienst.

Die Grundidee einer CMP ist folgende (jedem der folgenden Punkte ist zum besseren Verständnis ein kurzer, von mir selber gewählter Oberbegriff vorangestellt):

  1. Untersuchen: Die CMP analysiert im Vorfeld die Webseite derart, dass einwilligungspflichtige Dienste von der CMP erkannt werden.
  2. Einbinden: Die CMP wird als erster Dienst auf der Webseite eingebunden.
  3. Ausführen: Das CMP-Programm wird geladen.
  4. Blockieren: Das CMP-Programm unterdrückt das Laden alle anderen einwilligungspflichtigen Dienste.
  5. Einwilligungsabfrage: Das CMP-Programm fragt den Besucher der Webseite nach seiner Einwilligung für die auf der Webseite vorliegenden, einwilligungspflichtigen Dienste.
  6. Entsperren: Nach Vorliegen einer Einwilligung werden die bisher unterdrückten Dienste geladen.

Um zu wissen, welche Dienste einwilligungspflichtig sind, durchläuft die CMP im eben genannten Schritt eins („Untersuchen“) die infrage stehende Webseite in regelmäßigen Abständen, beispielsweise anfangs und dann einmal pro Monat. Dieser Vorgang wird auch als Scan-Prozess bezeichnet. Weil CMPs in ihren Werbeaussagen häufig auf Cookies abzielen und CMPs häufig als Cookie Popups bezeichnet werden, ist oft vom Cookie Scanner die Rede.

Die vom Scanner erkannten Dienste werden nun mit Hilfe einer Datenbank als einwilligungspflichtig oder nicht einwilligungspflichtig klassifiziert. Ob diese Klassifizierung richtig oder falsch ist, ist hier nicht relevant, wenngleich dieser Punkt in der Praxis oft für Probleme sorgt.

Das automatische Unterdrücken von Diensten verstehe ich so, dass dies ohne weiteres Zutun des Webseitenbetreibers, der einen CMP-Dienst einbindet, stattfindet. Dies leitet sich auch aus den eben dargestellten sechs Schritten der Arbeitsweise eines CMP-Dienstes ab. Relevant sind hier insbesondere die Schritte eins (automatischer Scanner) und vier (automatisches Unterdrücken bzw. Blockieren). Weil eine CMP die Möglichkeit der Entgegennahme einer Einwilligung in Form eines oft als „Cookie Popup“ bezeichneten Mechanismus‘ enthält, ist vorwiegend Schritt sechs der Automatik zuzurechnen. Ebenso finde ich mein Verständnis dessen, was unter einer automatischen Unterdrückung zu verstehen ist, durch zahlreiche Befragungen von Webseiten-Betreibern bestätigt. Die große Mehrzahl dieser nimmt an, dass die CMP nach Einbindung in die Webseite ihre Arbeit verrichtet und nichts weiter zu tun sei, damit die Webseite einwilligungspflichtige Dienste ordentlich handhabt.

Ein Unterdrücken bzw. Blockieren von Diensten durch eine CMP ist nur möglich, wenn die CMP selber geladen wurde, bevor weitere Dienste geladen werden, die von der CMP unterdrückt werden sollen. Dies ist logisch, da eine CMP nur arbeitsfähig ist, wenn sie geladen wurde. Eine CMP könnte theoretisch direkt in die Webseite eingebettet sein, derart dass das Laden der Kernfunktionen der Webseite (bzw. des HTML-Codes) die CMP implizit lädt. Dies ist aber in der Praxis für CMPs nicht möglich, wenn diese der oben in diesem Abschnitt genannten Grundidee der sechs Schritte folgen. Es ist deshalb nicht möglich, weil die Ergebnisse des „Untersuchen“-Schritts später beim „Einbinden“-Schritt nur dann zur Verfügung stehen, wenn das Einbinden der CMP derart geschieht, dass die Ergebnisse des „Untersuchen“-Schrittes nachgeladen werden.

Demnach muss eine CMP dieser Art auf einer Webseite so eingebunden werden, dass die CMP nachgeladen wird, und zwar analog zu jedem anderen auf der Webseite eingebundenen Dienst. Meine Untersuchung zeigt zudem, dass selbst ein direkt in eine Webseite integriertes Programm (Script) nicht in der Lage ist, Ladevorgänge von Diensten zuverlässig zu unterbinden.

Funktionsweise von Browsern beim Laden von Diensten

Im Folgenden beschreibe ich, wie Dienste, die auf einer besuchten Webseite eingebunden sind, von einem modernen Browser geladen werden. Diese Beschreibung erscheint mir notwendig, weil ein noch nicht fertig geladener Dienst wie eine CMP die Ladevorgänge anderer Dienste nicht blockieren kann (vgl. vorigen Abschnitt, Prozess „Blockieren“).

Moderne Browser wie Mozilla Firefox oder Google Chrome versuchen Webseiten derart zu laden, dass diese Webseiten möglichst schnell im Browser dargestellt werden können.

Um eine schnelle Darstellung zu erreichen, laden moderne Browser nach Möglichkeit mehrere Dienste gleichzeitig, die von der Webseite eingebunden werden. Insbesondere passiert dies, wenn mehrere Dateien von verschiedenen Adressen (Servern) geladen werden.

Das Verhalten des parallelen Ladens mehrerer Dienste kann mithilfe einer Netzwerkanalyse gezeigt werden. Die Netzwerkanalyse ist eine Möglichkeit, die in den genannten Browsern von Hause aus zur Verfügung steht und jederzeit genutzt werden kann. Die Netzwerkanalyse zeichnet die beim Aufruf einer Webseite stattgefundenen Ladevorgänge von Diensten auf und stellt sie dar.

Die folgende von mir durch Besuch einer beliebigen Webseite selbst angefertigte Abbildung veranschaulicht die Darstellung der Netzwerkanalyse in Mozilla Firefox (Aufruf über Taste F12 dort).

Abbildung 1: Diagramm für das Laden von Diensten auf einer besuchten Webseite.

Im Bild ist ein Diagramm zu sehen. Das Diagramm zeigt pro Zeile einen Dienst. Von links nach rechts in einer Zeile ist in Form eines Balkens zu erkennen, wann der Ladevorgang für einen Dienst begann und wann er endete. Die Gesamtladedauer ist in Millisekunden („ms“) angegeben.

So ist beispielsweise der erste gezeigte Dienst in 380 ms geladen worden. Der Ladevorgang begann einige hundert Millisekunden, nachdem die Webseite aufgerufen wurde (nämlich laut Diagramm irgendwann zwischen 640 ms und 960 ms nach Aufruf der Webseite).

Durch Anklicken eines Dienstes in der Netzwerkanalyse, aus der das eben gezeigte Diagramm entstand, offenbart sich die Bedeutung der Farben der Balken. Zur Veranschaulichung habe ich folgende Abbildung angefertigt.

Abbildung 2: Unterteilung der Ladezeiten eines Dienstes nach Art (Mozilla Firefox).

Wesentlich ist hier, dass ein Ladevorgang aus Wartezeiten, Verbindungsaufbauzeiten, Abrufzeiten und Empfangszeiten besteht. Der im Bild gezeigte rote Balken mit der Beschriftung „Blockiert:“ besagt, dass der Browser den Abruf des Dienstes noch nicht starten konnte, weil er das Zustandekommen der Netzwerkverbindung zum Dienst abwarten musste (Quelle: Beschreibung von Mozilla unter https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor/request_details).

Der eben genannte „Blockiert-Status“ ist mit dafür verantwortlich, dass nicht sicher davon ausgegangen werden kann, dass ein CMP-Dienst (für den der Ladeprozess vor dem aller anderen auf der Webseite eingebundenen Dienste gestartet wird) fertig geladen ist, bevor ein anderer Dienst angefangen wird zu laden (oder fertig geladen ist). Denn Ausschlag gebend für die Ladedauer eines Dienstes ist eben auch die Dauer des Verbindungsaufbaus und nicht nur die Abrufdauer für den Dienst (in Form einer Datei). Somit kann selbst ein CMP-Dienst, der idealerweise aus einer winzig kleinen Datei besteht und weitere Funktionen erst später nachlädt, erst fertig geladen sein, nachdem der Ladevorgang für andere Dienste bereits gestartet wurde.

Aus der Abbildung 1 geht hervor, dass der Ladevorgang mehrerer Dienste gleichzeitig oder nahezu gleichzeitig stattfinden kann und oft auch derart stattfindet, wie mir die Praxis zeigt. Dies wird etwa durch Betrachten der ersten drei Zeilen in der Abbildung 1 deutlich. Diese drei Zeilen gebe ich hier erneut wieder und lasse den Rest der Abbildung zur Vereinfachung weg:

Abbildung 3: Ladevorgänge von drei Diensten.

Hieraus ergeben sich für mich insbesondere folgende Erkenntnisse:

  1. Die Ladevorgänge zweier Dienste werden im konkreten Fall nahezu zeitgleich gestartet (nämlich die ersten beiden Dienste).
  2. Der Ladevorgang des dritten Dienstes (der unterste) beginnt, nachdem die Ladevorgänge anderer Dienste gestartet, aber noch nicht beendet wurden.

Um Missverständnisse zu vermeiden, merke ich folgendes zur Abbildung 3 an: Die Ladevorgänge der ersten beiden Dienste wurden entweder zu unterschiedlichen Zeiten gestartet und/oder zu unterschiedlichen Zeiten beendet. Dies ergibt sich aus den unterschiedlichen Dauern der Ladevorgänge, nämlich einmal 380 ms und einmal 379 ms. Die Abbildung ist einfach nur nicht hochauflösend genug, um diese unterschiedlichen Start- und/oder Endzeitpunkte darstellen zu können.

Das zu Mozilla Firefox Vorgetragene konnte ich zu Google Chrome in Experimenten ebenfalls feststellen.

Unerwünschte Ausführung von zu blockierenden Diensten

Ein Dienst, der von der CMP blockiert werden soll, kann gemäß meinen vorigen Ausführungen unerwünschter Weise ausgeführt werden, wenn er fertig geladen wurde, bevor die CMP fertig geladen und deren Programmcode ausgeführt wurde, der den Dienst blockieren soll.

Weil die Ladezeit für eine CMP unbestimmt lange sein kann (insbesondere bei kurzer Nichtverfügbarkeit des CMP-Servers), ist damit festgestellt, dass eine CMP nicht garantiert fertig geladen wurde, bevor ein anderer Dienst fertig geladen wurde.

Selbst für den Fall, dass eine CMP fertig geladen wurde, bevor ein anderer Dienst, dessen Ladevorgang bereits begonnen wurde, fertig geladen wurde, ist es einer CMP nicht zuverlässig möglich, den anderen Dienst vollständig zu blockieren.

Hierfür gibt es mehrere Gründe, die ich kurz beschreibe.

Ein Grund hierfür ist, dass nach dem Fertigladen der CMP und vor dem fertigen Ausführen der Programmanweisungen der CMP, die für das Blockieren eines anderen Dienstes zuständig sind, eine kurze Zeit vergeht. Innerhalb dieser Zeit kann der andere Dienst ebenfalls fertig geladen und teilweise oder vollständig ausgeführt worden sein.

Der nächste Grund, warum eine CMP nicht zuverlässig andere Dienste blockieren kann, bevor eine Einwilligung durch einen Besucher einer Webseite erteilt wurde, ist in sogenannten Werbe-Blockern zu finden. Werbe-Blocker sind Plugins, die im Browser des Nutzers installiert werden. Ein Beispiel ist das Ghostery-Plugin für Mozilla Firefox und Google Chrome. Solche Plugins sorgen (technisch zuverlässig) dafür, dass bestimmte Ladevorgänge unterbleiben. Dies ist den Plugins deswegen zuverlässig möglich, weil die Plugins direkt im Browser arbeiten und somit auf diesen auf einer niedrigen Ebene (Systemebene im OSI-Modell) und somit sehr früh einwirken können. Dies steht im Gegensatz zu CMPs, die auf einer hohen Ebene und somit später im Prozess des Webseiten-Aufrufs arbeiten müssen.

Werbe-Blocker können dafür sorgen, dass ein CMP-Dienst nicht geladen wird. Somit kann der CMP-Dienst nicht anfangen zu arbeiten und somit auch nicht andere Dienste unterdrücken. Ein solches Verhalten konnte ich auf den voneinander unabhängigen Webseiten von Inhabern bekannten deutscher Marken feststellen. Auf einer dritten Webseite eines Inhabers einer ebenfalls bekannten deutschen Marke konnte ich feststellen, dass der Dienst namens DynamicYield ohne Einwilligung geladen wurde, obwohl die Einwilligungsabfrage („Cookie Popup“) auf meinem Bildschirm zu sehen war, nach einer Einwilligung für DynamicYield fragte und ich diese Einwilligung noch nicht erteilt hatte.

Ein weiterer Grund ist, dass Dienste, deren Ladevorgang begonnen wurde, bereits anfangen können zu arbeiten. Dies geschieht auf der Server-Seite des Dienstanbieters, also nicht erst (später) im Browser des Besuchers. Die Arbeit auf Server-Seite wird dadurch befeuert, dass vorhandene Cookies zum Server, auf dem der Dienst bereitgestellt wird, mit übertragen werden, sobald der Dienst vom Browser angefordert wird. Solche Cookies sind insbesondere dann vorhanden, wenn der Dienst auch auf anderen (zuvor besuchten) Webseiten eingebunden wurde. Derartige Dienste sind etwa Google Maps oder Google reCAPTCHA.

Datenverarbeitung aufgrund begonnener Ladevorgänge

Eine weitere Arbeitsgrundlage für den Dienst auf Server-Seite schon während des Ladevorgangs des Dienstes stellen die zum Abruf des Dienstes übermittelten Metadaten dar. Dies ist analog zu den eben genannten Cookies, findet aber immer statt und nicht nur bei Diensten, die Cookies nutzen. Die Metadaten beinhaltet die ungekürzte IP-Adresse des Besuchers der Webseite sowie Charakteristiken zu dessen Endgerät. Hierzu zählen unter anderem die Art des Browsers, dessen genaue Version und das Betriebssystem. Derartige Daten können beispielsweise ausgewertet werden, um den Benutzer zu früheren Sitzungen zuzuordnen bzw. das Nutzerverhalten zu analysieren, was insbesondere für Dienste aus den Bereichen Marketing und Sicherheit relevant ist.

Diese Art der Zuordnung von Metadaten zu Nutzern wird als Device Fingerprinting oder Browser Fingerprinting bezeichnet. Hierfür gibt es zahlreiche Quellen, die den Vorgang beschreiben. Hier seien genannt:

Mit Hilfe des Fingerprintings kann ein Nutzer über mehrere Webseiten und mehrere Sitzungen hinweg als Nutzer X erkannt werden, der somit von anderen Nutzern abgrenzbar ist, die eben nicht als Nutzer X, sondern beispielsweise als Nutzer Y oder Z erkannt werden. Das Verhalten eines Nutzers X kann derart festgestellt werden und etwa als Basis für die Anzeige personalisierter Werbung dienen.

Meine eigenen Experimente zeigen ferner, dass das Abbrechen eines auf einer Webseite bereits begonnenen Ladevorgangs eines Dienstes über ein JavaScript-Programm zumindest in einigen populären Browser nicht zuverlässig funktionierte, so etwa im Mozilla Firefox. Dies gilt dann, wenn ein Dienst über eine Standard-Programmanweisung (sogenannter script-Tag) eingebunden ist und versucht wird, mit einem nachträglich geladenen JavaScript-Programm in den Ladevorgang einzugreifen. Das Problem würde nicht durch neuere Versionen eines Browsers geheilt werden, da nicht auszuschließen ist, dass einige Nutzer ältere Browser-Versionen nutzen.

Schlussfolgerungen

Meine Schlussfolgerungen aus meinen Untersuchungen sind insbesondere:

  1. Eine Consent Management Platform (CMP) ist selber ein Dienst und unterliegt denselben Bedingungen wie andere Dienste, die von der CMP unterdrückt werden sollen.
  2. Wird eine CMP eingesetzt, dann hat dies fachlich nur Sinn, wenn mindestens ein weiterer Dienst (neben der CMP) verwendet wird (der von der CMP kontrolliert werden soll). Somit sind mindestens zwei Dienste im Einsatz, wenn eine CMP (in sinnvoller Weise) zum Einsatz kommt.
  3. Zur Optimierung der Ladezeit einer Webseite laden moderne Browser mehrere auf der Webseite eingebundene Dienste nahezu parallel. Dies geschieht derart, dass das Laden eines Dienstes begonnen wird, nachdem das Laden eines anderen Dienstes begonnen, aber nicht notwendigerweise abgeschlossen wurde.
  4. Bevor ein JavaScript-Dienst nicht vollständig geladen wurde, steht er nicht zur Ausführung zur Verfügung und wird auch nicht ausgeführt.
  5. Somit steht auch ein CMP-Dienst erst nach vollständigem Laden zur Verfügung und kann auch dann erst ausgeführt werden.
  6. Der Ladevorgang eines anderen Dienstes, der geladen wird, bevor der CMP-Dienst vollständig geladen wurde, kann somit vom CMP-Dienst nicht (automatisch) blockiert werden.
  7. Der Ladevorgang eines Dienstes, dessen Ladevorgang bereits begonnen wurde, kann durch eine CMP nicht zuverlässig abgebrochen werden.
  8. Dienste können bereits während des Ladevorgangs (auf der Server-Seite) ihre Arbeit beginnen zu verrichten.
  9. Ein automatisches Unterdrücken (Blockieren) eines Dienstes durch eine CMP bedeutet, dass die CMP auf der betreffenden Webseite eingebunden wird und die CMP selber die einwilligungspflichtigen Dienste ohne Anpassung der Direktiven zum Laden dieser Dienste auf der betreffenden Webseite blockieren kann, bis eine Einwilligung vom Besucher der Webseite abgefragt wurde.
  10. Die Ausführung eines Dienstes kann durch eine CMP nicht zuverlässig automatisch unterbunden werden.
  11. Ob ein Dienst einwilligungspflichtig ist oder nicht, ändert nichts an der Grundproblematik des automatischen Blockierens des Dienstes durch eine CMP.

Die Sachverhalte, die zu diesen Schlussfolgerungen führten, waren durch Untersuchen technischer Gegebenheiten feststellbar.

Zum eben genannten Punkt 2 der Aufzählung eine Anmerkung: Mich fragt immer wieder jemand, ob man nicht trotzdem ein „Cookie Popup“ einbinden soll, auch wenn es gar nicht nötig ist. Als Argument wird die Sorge vorgetragen, dass manche gerade wegen des fehlenden Popups meinen könnten, die Webseite hätte Datenschutzprobleme. Ich kann davon nur abraten. Das schlimmste, was bei zurecht fehlendem Cookie Popup passieren kann, ist eine unqualifizierte, in Gänze unberechtigte Beschwerde bei einer Aufsichtsbehörde (manche meinen diese Beschwerde, wenn sie von „Anzeige“ sprechen).

Fazit

Ein Blockieren von auf einer Webseite eingebundenen Diensten kann durch einen CMP-Dienst auf automatische Weise nicht sichergestellt werden, weil dem technische Gründe entgegenstehen.

Eine Consent Management Plattform (CMP) kann auf Webseiten nicht automatisch sicherstellen, dass auf diesen Webseiten eingebundene (einwilligungspflichtige) Dienste bis zum Vorliegen einer Einwilligung, die durch Webseiten-Besucher erteilt wird, unterdrückt werden.

Ergebnis meiner Untersuchung.

Wenn Sie unbedingt ein Cookie Tool nutzen wollen, dann nutzen Sie entweder inaktiven Code. Dazu kann die mittlerweile standardisierte Direktive data-src (statt src) im HTML script Befehl verwendet werden. Beispiel:

<script data-src="www.boese-webseite.de/mit/einwilligungspflichtigem-script.js">

Dafür müssen Sie aber den Quellcode Ihrer Webseite anpassen. Bei Plugins, die Google Fonts nutzen, ist das technisch anspruchsvoller bzw. würde zur Empfehlung führen, ein bestimmtes datenschutzfeindliches Plugin nicht mehr zu nutzen.

Alternativ können Sie mein Consent Tool nutzen, bei dem Sie sich um all das kümmern müssen, was andere Consent Tools von Hause aus potentiell falsch mitbringen, nämlich Datenschutztexte.

Vielleicht gelingt es Ihnen ja, auf einwilligungspflichtige Dienste ganz zu verzichten. Dann brauchen Sie kein nerviges und meist rechtswidriges Cookie Popup. Den Google Tag Manager etwa braucht niemand. Wer ihn nutzt, dann entweder aus Bequemlichkeit, Unwissenheit oder, weil die Konzernstruktur dies begünstigt. Falls Sie wirklich eine interaktive Karte meinen zu brauchen, nehmen Sie doch meine interaktive Karte.

Konnte ich Sie immer noch nicht von einer Consent Management Plattform abbringen, dann empfehle ich, die Checkliste für Einwilligungsabfragen anzusehen (am Ende des Beitrags gibt es ein PDF im Kurzformat).

Bullshit Basics
Dies war ein Beitrag aus der Kategorie Bullshit Basics.
In dieser Kategorie werden weit verbreitete Unwahrheiten oder Falschwissen thematisiert und durch Fakten aufbereitet.
Wer schreibt hier?
Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. In IT und Datenschutz bin ich auch als Sachverständiger tätig. Mir sind juristische Gegebenheiten nicht fremd. Meine Ergebnisse gewinne ich durch Betrachtung von Technik und Recht. Das scheint mir absolut notwendig, wenn es um digitalen Datenschutz geht. Über neue Beiträge werden Sie informiert, wenn Sie meinen Newsletter abonnieren. Über Ihre Unterstützung für meine Arbeit würde ich mich besonders freuen.
Bitte nutzen Sie bei Verwendung meiner Ergebnisse die Quellenangabe oder verlinken Sie gut wahrnehmbar auf diesen Artikel:
Einen Kurzlink oder eine Bestätigung für Ihre Quellenangabe erhalten Sie kurzfristig auf Anfrage. Ein Teilen oder Verteilen dieses Beitrags ist natürlich ohne weiteres möglich und gewünscht.

Schreiben Sie einen Kommentar

Ihre Mail-Adresse wird nicht veröffentlicht.

Nächster Beitrag

Die Nicht-Protokollierung von IP-Adressen: Alles gut beim Datenschutz?