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 ergibt keinen Sinn, nach einer Einwilligung für diese drei Cookies zu fragen. Richtig wäre es, nach einer Einwilligung für den 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, sind aber aus rechtlichen Gründen wichtig.
Extra: 5+1: Widerruf oft nicht möglich
Technische Third-Party Cookies sind Cookies, die in einer Domäne eines Tool-Anbieters existieren, die ungleich der besuchten Webseite ist. Der Website-Betreiber hat technisch keine Einflussmöglichkeit auf die Drittpartei-Domäne. Somit können Cookies in dieser Domäne nur genau dann abgeräumt werden (Widerruf des Besuchers einer Website!), sofern der Tool-Anbieter hierfür eine Schnittstelle anbieten. Oft gibt es diese Schnittstelle nicht. Somit ist der Widerruf objektiv nicht möglich. Sofern ausnahmsweise die Widerrufs-Schnittstelle vom Tool-Anbieter angeboten wird, müsste sie explizit vom Verantwortlichen (Website-Betreiber) aufgerufen werden. Das passiert allerdings in den wenigen möglichen Fällen leider so selten, dass kaum darüber gesprochen werden muss.
Beispiel: YouTube Video-Plugin (angeblich ohne Cookies mit der Domäne youtube-nocookie.com). Das Plugin setzt entgegen des Domänennamens ein Cookie namens CONSENT. Dieses Cookie kann nur vom Anbieter von YouTube selbst abgeräumt werden. Soweit mir bekannt ist, bietet YouTube dafür aber keine Schnittstelle an. Somit kann das YouTube Video Plugin nicht rechtskonform eingesetzt werden, weil der Widerruf gemäß Art. 7 Abs. 3 DSGVO nicht möglich ist. Dass der YouTube Player einwilligungspflichtig ist, hat neben dem Cookie weitere Gründe.
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
Kernaussagen dieses Beitrags
Cookie-Popups funktionieren nicht zuverlässig, weil Browser Dateien gleichzeitig laden und das Consent-Script daher nicht immer rechtzeitig eingreifen kann, um die Einbindung von Cookies zu blockieren.
Viele Tools, die den Datenschutz auf Webseiten verbessern sollen, funktionieren nicht zuverlässig, weil sie sich zu sehr auf das Blockieren von Cookies konzentrieren.
Cookie-Scanner können nicht alle Cookies erkennen und wissen auch nicht immer, wofür sie verwendet werden.
Der Text kritisiert, dass viele Webseiten Daten von Google-Diensten wie Schriftarten oder YouTube-Videos ohne Einwilligung der Nutzer einbinden und dabei Datenschutzbestimmungen verletzen.
Viele Cookie-Einwilligungslösungen funktionieren falsch, weil sie nur nach Einverständnis für Cookies fragen, nicht aber für die Dienste, die diese Cookies verwenden.
Es ist schwierig, Einwilligungen für Cookies richtig einzuholen, da es viele verschiedene Arten von Cookies gibt und es keine zuverlässigen Methoden gibt, sie zu erkennen und zu verwalten.
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. Ich stehe für pragmatische Lösungen mit Mehrwert. Meine Firma, die 
> 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.
Das bedeutet also freies Schussfeld für Abmahner, weil praktisch jeder Webseitenbetreiber gegen die DSGVO verstößt?
Ja, aber die Abmahnung wird meistens nicht erfolgreich sein, aus folgenden Gründen:
1) Massenabmahnung ist rechtsmissbräuchlich und wird somit schnell rechtswidrig
2) Auch eine normale Abmahnung gegen DSGVO-Verstöße wie Web Tracking hat (je nach Gericht und Bundesland) wenig Aussicht auf Erfolg, selbst wenn sie gerechtfertigt ist.
Im Wettbewerbsrecht oder bei Klagen durch Verbraucherverbände sieht es anders aus. Da sind die Chancen sehr gut.
Leider haben deutsche Datenschutzbehörden im Schnitt anscheinend wenig Lust oder Möglichkeiten, gegen deutsche Webseiten vorzugehen, die rechtswidriges Web Tracking betreiben, etwa indem sie Google Analytics rechtswidrig einsetzen.