gekennzeichnet. 
Auf vielen Webseiten wird der Besucher durch Cookie Popups genervt. Sie nerven nicht nur, sondern sind auch noch unzuverlässig und erzeugen somit massenweise Rechtsverstöße. Dass Consent Tools an sich unzuverlässig sind, beweist dieser Beitrag.
Einleitung
Bindet eine Webseite einen Dienst wie Google Analytics ein, darf dieser Dienst erst nach Einwilligung durch den Besucher der Webseite geladen werden. Die rechtliche Grundlage ist die ePrivacy-Richtlinie, zumindest immer dann, wenn es um Cookies geht. Weitere Gründe für eine Einwilligungspflicht liefern der Art. 5 DSGVO (Datenminimierung) und die Art. 44ff DSGVO (Datentransfer in unsichere Drittländer).
Eine Einwilligungsabfrage auf Webseiten wird oft auch als Cookie Popup, Cookie Blocker, Consent Tool oder Consent Popup bezeichnet. Oft wird auch von Consent Management Plattformen gesprochen.
Dieser Beitrag zeigt, dass die Marketing-Versprechen vieler Anbieter von Consent Tools unhaltbar sind. In der Praxis verschlimmbessern Consent Tools Webseiten sehr häufig. Die Folge sind zahlreiche rechtliche Mängel. Das habe ich in meinem großen Praxistest zu Cookie Blockern gezeigt.
In diesem Beitrag erfahren Sie, warum Cookie Consent Tools objektiv und ganz allgemein nie zuverlässig funktionieren können, wenn man auf deren Automatik vertraut oder wenn gängige Tools von Google, Facebook, Vimeo usw. eingesetzt werden. Aber auch sonst gibt es eine immer vorhandene Unzuverlässigkeit, weil Cookies auf vielen Wegen in ein Endgerät gelangen können (darum geht es nämlich in der ePrivacy Richtlinie).
Gründe für die Unzuverlässigkeit von Cookie Blockern
Ich werde fünf Gründe nennen, die objektiv zutreffen und ganz allgemein beweisbar sind. Mir ist wichtig, dass Sie dies verstehen. Die fünf Gründe basieren auf harten, unwiderlegbaren Fakten.
1. Der Cookie Blocker
Der erste Grund, warum Cookie Blocker nicht zuverlässig funktionieren können, ist rein technischer Natur. Die Arbeitsweise eines Consent Scripts, wie sie durch Werbeaussagen zahlreicher Hersteller suggeriert wird, ist wie folgt:
- Das Consent Script wird auf jeder Seite einer Webseite eingebunden, und zwar so, dass es vor allen anderen Scripten und Dateien geladen wird.
- Das Consent Script erkennt angeblich alle einwilligungspflichtigen Vorgänge und blockiert diese angeblich, bis der Nutzer eingewilligt hat
Die Praxis sieht anders aus. Moderne Browser laden mehrere Dateien nahezu gleichzeitig. Dies passiert vor allem dann, wenn die Dateien von unterschiedlichen Servern geladen werden. Werden auf einer Webseite beispielsweise Google Maps, Google Schriften und ein Consent Tool Script eingebunden, passiert in etwa folgendes:
- Der Ladevorgang für das Consent Script beginnt
- Der Ladevorgang für das Google Maps Script beginnt
- Der Ladevorgang für Google Schriften beginnt
- Irgendwann vor oder nach Punkt 2 oder 3 ist der Ladevorgang des Consent Scripts abgeschlossen. Erst dann kann das Consent Script versuchen, die folgenden Ladevorgänge abzubrechen. Dies funktioniert nur für noch nicht begonnene Ladevorgänge
Es ist nicht vorhersagbar, ob das Consent Script schnell genug lädt, um fertig geladen und arbeitsbereit zu sein, bevor mit dem Laden von Google Maps oder Google Schriften begonnen wird. In der Praxis lässt sich tausendfach feststellen, dass die gewünschten Unterbrechungen von Ladevorgängen nicht funktioniert.
Consent Tools können Ladevorgänge für Webseiten-Tools nicht zuverlässig unterbinden
Um zuverlässig Ladevorgänge unterbinden zu können, müsste die Webseite erheblich angepasst werden
Bewusst habe ich im Beispiel Google Schriften aufgenommen, denn diese setzen selbst wahrscheinlich keine Cookies. Offensichtlich wird auf Webseiten das Laden von Google Fonts durch Consent Tools nicht unterbunden. Der Grund hierfür ist nachfolgend genannt.
2. Der Cookie Scanner
Wie der Name Cookie Blocker oder Cookie Consent schon sagt, versteifen sich viele Consent Tools darauf, Cookies blockieren zu wollen. Die Funktionsweise solcher Blocker ist wie folgt:
- Ein Cookie Scanner durchläuft eine Webseite
- Auf jeder gefundenen Seite der Webseite wird geschaut, ob Cookies gesetzt werden
- Die Ladevorgänge, denen Cookies zugeordnet werden können, werden vermerkt
- Wird die Webseite später aufgerufen, versucht das dort eingebundene Consent Script nun, alle zuvor als Cookie-behaftet erkannten Ladevorgänge zu unterbinden, bis eine Einwilligung vorliegt
Offenbar funktioniert dieses Vorgehen nicht für Google Schriften und auch nicht für das eingebundene YouTube Video mit erweiterten Datenschutzeinstellungen. Letzteres bedeutet nämlich, dass gar keine YouTube-Cookies erzeugt werden. Wie ich in einem eigenen Beitrag gezeigt habe, sind die Datenverarbeitungsvorgänge von YouTube Scripten derart umfangreich, dass alleine daraus eine Einwilligungspflicht nach Art. 5 DSGVO resultiert. Zusätzlich könnte man noch den Datentransfer in unsichere Drittländer als Argument anführen.
Das umfasende Erkennen von relevanten Cookies ist nicht möglich. Der Fokus auf Cookies ist unvollständig.
Kritik an Cookie-basierten Scannern
Ein weiterer Grund für die objektiv feststellbare Unzuverlässigkeit von Consent Tools ist technischer Natur.
Stellen Sie sich vor, eine Webseite lädt Google Maps. Nehmen wir an, das Karten-Script setzt keine eigenen Cookies, lädt aber Dateien von der Adresse google.com nach.
Ein Cookie Scanner durchläuft nun die Webseite, auf der die Karte eingebunden ist. Dazu simuliert der Scanner einen Browser. Dieser Browser entspricht einem Browser, der zum ersten Mal überhaupt aufgerufen wurde. Im Browser sind also bisher keinerlei Cookies gespeichert. Der Browser ist jungfräulich. Der Scanner erkennt in diesem Fall keine Cookies.
In der Realität sieht es anders aus. Nehmen wir an, Sie rufen die Webseite google.com auf. Dabei werden Cookies gesetzt. Dies ist faktisch so gegeben (Stand: 03.02.2021). Probieren Sie es selbst aus! Nun rufen Sie eine Webseite auf, die Google Maps einbindet. Diese lädt nun Dateien von google.com. Dabei werden die Cookies, die in Ihrem Endgerät gespeichert sind, beim Abruf der Datei von google.com an die Abrufadresse (google.com) übertragen. Die Karte lädt also Cookies. Der Cookie Scanner konnte diese Cookies nicht erkennen!
Dazu muss man wissen, dass jeder Nutzer weltweit potentiell andere Cookies auf seinem Endgerät (PC, Smartphone, Notebook, Tablet) gespeichert hat. Es ist unmöglich, diese alle zu kennen. Zum Google Tag Manager etwa wir oft erklärt, er sei eine cookielose Domäne. Das ist Bullshit. Sie finden weiter unten einen Link auf einen Bullshit Basics Artikel von mir dazu mir Beweis des Gegenteils. Auf meinem Endgerät sind serh wohl Cookies für die Domäne googletagmanager.com vorhanden und werden auf jeder Webseite, der den Tag Manager einbindet, übertragen. Dies ist ein einwilligungspflichtiger Vorgang.
Weitere Informationen zu Cookies finden Sie in meinem Grundlagen-Artikel.
3. Fehlendes Weltwissen
Angenommen, der vorige Punkt wäre erledigt, also, ein Cookie Scanner würde alle Cookies der Welt namentlich und inhaltlich kennen. Dies ist natürlich nicht der Fall, wie Sie mir zugeben werden, ohne lange darüber nachdenken zu müssen.
Nun müsste der Cookie Scanner zu jedem einzelnen Cookie den Zweck kennen. Woher kommt dieses Wissen? Nehmen wir an, Sie bieten einen Newsletter an. Außer Ihnen weiß niemand, wer die letzte Newsletter-Mail geschrieben hat. Nun soll der Empfänger der Newsletter-Mail erklären, wer diese Mail geschrieben hat. Offenbar ist das nicht möglich ohne Ihre unterstützenden Angaben.
Bei Cookies ist es ganz genauso: Verrät der Anbieter eines Tools, das bestimmte Cookies einsetzt, nichts zu den Zwecken der Cookies, ist eine Aussage für einen Dritten über die Zwecke dieser Cookies nicht möglich.
Artikel 13 DSGVO zwingt aber dazu, die Zwecke von Cookies zu erklären. Dies ist niemandem möglich, außer dem Anbieter der Cookies selbst. Für Google Tools ist oft feststellbar, dass der Anbieter, nämlich der Google Konzern, gar keine oder keine genauen Aussagen über den Zweck der Google-Cookies macht.
Fast alle Erklärungen, die Sie zu Drittpartei-Cookies in Datenschutzerklärungen oder auf Einwilligungsabfragen finden, sind erfunden oder gemutmaßt. Zum NID-Cookie erklärt Google etwa:
Das NID-Cookie enthält eine eindeutige ID, über die wir Ihre bevorzugten Einstellungen und andere Informationen speichern, wie beispielsweise Ihre bevorzugte Sprache, wie viele Suchergebnisse pro Seite angezeigt werden sollen (z. B. 10 oder 20) und ob der Google SafeSearch-Filter aktiviert sein soll.
Quelle: https://policies.google.com/technologies/cookies?hl=de
Das NID-Cookie wird nach meiner Untersuchung vorrangig dazu verwendet, um Nutzer eindeutig identifizieren zu können. So wird beispielsweise eine eindeutige Identifikation vergeben, nachdem Sie sich auf google.de angemeldet haben, um die Datenschutzbestimmungen nicht jedesmal neu bestätigen zu müssen. In der eben genannten Erklärung ist zudem von anderen Informationen die Rede. Diese Aussage ist an Unschärfe kaum zu überbieten und genügt den Anforderungen des Artikel 12 DSGVO nach transparenter und umfassender Information in keinster Weise.
Zu vielen anderen Cookies liefert Google gar keine Angaben, dennoch sind wie durch ein Wunder Angaben von Dritten hierzu zu finden. Die im Titelbild dieses Artikel genannte Aussage etwa liest man immer wieder. Ich konnte sie auf Webseiten des Google Konzerns nicht finden. Unabhängig davon ist die Aussage unverständlich und somit unwirksam.
Alles, was für Cookies gesagt wurde, gilt auch für Dienste (Tools). Cookies werden von Diensten erzeugt und verwaltet und entstehen nicht einfach so. Auch für Dienste müssen deren Zwecke erklärt werden. Auch hier weiß nur der Anbieter eines Dienstes über die genauen Datenverarbeitungen, Orte der Datenerhebung und Datenempfänger bescheid.
Die gesetzlich vorgeschriebene Nennung der Zwecke von Cookies ist für die Cookies der meisten bekannten Tools seriös nicht möglich
Objektive Festellung zu Cookie-Zwecken aufgrund logischer Herleitung
Zusätzlich zu den Zwecken sind weitere Angaben zu Cookies zu machen. Dazu gehört die Anbieterangabe. Wissen Sie, wenn "Google" mit "Google" meint, wenn "Google" in zahlreichen Datenschutzhinweisen und Nutzungsbedingungen von "Google" spricht? Bitte verraten Sie es mir. Unter diesem Beitrag befindet sich ein Kommentarfeld. Selbstverständlich muss der Verantwortliche einer Webseite diese Information für alle eingesetzten Dienste liefern können.
4. Cookies als zentrales Motiv
Nicht umsonst werden viele Consent Tools als Cookie Blocker oder ähnliches bezeichnet. Cookies sind nur ein Grund von mehreren Gründen, eine Einwilligung vom Nutzer einholen zu müssen. Die Rechtsgrundlage hierfür ist die ePrivacy Richtlinie, genauer gesagt, der Artikel 5 Absatz 3 dieser Richtlinie.
Ein weiterer Grund für eine Einwilligung ist das Prinzip der Datenminimierung. Praktisch bedeutet das: Bindet eine Webseite Google Schriften so ein, dass die Schriften von einem Google Server geladen werden, bedarf es dafür einer Einwilligung. Faktisch könnte die Schrift dann nicht verwendet werden. Die Abhilfe wäre einfach: Die Schrift lokal abspeichern und vom eigenen Server laden. Mit dem Google-Konzern kann man meines Wissens nach keinen gültigen AVV abschließen, der ein Einbinden von externen Google Schriften ohne Einwilligung rechtfertigen könnte.
Noch plastischer wird es beim Laden von YouTube Videos:
- Zahlreichen Dateien werden von den Domänen youtube-nocookie.com, ytimg.com und ggpht.com geladen
- Google Schriften werden von der Domäne gstatic.com geladen
- Der DoubleClick Werbe-Tracker wird von der Domäne doubleclick.net geladen
- YouTube sendet nach dem Laden der Seite Daten an einen Google-Server
- DoubleClick sendet in unbestimmten Abständen Daten an einen Google-Server
Dass dies ein vermeidbarer Datentransfer ist, wird jeder zugeben müssen. Das berechtigte Interesse scheidet hier also aus.
Nach dem EuGH-Urteil zum Privacy Shield dürfte es sich herumgesprochen haben, dass der Datentransfer in die USA und andere unsichere Drittländer selbst mit Hilfe von Standardvertragsklauseln oder Corporate Binding Rules nicht abgesichert werden kann.
Cookie-zentrierte Einwilligungslösungen fragen anscheinend häufig nur nach einer Einwilligung für Cookies. Der Nutzer soll aber doch in Dienste einwilligen. Google Analytics beispielsweise setzt in vielen Konfigurationen drei Cookies. Es macht doch keinen Sinn, nach einer Einwilligung für diese drei Cookies zu fragen. Richtig wäre es, nach einer Einwilligung für dein Einsatz von Google Analytics zu fragen. Zu diesem Dienst wird dann erklärt, dass er drei Cookies einsetzt. Diese Detailangabe kann auf einer späteren Ebene erfolgen.
Das Bild zeigt drei Cookies, die dem Google Tag Manager zugeordnet werden. Diese Zuordnung ist falsch. Der Tag Manager wird hier als Anbieter genannt, nicht als Dienst. Die tatsächliche Anbieternennung fehlt offensichtlich. Die Zuordnung ist falsch, weil der Tag Manager andere Dienste tunnelt und somit auch deren verwaltete Cookies.
Jedenfalls wird nirgends eine Abfrage gemacht, ob der Nutzer Google Analytics akzeptiert oder nicht. Zu diesem Tool wird der Zweck in der Consent Abfrage nicht gegeben. So ist eine informierte Einwilligung nicht möglich. Besonders schon sieht man den Fehler in der Cookie-Zentrierung bei eingebundenen YouTube Videos. Wer die Cookies erklärt, die bei der EInbindung des zugehörigen YouTube Scripts gesetzt werden, hat den Zweck des YouTube-Scripts nicht erklärt. Man kann das sehr schön dadurch beweisen, dass das YouTube Script auch ohne Cookies geladen werden kann.
5. Der fehlende Datenschutz-Ansatz
Vielen ist bekannt, dass neben der Einwilligungsabfrage auch die Datenschutzerklärung wichtig ist. An das SSL-Zertifikat denken vielen ebenfalls, zumal es oft im Web Hosting Tarif enthalten ist. Die Weiterleitung beim Aufruf einer Webseite ohne https auf die SSL-Version vergessen manche.
Der Link auf die Datenschutzerklärung ist bei einer erheblichen Anzahl an Webseiten, ich schätze, es sind 75%, nicht auf jeder Seite der Homepage vorhanden.
Viele binden YouTube Videos immer noch so ein, dass dabei Cookies ins Spiel kommen. Dies muss nicht sein, weil die Abhilfe einfach ist.
All diese Punkte und noch einiges mehr werden von Consent Tools nicht berücksichtigt, sinder aber aus rechtlichen Gründen wichtig.
Fazit
Wie anfangs angekündigt, konnte ich folgendes zeigen und auch beweisen:
- Der Ladevorgang von einwilligungspflichtigen Tools kann nicht zuverlässig unterbunden werden
- Tools, die keine Cookies einsetzen, können nicht zuverlässig durch eine Automatik erkannt werden. Keines der mir bekannten Consent Tools unternimmt hier einen nennenswerten Versuch, wahrscheinlich aus Angst, eine Datei zu blockieren, die für die Webseite funktionell wichtig ist
- Jeder von Ihnen hat andere Cookies auf seinem Endgerät gespeichert. Keiner der weit verbreiteten Cookie Scanner kann herausfinden, welche das sindCookies können nicht zuverlässig erkannt und somit nicht rechtssicher gehandhabt werden
- Die Zwecke von Diensten und Cookies sind für die meisten populären Tools nicht rechtssicher bekannt
- Ein Fokus auf Cookies in der Einwilligungsabfrage ist falsch
- Für Webseiten gibt es zahlreiche weitere Vorschriften neben der Einwilligungsthematik
Meine Empfehlung: Vermeiden Sie Einwilligungsabfragen soweit wie möglich. Hier eine kurze Hilfestellung (genauer ist es in meinen anderen Beiträgen beschrieben):
- Weglassen von nicht wirklich benötigten Tools
- Ersetzen von Tools wie Google Maps u.a. durch Alternativen
- Google Maps: Button "Route planen"
- Google Analytics: Matomo
- YouTube oder Vimeo Video: lokales Video oder Vorschaubild mit Absprung auf Videoplattform
- Google reCAPTCHA: Andere Lösung, etwa WordPress Plugin für Contact Form 7
Auch interessant
- Checkliste für Cookie Popups
- Cookiegeddon: Praxistest populärer Einwilligungslösungen
- Alternative für Google Tools
- Bullshit Basics: Cookies sind keine Textdateien
- Bullshit Basics: Der Google Tag Manager nutzt selber Cookies
Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. In IT & 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 Ihre 
> Dass Consent Tools an sich unzuverlässig sind, beweist dieser Beitrag.
Ja, aber! 🙂
Also völlig einverstanden mit der Aussage, dass die Scanner, dank derer sich die Tools selbst konfigurieren sollen, keinen verlässlichen Schutz bieten, weder für Seitenbetreiber noch für Nutzer. Jetzt das „Aber“: Man kann Consent Manager durchaus so entwickeln und in Seiten integrieren, dass sie Kommunikation wirksam unterbinden. Korrekt muss es heißen, dass die Kommunikation erst nach Einwilligung gestartet wird. Haben wir (Internet-Agentur) so gemacht und funktioniert. Ist aber nicht trivial. Ich habe auch schon ein Borlabs so konfiguriert, dass es die Kommunikation wirksam unterbindet. Aber man muss eben schon wissen was man macht.
tl;dr: Die Werbung für die Blocker verspricht mehr, als sie halten. Nein! Doch! Oh! Aber wenn man weiß was technisch passiert kann man mit manchen davon schon arbeiten.
Danke für Ihre Rückmeldung! Es stimmt, dass man die Ladevorgänge (Sie nennen es "Kommunikation") wirksam unterbinden kann, wenn man diese nämlich gar nicht erst aktiv deklariert, sondern passiv. Wer weiß, worum es geht, dem sagt data-src etwas.
Ich muss Sie allerdings enttäuschen, was Borlabs und andere "Verdächtige" angeht: Vor allem Borlabs ist gänzlich ungeeignet, zu einer rechtssicheren Webseite zu verhelfen. Das, was von Borlabs übrig bleibt, wenn man alles "richtig" gemacht hat, was Borlabs nicht hinkriegt, ist so wenig, dass man gleich das von mir auf dieser Webseite frei bereitgestellte Consent Tool nehmen kann.
Es geht außerdem nicht nur um Ladevorgänge ("Kommunikation"), sondern um weitere rechtliche Vorgaben, die den meisten in Teilen unbekannt sind, inklusiven dem Anbieter von Borlabs.
Die Werbung der Blocker-Anbieter ist eben nur Werbung, sie stimmt also meistens nicht.
Schliesse mich Tim an.
Mein Cookiebanner gibt den betroffenen code erst in die Seite, wenn zugestimmt wurde. Davor ist es, als wäre der code nie auf der Seite gewesen (weil er es nicht war).
Trotzdem ist das ganze besonders für Anfänger oder zb WordPress-Nutzer eine Falle.
Danke für den informativen Beitrag!
Danke für Ihre Rückmeldung-
Zu "Mein Cookiebanner gibt den betroffenen code erst in die Seite, wenn zugestimmt wurde. Davor ist es, als wäre der code nie auf der Seite gewesen (weil er es nicht war).":
Das funktioniert nur, wenn der Cookiebanner entweder den kompletten einwilligungspflichtigen Code generisch lädt (womit viele überfordert sind) oder wenn nur Tools geladen werden, die vom Cookiebanner konkret und vor allem rechtskonform unterstützt werden (konkret: wird nie für alle relevanten Tools umfassend der Fall sein; rechtskonform: da sage ich: das wird ist recht unwahrscheinlich.