Einleitung

In diesem Blog wurde schon viel über sogenannte Cookie Tools geschrieben. Synonyme sind Cookie Popup, Cookie Dienst, Cookie Banner oder Cookie Bar. Alle Synonyme sind unberechtigt. Es geht nicht nur um Cookies, sondern um einwilligungspflichtige Datenverarbeitungen. Hierzu zählen insbesondere:

• Nutzerprofilbildung („Tracking“).
• Übermäßige Datenverarbeitungen zu Lasten des Nutzers, für die das Interesse des Website-Betreibers nicht berechtigt ist.
• Datentransfer in unsichere Drittländer (die USA sind weiterhin ein Geheimdienststaat, auch wenn manche in der EU das anders sehen).
• Nicht erforderliche Cookies.
• Nicht erforderliche sonstige Endgerätezugriffe, wie etwa durch JavaScript (siehe Viewport-Abfrage in Google Analytics).
• Nicht erforderliche Zugriffe auf Endeinrichtungen, beispielsweise unnötige Updates auf Smart Home Geräten (inkl. Auto-Navigationssystemen)

Cookie Tools sollen eine Einwilligung abfragen. Der Begriff Consent Tool wäre besser. Consent bezeichnet die Einwilligung des Website-Besuchers.

Als Zusatzfunktion mit meist negativer Wirkung bieten viele Consent Tools einen sogenannten Cookie Blocker an. Die Idee ist folgende:

1. Ein Webmaster hat keine Ahnung von Datenschutz.
2. Er oder sie ballert seine oder ihre Webseite mit Tools zu, die nicht rechtskonform und erst recht nicht ohne Einwilligung betrieben werden können.
3. Nun bindet der Webmaster ein Consent Tool mit Cookie Blocker ein.
4. Der Cookkie Blocker deaktiviert alle bösen Plugins, bis der Nutzer seine Einwilligung gegeben hat. Danach reaktiviert der Blocker die bösen Plugins, die oft immer noch böse sind.
5. Alles ist gut.

Das Problem mit Cookie Blockern

Soweit die Welt der Träume. Böse Plugins wie Google Analytics sind rechtlich nicht beherrschbar. Der Grund ist die völlig unklare Datenverarbeitung, die bei Google stattfindet. Das gilt auch für einige populäre Dienste anderer Anbieter. Selbst mit Einwilligung sind solche Dienste nicht rechtskonform nutzbar.

Der Cookie Blocker überspringt dieses Problem mit den nicht rechtskonform nutzbaren Diensten und widmet sich dem anderen Problem, dass Dienste bis zu einer Einwilligung unterdrückt werden sollen. Viele Website-Betreuer sind entweder nicht versiert genug oder haben keine Lust, Plugins erst zu laden, wenn diese geladen werden dürfen. Stattdessen binden sie die Plugins einfach ein und warten darauf, dass der Cookie Blocker diese Plugins blockiert, bis eine Einwilligung für diese Plugins über das Cookie Popup eingeholt wurde.

Dass es technisch objektiv nicht zuverlässig möglich ist, Plugins durch Cookie Blocker zu blockieren, habe ich mehrfach beschrieben. Hier gibt es keinen weiteren Klärungsbedarf.

Neuerdings (mindestens seit einigen Monaten) werden viele Cookie Tools von datenschutzfreundlichen Browsern oder Ad Blockern selbst als kritisch angesehen. Das führt dazu, dass diese Cookie Tools selbst blockiert werden.

Hier sehen Sie einen Screenshot meiner Bausparkasse Schwäbisch Hall:

Der Screenshot ist nicht nachbearbeitet. Genau so sieht es aus, wenn man die Webseite der Schwäbisch Hall aufruft.

Schade, dass die Schwäbisch Hall mir keine Option anbietet, nichts zu akzeptieren. Stattdessen werde ich genötigt, auf „Weitere Optionen“ klicken zu müssen.

Nach Klicken auf „Weitere Optionen“ erscheint folgende Ansicht bei der Schwäbisch Hall:

Der Screenshot ist nicht nachbearbeitet. Ich nutze einen Standard-Firefox Browser in aktueller Version mit Standard Ghostery Werbeblocker, nachdem frühere Besuche der Webseite ohne Werbeblocker zu für mich unerwünschten Datenverarbeitungen geführt hatten.

Nun habe ich genau eine Option: Die Webseite wieder schließen. Da ich diese Webseite nur aufrief, um die per Mail von Schwäbisch Hall angekündigten Kundendokumente einzusehen, muss ich leider einen anderen Weg suchen.

Hätte die Schwäbisch Hall eine Ablehnen-Funktion auf erster Ebene der Einwilligungsabfrage angeboten, so wie es rechtlich notwendig ist, wäre das Problem, dass die Webseite unbedienbar ist, wahrscheinlich nicht entstanden. Allerdings hätte ich schon gerne gewusst, wofür ich eigentlich meine Einwilligung geben soll.

Nach Anruf bei der Schwäbisch Hall wurde mein Anliegen weiter aufgenommen und wird an die Technikabteilung weitergegeben, die sich dann bei mir melden würde. Ich erhielt auch die Belege, die für mich nicht online abrufbar waren, per Post. Für mich bedeutet das Mehrarbeit: Scannen von Dokumenten, Herumschlagen mit den Fehlern anderer, usw.

Ich werde der Schwäbisch Hall bei fruchtlosem Verlauf anbieten, unsere Geschäftsbeziehung mit Ausgleich von nicht in Anspruch genommener Leistungen zu beenden. Die Schwäbisch Hall fragte mich per Post nach meiner Systemkonfiguration. Sie könne das Verhalten der Webseite technisch nicht nachvollziehen. Ich hatte zuvor Screenshots geschickt.

Allerdings ist „Weitere Optionen“ keine Ablehnen-Funktion, sondern zunächst eine Informationsinformation. Ein Ablehnen auf erster Ebene des Consent Layers hätte das Problem direkt für mich gelöst. Dass die Technikabteilung selbst nach meinem Hinweis auf den Einsatz eines Werbeblockers mein Problem (angeblich) nicht nachvollziehen konnte, halte ich für schwierig und wenig Kunden-zentriert. Dass die Webseite ohne Werbeblocker nicht nutzbar ist, ohne Datenschutzfragen hervorzurufen, ist ein weiterer Punkt, der fragwürdig ist.

Nebenbei bemerkt

Was passieren kann, wenn Technik und Recht aufeinanderprallen und Zuständigkeiten und Kompetenzen unklar sind, sieht man regelmäßig auf Webseiten von Online Journalen. Zu nennen sind beispielsweise Welt online und die Kieler Nachrichten, die auch über deutschlandweit relevante Themen berichten. So begegnet dem naiven Internet-Nutzer wie Ihnen und mir folgende Arabeske:

1. Sie rufen die Webseite der Welt oder der Kieler Nachrichten auf, um einen Artikel zu lesen.
2. Sie werden gefragt, ob Sie Werbung ertragen möchten, um den Artikel werbefinanziert lesen zu können, oder ob Sie ein Abo kaufen möchten, um den Artikel gegen Geld lesen zu können.
3. Sie entscheiden sich für Werbung.
4. Der Artikel erscheint nicht. Stattdessen sehen Sie das Titelbild des Beitrags und einen ganz kurzen Anreißer-Text.
5. Es folgt eine Aufforderung, ein Abo gegen Geld abzuschließen.

Sie werden also in Werbung reingetrickst, um dann den Artikel nicht lesen zu können, außer, Sie wollen Geld bezahlen. Warum fragen Welt und Kieler Nachrichten dann nicht direkt nach Geld anstatt nach Werbung und dann nach Geld? Zwei Antwortmöglichkeiten sehe ich:

1. Welt und Kieler Nachrichten sind inkompetent, eine rechtskonforme Webseite bereitzustellen.
2. Welt und Kieler Nachrichten wollen erst Geld mit Werbung verdienen und dann Geld mit einem kostenpflichtigen Abo.

Vielleicht möchten Sie zukünftig ja auch lieber andere Magazine als die Welt und die Kieler Nachrichten lesen, nämlich solche, die respektvoll mit Leserinnen und Lesern umgehen und deren Privatsphäre achten.

Fazit

Datenschutzfreundliche Browser wie Brave oder Mullvad blockieren zahlreiche Cookie Popups. Der Werbeblocker uBlock Origin sorgt neben Ghostery ebenfalls oft dafür, dass Cookie Popups blockiert werden, die zurecht als nervig und kritisch betrachtet werden.

Wenn eine Einwilligungsabfrage wegen eines Werbeblockers oder datenfreundlichen Browsers nicht erscheint, ist dies kein Problem, solange keine Plugins genutzt werden, die die Einwilligung als Rechtsgrundlage benötigen würden. Dass dies nicht optimal für das Marketing ist, ist eine andere Frage. Weil aber Google Analytics sowieso von Werbeblocker blockiert, aber dennoch immer noch häufig (alleinig) eingesetzt wird, zeigt, dass einige Marketing-Abteilungen noch nicht in der Realität angekommen sind.

Der richtige Weg für einwilligungspflichtige Dienste ist auch aus Marketing-Sicht folgender:

1. Code für das jeweilige Plugin gar nicht oder deaktiviert einbinden. Deaktiviert einbinden geht über die Direktive data-src statt src im Script-Befehl.
2. Eine Einwilligungsabfrage lädt nach Einwilligung entweder den Code überhaupt erst oder aktiviert den deaktiviert ausgespielten Code, indem automatisch aus der Pseudo-Direktive data-src die vom Browser ausführbare Direktive src gemacht wird.

Ganz fortgeschrittene nutzen keine einwilligungspflichtigen Dienste. Hier ein paar Beispiele für datenschutzfreundliche Alternativen:

• Google Analytics → WP Statistics (für WordPress), Matomo oder eigenes Conversion Tracking (siehe diesen Blog)
• Google Maps → keine Karte, lizenzrechtlich einwandfreies Kartenbild, Button für Routenplaner oder datenschutzfreundliche interaktive Karte
• YouTube Video Plugin (oder Vimeo) → kein Video, Link auf Videoplattform oder lokaler Video-Player
• Facebook Pixel → kein Facebook
• SoundCloud → lokaler Audio-Player
• Cookie Tool mit geratenen Vorgaben → eigenes Cookie-Tool mit selbst eingegebenen Angaben

Wenn Sie unbedingt ein Consent Tool einsetzen wollen oder müssen, dann sollte es eines sein, welches idealerweise lokal abgelegt ist. Noch wichtiger ist allerdings, dass der Pseudo-Funktion des Cookie Blockers kein Vertrauen geschenkt wird und Plugins erst geladen werden, nachdem sie geladen werden dürfen. Etwas Einwilligungspflichtiges zu laden, was bis zum Vorliegen einer Einwilligung künstlich daran gehindert werden soll, zeugt von maximaler Verzweiflung oder inkompetenten Dienstleistern.

Wie eine Einwilligungsabfrage richtig umgesetzt wird oder ganz entfallen kann, zeigt die Übersicht Cookies und Einwilligung.

Einleitung

Das Bundesministerium für Digitales und Verkehr wünscht sich Rückmeldungen zur Zentralen Einwilligungsverwaltung für Telemedien. Schließlich hat der (damalige) Gesetzgeber diese Aufgabe in den § 26 TDDDG hineingeschrieben. Bereits jetzt möchte ich die erneute Gelegenheit nutzen, um klarzustellen, warum PIMS, wie die zentrale Einwilligungsverwaltung auch genannt wird, scheitern wird. Am 14. Mai 2024 ging das TTDSG in das TDDDG über.

Der § 25 TDDDG besagt, dass Endgerätezugriffe dann einwilligungsfrei sind, wenn sie erforderlich sind. Der Begriff „Cookie“ taucht dort nicht auf. In der Praxis sind Cookies nur ein Mechanismus, um auf das Endgerät des Nutzers zuzugreifen. Der Nutzer ist der Besucher einer Webseite oder Aufrufer einer App.

Wenn ein Cookie nicht einwilligungsfrei ist, muss eine Einwilligung abgefragt werden, bevor es gespeichert oder ausgelesen werden darf. Dies geschieht oft über einen Mechanismus, der als Cookie Popup oder Consent Abfrage bezeichnet wird. Die Regeln für Einwilligungen sind insbesondere in Art. 7 DS-GVO definiert.

Die sogenannten Cookie Popups stören jeden bis auf die Anbieter dieser auch als Cookie Tools bezeichneten Plugins. So kam es, dass im Zuge des Gesetzgebungsverfahrens zum TDDDG eine Regelung aufgenommen wurde, um Cookie Popups zu entschärfen. Dies soll über eine zentrale Einwilligungsverwaltung geschehen.

Die Grundidee der zentralen Einwilligungsverwaltung ist folgende:

1. Ein Nutzer besucht eine noch zu schaffende Möglichkeit (zentrale Einwilligungsverwaltung genannt). Dies könnte eine Webseite oder ein Browser-Plugin sein.
2. Dort hinterlegt der Nutzer seine Datenschutzvorlieben.
3. Nun besucht der Nutzer eine Webseite oder App oder auch mehrere.
4. Jede besuchte Webseite oder App fragt nun die Zentrale (siehe Punkt 1), was die Datenschutzeinstellungen des Nutzers sind.
5. Theoretisch kennt die besuchte Webseite oder App nun die vom Nutzer erteilten Einwilligungen und muss kein Cookie Popup mehr anzeigen.

Niemand weiß genau, wie das funktionieren soll. Auf meine Rückfragen bei diversen Stellen und unter Nennung der Problematik erhielt ich gar keine oder keine konkreten Antworten. Selbst ein vorliegendes Forschungsgutachten[1] bleibt Antworten schuldig. Daher verwundert es auch nicht, dass der Gesetzgeber im TDDDG nicht festgelegt hat, wie eine zentrale Einwilligungsverwaltung in der Praxis realisiert werden soll.

Beispielsweise funktioniert eine zentrale Einwilligungsverwaltung in Form einer Webseite nicht so gut in Auto-Assistenzsystemen, die eine Einwilligung abfragen. Smartphone Apps hingegen funktionieren nicht auf Desktop PCs. Browser-Plugins müssten für jeden halbwegs verbreiteten Browser speziell programmiert und permanent gewartet werden.

Der § 26 TDDDG enthält somit "nur" eine Vorschrift, wonach innerhalb von zwei Jahren eine Verordnung zu erlassen ist, die einer zentrale Einwilligungsverwaltung den Weg ebnen soll.

Oft wird die zentrale Einwilligungsverwaltung auch mit PIMS abgekürzt. PIMS ist eine neu eingeführte Abkürzung, die verschiedene Ausprägungen annehmen kann. Mal steht PIMS für Personal Information Management System, mal steht das "P" für "Privacy".

PIMS kann nach meiner Ansicht sowohl aus rechtlichen als auch als technischen als auch aus rein praktischen Gründen nicht funktionieren. Weiter oben wurden bereits fundamentale Probleme mit PIMS benannt. Einige weitere Gründe nenne ich nachfolgend.

Darnach folgen Empfehlungen, wie Webseiten in Position gebracht werden können, um möglichst wenig Probleme mit Cookie Popups oder Einwilligungsabfragen gleich welcher Art zu verursachen. Somit wird auch die Notwendigkeit entschärft, sich als Website- oder App-Anbieter mit PIMS tiefer befassen zu müssen.

Mein Beitrag schließt mit einem Fazit und einem Ausblick.

PIMS: Die zentrale Einwilligungsverwaltung, das Sorgenkind

PIMS ist und bleibt ein unlösbares Problem. Erstens geht es nicht nur um Cookies. Zweitens müssen Einwilligungen für konkrete Zwecke und informiert erfolgen. Ersteres ist ein Grund für das Versagen von PIMS. Letzteres geht aktuell für die meisten populären Plugins nicht, weil die Anbieter Datenkraken sind und es bleiben wollen.

Die eben genannten zwei Gründe sind nicht die einzigen, warum es mit PIMS nichts werden wird. Mehr erfahren Sie in den folgenden Abschnitten.

Cookies sind nur ein Teil der Wahrheit

Ein ungelöstes Problem, welches PIMS aufwirft, begegnet dem Leser in § 25 TDDDG. Der § 26 TDDDG, der PIMS den Weg ebnen soll, verweist nämlich auf § 25 TDDDG. Und dort ist nur von Endgerätzugriffen die Rede. Vielmehr thematisiert das TDDDG Endeinrichtungen.

Endeinrichtungen sind nicht nur Endgeräte, sondern auch alle Arten von netzwerkfähigen Geräten, wie etwa Multi Room-Lautsprecher oder vernetzte Sensoren.

Entscheidend ist aber etwas anderes:

In Art. 6 Nr. 1 DS-GVO sind die Rechtsgrundlagen für die Verarbeitung personenbezogener Daten geregelt. Das TDDDGals lex specialis greift vor der DS-GVO, wenn es um Cookies und andere Endgerätzugriffe geht, die beim Aufruf von Webseiten und Apps auftreten können.

Für § 25 TDDDG ist es irrelevant, ob die Cookie-Daten personenbezogen sind oder nicht.[2]

Die DS-GVO als lex generalis ist im § 26 TDDDG bezüglich der Rechtsgrundlagen der Datenverarbeitung gar nicht berücksichtigt. Das ist fatal, denn jede Art von Cookie kann auch bezüglich der DS-GVO relevant sein.

Das TDDDG reglementiert also die Speicherung von Cookies und das Auslesen dieser. Die DS-GVO kommt danach und regelt die Verarbeitung von aus Cookies ausgelesenen Werten. Diese Werte sind oft personenbeziehbar und somit personenbezogen[3]. Sind sie es nicht, dann sind nach meiner Ansicht Cookies aus folgendem Grund dennoch personenbeziehbar und somit personenbezogen.

Aus technischen Gründen wird beim Auslesen eines Cookies immer die Netzwerkadresse (IP-Adresse) des Nutzers mit an den Server übertragen, der den Cookie-Wert erhält. Die IP-Adresse ist selbst in dynamischer Ausprägung personenbezogen.[4]

Weil Cookies immer mit der personenbeziehbaren IP-Adresse übertragen werden, sind sie selbst auch personenbeziehbar und somit personenbezogen. Die zentrale Einwilligungsverwaltung nach § 26 TDDDG lässt diesen Umstand unberücksichtigt und widmet sich nur der Speicherung und dem Auslesen von Cookies, nicht aber dem Verarbeiten der ausgelesenen Cookie-Daten.

Selbst ohne Vorliegen eines Cookies können Datenverarbeitungen einwilligungspflichtig sein. Siehe hierzu beispielsweise das Urteil zu Google Fonts[5]. Das Urteil berücksichtigt Art. 44ff DS-GVO, den Datentransfer in unsichere Drittländer, zu denen auch die USA als Geheimdienststaat zählen.

Die in Art. 5 DS-GVO genannten Grundsätze der Datenverarbeitung legen nahe, dass eine überschwängliche Datenverarbeitung ebenfalls einer Einwilligung bedarf. Als Beispiel sei die Nutzerprofilbildung genannt.

Laut Erwägungsgrund 111 [6] zur DS-GVO sind bestimmte Einwilligungen zudem nur für gelegentliche Datenübermittlungen statthaft. Dieser Gelegenheitscharakter ist aber gerade bei Webseiten und Apps, die beliebig oft von beliebig vielen Personen aufgerufen werden (sollen) können, nicht gegeben.

In was willigt der Nutzer eigentlich ein?

Damit eine zentrale Einwilligungsabfrage sinnvoll ist, muss sie für möglichst viele Datenverarbeitungen eine Einwilligung abfragen. Genauer gesagt, werden Einwilligungen für Zwecke abgefragt. Auf Webseiten und Apps ergeben sich die Zwecke durch die eingesetzten Dienste. Ein Beispiel für einen Dienst ist Google Analytics.

Es erscheint schwierig und in der Praxis nahezu unmöglich, sämtliche möglichen Zwecke zu kennen und zu benennen, zu denen Google Analytics und auch alle anderen Webseiten-Dienste weltweit eingesetzt werden kann.

Dazu muss man wissen, dass beispielsweise Google Analytics nicht nur eine Reihe von Optionen und Funktionen anbietet (Remarketing, Conversion Tracking, Marketing Attribution…), sondern auch mit oder ohne Google Optimize zur Optimierung der Benutzeroberfläche verwendet werden kann und eine Reihe weiterer Variationspunkte und Konfigurationsmöglichkeiten bietet.

Eine Liste aller Dienste, die für Webseiten und Apps relevant sind, gibt es nicht. Somit sind auch die Zwecke dieser Dienste nicht bekannt. Laut Art. 6 Nr. 1 lit. a DS-GVO muss aber gerade der konkrete Zweck bekannt sein, für den eine Einwilligung erfragt wird. Auch Erwägungsgrund 32 zur DS-GVO liest sich so.

Diesen Umstand der Unkenntnis haben wohl auch diejenigen erkannt, die eine Verordnung für § 26 TDDDG auf den Weg bringen wollen (Lobbyisten) oder sollen (Gesetzgeber). Zudem stellt sich die Frage, was passiert, wenn ein Dienst derart vom Anbieter aktualisiert wird, dass sich seine Zwecke ändern oder erweitern. Auch könnte der Anbieter wechseln, etwa durch einen Aufkauf. Aus dem Land Irland als Firmensitz des bisherigen Anbieters könnten dann die USA als Firmensitz des neuen Anbieters werden.

Aufgrund der Unkenntnis dessen, für was eigentlich eine Einwilligung abgefragt werden soll, entstand der aus meiner Sicht verzweifelte Vorschlag, mit einer Generaleinwilligung zu arbeiten.  Statt in Dienste und Zwecke soll nun pauschal in Totschlagzwecke oder für alle Dienste großer Anbieter (wie beispielsweise Google) eingewilligt werden.

Zu den Anbietern sei nur gesagt, dass auch hier unbekannt ist, welche Anbieter von Diensten für Webseiten und Apps es weltweit gibt.

Die Totschlagzwecke könnten "Marketing" oder "Statistik" lauten. Selbst wenn man diesem Vorgehen, dass eine wohl rechtswidrige "Lösung" produzieren würde, folgen möchte: Auch hiermit gibt es rein logische Umsetzungsprobleme. Ein Nutzer könnte in einer Zentrale (PIMS) in alle Dienste einwilligen, die unter dem Begriff "Marketing" zusammenzufassen wären. Dann verschiebt sich das Problem der unbekannten Liste aller relevanten Dienste allerdings nur nach hinten.

Denn beim Besuch einer Webseite müsste die Webseite doch wissen, ob der Dienst "Google Tag Manager" der Kategorie "Marketing" zuzuordnen ist, der ein Nutzer vielleicht in PIMS zugestimmt hatte. Diese Festlegung gibt es aber nicht. Es ist unklar, wie eine solche Festlegung zustandekommen kann und wer sie vornehmen soll, sofern überhaupt möglich.

Widerruf einer zuvor erteilten Einwilligung

Noch deutlicher wird das Dilemma sichtbar, wenn es um den Widerruf einer zuvor erteilten Einwilligung geht. Jede betroffene Person hat nämlich laut Art. 7 Abs. 3 DS-GVO das Recht, "ihre Einwilligung jederzeit zu widerrufen".

Zuerst stellt sich die Frage, wo der Widerruf abzusetzen ist. Auf der gerade besuchten Webseite oder auf einer Zentralseite (PIMS genannt)?

Mit § 26 TDDDG sollten die Rechte betroffener Personen jedenfalls nicht schlechter gestellt sein als ohne diesen deutschen Sonderweg. Ansonsten wäre das Vorhaben wohl europarechtswidrig. Also muss der Widerruf einer zuvor erteilten Einwilligung mindestens auf der gerade besuchten Webseite möglich sein.

Doch was ist, wenn die Webseite Ihren Widerruf nicht oder falsch an die Zentrale weitergibt oder wenn es auf dem Weg zur Zentrale eine Kommunikationsstörung gibt? Dann könnte man darüber nachdenken, dass der Betreiber der Webseite, auf der ein Nutzer einen Widerruf abgesetzt habt, der in der Verantwortlichkeit des Website-Betreibers nicht korrekt zur Zentrale gelangte, für alle Folgeverstöße aufgrund des unberücksichtigten Widerrufs verantwortlich ist.

Schließlich könnte der Nutzer nach seinem nicht berücksichtigen Widerruf viele andere Webseiten besuchen. Diese Webseiten fragen dann die Zentrale ab und meinen, der Nutzer hätte eine Einwilligung erteilt. Jedoch hatte der Nutzer diese bereits widerrufen. Nur wurde der Widerruf des Nutzers in der Verantwortlichkeit der Webseite, auf der der Widerruf abgesetzt wurde, nicht berücksichtigt.

Wer sind Sie eigentlich?

Noch einmal: Die zentrale Stelle (PIMS), in der Nutzer Einwilligungen hinterlegen können sollen, gibt es noch nicht. Woher weiß PIMS eigentlich, wer Sie und ich sind bzw. wie kann PIMS Sie von mir unterschieden?

Soweit mir bekannt ist, hat bei weitem nicht jeder Deutsche einen digitalen Personalausweis samt Lesegerät, und zwar für jedes Endgerät: Smartphone, Tablet, Notebook, Desktop PC. Unabhängig davon wäre die Einführung eines deutschlandweiten elektronischen Identifikationsverfahrens ein Mammutprojekt, dessen Ausgang höchst zweifelhaft wäre.

Multiple Endgeräte

Wo wir gerade über Endgeräte sprechen: Ich nutze aktiv fünf Endgeräte. Da PIMS mich ja nicht näher kennt und es kein Endgeräte-übergreifendes Super-Cookie gibt, müsste ich für jedes meiner fünf Endgeräte die Zentrale aufrufen und jedesmal meine Datenschutzeinstellungen definieren. Sofern für PIMS ein Browser-Plugin verwendet werden würde, würde sich das Problem in meinem Fall auf ca. 15 einzelne Browser ausdehnen, die auf meinen fünf Endgeräten genutzt werden.

Die technische Meisterleistung

Eine zentrale Stelle, die Einwilligungen vieler Millionen deutscher Bürger verwaltet, muss technisch hochleistungsfähig sein. Jeder Bürger kann potentiell jeden Tag mehrmals auf die Zentrale zugreifen. Die PIMS-Plattform müsste also viele Millionen Zugriffe pro Tag verkraften.

Jede besuchte Webseite wiederum müsste bei jedem Seitenaufruf die Zentrale abfragen. Nur so kann erkannt werden, ob eine erteile Einwilligung immer noch vorliegt oder schon widerrufen wurde. Dadurch kommen sicher einige Milliarden Zugriffe pro Tag auf die PIMS-Plattform zustande.

Wie dies technisch stabil und wirtschaftlich realisiert werden soll, ist ungewiss.

Die Verfügbarkeitsfrage

Eine so wichtige Plattform wie PIMS wird zudem zahlreichen Angriffen ausgesetzt werden, darunter DDoS-Attacken (Distributed Denial of Service). Sollte die PIMS-Zentrale wegen einer solchen Attacke oder aufgrund technischer Fehler einmal nicht erreichbar sein, wären somit sämtliche erteilten Einwilligungen deutscher Bürger nicht mehr sichtbar. Jede Webseite und App müsste also davon ausgehen, dass keine einzige Einwilligung erteilt wurde.

Aktuell arbeiten viele kommerzielle Webseiten mit sogenannten Paywalls. Bezahlen mit Geld oder bezahlen mit Daten, ist hier das Motto. PIMS konterkariert diese Paywalls. Die Anbieter dieser über Bezahlfunktionen monetarisierten Webseiten sind also auch nicht für PIMS.

Neben diesen bereits erheblichen Gründen habe ich zahlreiche weitere Gründe zusammengetragen, die den § 26 TDDDG als praktisch nicht umsetzbar erscheinen lassen.

Empfehlungen für Webseiten und Apps

Viele Webseiten und Apps könnten schon jetzt ganz ohne Einwilligungsabfrage auskommen. Dass dennoch die oft als nervig empfundenen "Cookie Popups" eingesetzt werden, hat nach meinem Dafürhalten vor allem folgenden Gründe:

• Komplexes Spannungsfeld Technik und Datenschutzrecht
• Unwissenheit
• Falsche Beratung
• Gegenläufige Interessen von Marketing-Mitarbeitern und -Agenturen

Zu den genannten Punkten ein paar Beispiele:

Wenn keine einwilligungspflichtigen Datenverarbeitungen stattfinden, wird keine Einwilligungsabfrage benötigt. Statt Google Analytics kann Matomo als sehr guter Besucherzähler mit vielen Extras verwendet werden. Richtig konfiguriert, benötigt Matomo keine Einwilligung und liefert 100% der Daten, anstatt nur einen Bruchteil eingewilligter Datenerhebungen (wie bei Google Analytics). Allerdings scheint es für manche Internetagentur einfacher zu sein, dem Kunden Google Analytice vorzuschlagen anstatt sich technische Expertise anzueignen.

Selbst Conversion Tracking und Marketing Attribution-Funktionen können ohne Google Analytics realisiert werden. Bei einem Werbe-Budget von mehreren Tausend Euro sollte auch etwas Geld für einen Programmierer vorhanden sein, der beim datenschutzfreundlichen Ausgestalten der Webseite hilft.

Statt dem Google Maps-Plugin tut es oft ein Button mit der Beschriftung "Anfahrt planen". Wer unbedingt eine interaktive Karte braucht, der findet hier meine einwilligungsfreie Lösung auf Basis von OpenStreetMap (OSM): Die Karte gibt im Gegensatz zum OSM-Standard nutzerbezogenen Daten nicht weiter.

Videos-Plugin von YouTube oder Vimeo können durch ein Vorschaubild mit Link auf die Videoplattform ersetzt werden. Kleine Videos mit eigener Urheberschaft können lokal eingebunden werden. Alternativ kann dort, wo das Video erscheinen soll, eine Einwilligung abgefragt werden. Eine globale Abfrage muss hierfür nicht sein.

Fazit

Eine zentrale Einwilligungsverwaltung, wie sie der § 26 TDDDG vorsieht, ist aus zahlreichen Gründen unterschiedlicher Art zum Scheitern verurteilt.

Selbst wenn die rechtlichen Probleme beseitigt werden sollten, würde dies nicht vor Ende 2023 stattfinden. Auch mögliche entschärfte Rahmenbedingungen sind noch unklar. Bis Ende 2023 aber soll die PIMS-Verordnung vorliegen.

Zudem heilen rechtliche Winkelzüge, die aus meiner Sicht einer Verschlimmbesserung der DS-GVO gleichkämen, die anderen technischen und praktischen Probleme nicht, die PIMS als völlig unrealistisch erscheinen lassen.

Eine zentrale Einwilligungsverwaltung löst zudem die Datenschutzprobleme nicht, die jetzt auf Webseiten und Apps vorhanden sind.

Für Betreiber von Webseiten und Apps kann die Empfehlung also nur lauten, ein so gutes Datenschutzniveau wie möglich herzustellen und sich mit PIMS bis auf Weiteres nicht zu beschäftigen.

Weniger Cookie-Popups lassen sich vor allem dadurch erreichen, dass Webseiten und Apps weniger Cookie-Popups verwenden. Hierfür stehen zahlreiche Funktionen in Form datenschutzfreundlicher Dienste zur Verfügung.

Solange es keine zentrale Lösung gibt, gelten die bekannten Regeln. Einen Überblick gibt die Seite Cookies und Einwilligung auf Websites.

Lesen Sie meine 66 Gründe, die gegen die Realisierbarkeit von PIMS sprechen:

PIMS nach § 26 TDDDG kann nur einer wollen, und das ist jemand, der gerne einen Dienst verkaufen möchte, der ohne wesentlichen Nutzen ist. Oder es ist jemand, der maximale Verwirrung stiften möchte, um Datenschutz noch mehr zur Randerscheinung werden zu lassen.

Wenn Sie etwas gegen Datenschutzsünder haben, dann fangen Sie doch mal mit einem Auskunftsgesuch gegen Webseitenbetreiber an, die Ihre Daten ungefragt weitergeben.

[1] Stiemerling, Oliver/Weiß, Steffen/Wendehorst, Christiane: Forschungsgutachten zum Einwilligungsmanagement nach § 26 TTDSG. Studie im Auftrag des Bundesministeriums für Wirtschaft und Energie, 16.12.2021

[2] Vgl. § 25 TDDDG sowie EuGH-Urteil vom 01.10.2019 – C-673/17 – „Planet49“, siehe Urteilsdatenbank

[3] Vgl. Art. 4 Nr. 1 DS-GVO.

[4] Vgl. EuGH-Urteil vom 19.10.2016 – C-582/14 und BGH-Urteil vom 16.05.2017 – VI ZR 135/13 – „Breyer“, siehe Urteilsdatenbank

[5] LG München, Urteil vom 20.01.2022 – 3 O 17493/20, siehe Urteilsdatenbank

[6] Der Erwägungsgrund 111 lautet: "Datenübermittlungen sollten unter bestimmten Voraussetzungen zulässig sein, nämlich wenn die betroffene Person ihre ausdrückliche Einwilligung erteilt hat, wenn die Übermittlung gelegentlich erfolgt und im Rahmen eines Vertrags oder zur Geltendmachung von Rechtsansprüchen, sei es vor Gericht oder auf dem Verwaltungswege oder in außergerichtlichen Verfahren, wozu auch Verfahren vor Regulierungsbehörden zählen, erforderlich ist. Die Übermittlung sollte zudem möglich sein, wenn sie zur Wahrung eines im Unionsrecht oder im Recht eines Mitgliedstaats festgelegten wichtigen öffentlichen Interesses erforderlich ist oder wenn sie aus einem durch Rechtsvorschriften vorgesehenen Register erfolgt, das von der Öffentlichkeit oder Personen mit berechtigtem Interesse eingesehen werden kann. In letzterem Fall sollte sich eine solche Übermittlung nicht auf die Gesamtheit oder ganze Kategorien der im Register enthaltenen personenbezogenen Daten erstrecken dürfen. Ist das betreffende Register zur Einsichtnahme durch Personen mit berechtigtem Interesse bestimmt, sollte die Übermittlung nur auf Anfrage dieser Personen oder nur dann erfolgen, wenn diese Personen die Adressaten der Übermittlung sind, wobei den Interessen und Grundrechten der betroffenen Person in vollem Umfang Rechnung zu tragen ist."

Alle Bilder in diesem Beitrag wurden von einem Computer-Programm erzeugt. Verwendet wurde das selbst entwickelte KI-System von Dr. DSGVO, ähnlich zu Midjourney. Die Bilder dürfen auf Webseiten frei verwendet werden, mit der Bitte, eine Verlinkung auf diesen Blog zu setzen.

Einleitung

Die meisten Webseiten haben im Wesentlichen eine Funktion: Sie sollen vorhanden sein, halbwegs gut aussehen und Informationen bereitstellen oder Waren und Dienstleistungen aufzeigen. Wenn man von Online Shops und anderen funktionell eher schwergewichtigen Webseiten absieht, ist es aus meiner Sicht sehr einfach, eine datenschutzkonforme Webseite zu betreiben.

Auch für diejenigen, die Marketing-Maßnahmen vorsehen, um Ihre Website nach vorne zu bringen, bietet dieser Beitrag einige Denkanstöße und Lösungsmöglichkeiten. Nicht immer muss es Google Analytics sein. Oft sogar ist dieses als Super-Analyse-Tool angesehene Produkt kontraproduktiv.

Die Basis der Webseite: Das Hosting

Der erste Schritt ist fundamental wichtig. Er besteht darin, sich eine Heimat für die eigene Webseite zu suchen. Hier sehe ich als beste Möglichkeit genau eine an: einen rein deutschen Provider und keinen Homepage-Baukasten.

Rein deutscher Provider

Der Anbieter des Web-Space sollte seinen alleinigen Firmensitz in Deutschland haben. Andere Länder der EU sind natürlich auch möglich. Naturgemäß kennt sich der einheimische Bürger mit einheimischen Gesetzen und Vorschriften aber besser aus. Auch der Gerichtsstand im eigenen Land hilft bei Streitigkeiten unkomplizierter weiter als eine Reise ins Ausland.

Alleiniger Firmensitz in Deutschland bedeutet, dass es keine Mutter- oder Tochterfirmen im Ausland gibt. Das wäre der Idealzustand, der vorzufinden ist. Meine Empfehlung gilt ALL-INKL. Um es direkt zu sagen: Ich bin kein Fan von Strato und 1 & 1. Bei Strato war (ist?) der Support nicht besonders gut erreichbar (schlecht aber auch nicht). Man bezahlt bei Strato für leere Pakete, nachdem man eine Domäne einmal gekündigt hat. Bei 1 & 1 stört mich einiges anderes. Dazu gehören eine teils intransparente Preispolitik sowie Standardprodukte, die nach einiger Zeit vom Markt verschwinden sowie Marketing-Mails in größerer Anzahl samt ungefragten Anrufen. Bei ALL-INKL hatte ich mehrfach Nachfragen auf höherem Niveau. Die Antwort kam jeweils in Lichtgeschwindigkeit und in sehr hoher Qualität.

Auch der Serverstandort sollte alleinig in Deutschland sein. Für alle Jetzt-schon-Meckerer: Wer Europa- oder weltweit Nutzer einsammeln möchte, kann über ein CDN nachdenken, aber bitte nicht Cloudflare, AWS oder ähnliches.

Echte Webseite, kein Homepage-Baukasten

Ein Homepage-Baukasten erleichtert die Arbeit anfangs. Er stellt eine Black Box mit diversen Funktionen bereit. Dadurch können viele eine Webseite bauen, die technisch nicht besonders versiert sind.

Viele Homepage-Baukästen, auch solche von deutschen Anbietern, weisen Datenschutzmängel auf. Diese Mängel können nicht abgestellt werden. Somit scheiden diese Baukästen bereits von Anfang an für denjenigen aus, der keine Datenschutzprobleme haben möchte.

Nutzen Sie ein Content Management System wie WordPress. Viele Provider bieten eine Installation mit einem Klick an. Buchen Sie sich einen Profi, der Ihre Webseite ordentlich einrichtet. Was ich oft tue: Den Kunden nach seinem Wunschdesign fragen, eventuell hat er ja ein Beispiel. Dann dem Kunden mehrere Vorlagen zeigen, aus denen er jeweils die für ihn passenden Elemente auswählen kann. Daraus entwickle ich dann eine WordPress-Vorlage, die das individuelle Design für den Kunden enthält.

Diese Anfangsinvestition zahlt sich später aus. Die Kosten für einen Homepage-Baukasten sind eigentlich immer höher als der Eigenbetrieb eines Servers. Zudem bietet ein eigener Server weitere Möglichkeiten für zukünftige Projekte und Anwendungen. Wie wäre es beispielsweise mit einem Video-Plugin auf Ihrer Webseite, gestreamt von Ihrem Server und ganz ohne die Datenfeinde YouTube und Vimeo?

Bestandswebseiten

Wer schon eine Webseite hat, sollte diese einem umfangreichen Test unterziehen, dem Website-Check. Einen guten Start bietet mein Online Webseite-Check:

Der Check ist kostenfrei, im Gegensatz zu Angeboten wie der DATEV Website-Analyse (die wahrscheinlich weniger kann als meine Checks; zumindest sehe ich auf der Website mit dem DATEV Angebot diverse mögliche Datenschutzproblemchen).

Mein Check fragt nicht nach Ihrem Daten (außer der Adresse der Webseite natürlich) und zeigt nach wenigen Sekunden das Diagnoseergebnis an. Wer eine größere Webseite betreibt, kann für wenig Geld einen Volkstarif-Check erwerben und damit seine Webseite in größerem Umfang so oft scannen, wie nötig.

Wer einen Homepage-Baukasten nutzt und Datenschutzprobleme sieht, sollte die Webseite in ein CMS wie WordPress portieren (lassen). Je nach Nutzung der Webseite geht das sehr einfach oder recht einfach. Sehr einfach ist es dann, wenn nur selten Inhalte auf der Webseite geändert werden sollen.

Kritische Tools entfernen oder ersetzen

In Kürze, hier die Schritte hin zu einer sauberen Webseite:

• Bestandsaufnahme machen: Siehe oben (Website-Check) oder Profi fragen
• Nicht mehr benötigte Tools und Plugins entfernen: Prüfen Sie dazu den Nutzen der Tools. Ist ein eingebundenes Video (womöglich mit Drittinhalten) wirklich nützlich? Brauchen Sie Google Analytics wirklich?
• Weiter benötigte Funktionen optimieren: Nutzen Sie datenschutzfreundliche Alternativen. Hier eine Auswahl:
  • Google Maps → Mein Plugin für interaktive Karte oder gar keine Karte, sondern ein Button „Anfahrt planen“, eventuell versehen mit einem geeigneten Bild der Umgebung (kein Screenshot einer Online-Karte!)
  • Google Analytics → Matomo (bitte auf richtige Konfiguration achten), kann auf eigenen Servern problemlos installiert werden (nicht aber in vielen Homepage-Baukästen!)
  • YouTube Video-Plugin → eigenes Video-Hosting oder gar kein Video oder Vorschaubild mit Link auf Videoplattform
  • Kritischer Mail-Provider wie Mailchimp → eigener Mail-Server (geht bis zu mehreren tausend Newsletter-Abonnenten pro Monat oder für nahezu jede Art von sonstigen Kontaktformularen).
  • Google reCAPTCHA → Eingabefeld mit einfacher Rechenaufgabe („Wie viel sind 17 weniger fünf? Schreiben Sie das Ergebnis als Wort in Kleinbuchstaben“). Mythos: Spam lässt sich nicht durch ein Captcha vermeiden.
  • Google Fonts → Lokal einbinden.

Allgemeine Tipps für guten Datenschutz

Viele der folgenden Tipps gelten auch für die eben genannten Bestandswebseiten. Für neue Homepages können die eben genannten datenschutzfreundlichen Alternativen natürlich ebenso herhalten. Oft besteht für diese aber gar nicht erst die Notwendigkeit, solche Dienste einzusetzen.

Datenschutzhinweise

Vorab: Wegen leicht fehlerhafter oder in Teilen fehlenden Datenschutzhinweisen bekommen Sie üblicherweise keine Probleme. Wichtiger ist es, Daten nur mit der passenden Rechtsgrundlage zu verarbeiten. Einen Dienst wie den YouTube Video-Player ohne Einwilligung einzusetzen ist viel schlimmer als ein Fehler in Hinweistexten.

Sie dürfen meine Datenschutztexte verwenden und anpassen. Bitte denken Sie daran, am Ende der Texte einen kleinen Hinweis mit Link auf meine Webseite einzubauen.

Die Betroffenenrechte und die allgemeinen Rechtsgrundlagen können Sie unverändert übernehmen. Texte für Formulare und Newsletter sollten auch allgemein passen. Verwenden Sie Tools wie Matomo, dann müssen Sie hierfür eigene Texte hinzufügen. Mein Website-Check bietet in der Vollversion Mustertexte für zahlreiche Dienste an.

Wenn Sie Zeit und Lust haben, dann vertonen Sie einzelne Abschnitte Ihrer Datenschutzerklärung doch. So wird Ihre Webseite etwas barrierefreier.

Ich empfehle übrigens, die Datenschutzerklärung als Datenschutzhinweise zu bezeichnen. So vermeiden Sie aus rechtlicher Sicht Missverständnisse und niemand kommt so schnell auf die Idee, Ihnen zu unterstellen, es handele sich dabei um einen Vertrag. Vielmehr handelt es sich um Pflichtinformationen gemäß Art. 12 DSGVO.

Bitte bezeichnen Sie Cookies nicht als Textdateien. Ein Cookie ist ein Datensatz oder Datenspeicher. Beschreiben Sie lieber die Zwecke von Cookies. Es geht übrigens nicht um Cookies, sondern um Zwecke. Zwecke werden auf Webseite typischerweise durch Dienste (Tools & Plugins) verwirklicht. Beschreiben Sie also die eingesetzten Dienste. Pro Dienst nennen Sie dann die hoffentlich nicht verwendeten Cookies. Pro Cookie nennen Sie dessen Namen, Lebensdauer und den Zweck. Kennen Sie den Zweck nicht, ist das ein Anzeichen dafür, dass Sie einen Dienst einsetzen möchten, den Sie nicht einsetzen sollten. Fragen Sie doch mal beim Anbieter des Dienstes nach. Meinen Sie, dass dieser Ihnen nicht antworten wird (Google, Facebook etc.), dann kennen Sie die Antwort ja schon. Bekommen Sie keine gute Antwort, dann steht die Entscheidung ebenso fest.

Auf jeder „verdammten“ Seite Ihrer Webseite müssen die Datenschutzhinweise verlinkt sein. Auf jeder Seite. Es mag ganz wenige Ausnahmen geben, die man vor Gericht durchkriegen würde. Darauf sollten Sie sich nicht verlassen. Jede Seite bedeutet mindestens: Jede öffentlich zugängliche Seite. Bei WordPress-Webseiten ist beispielsweise die Login-Seite für Administratoren und Redakteure meist öffentlich zugänglich (Pfad /wp-admin/). Bei Typo3 heißt der Pfad anders (/typo3/), andere Webseite haben weitere fixe Pfade, die man leicht herausfinden und ausprobieren kann.

Achten Sie darauf, dass der Link auf die Datenschutzhinweise nicht verdeckt wird, beispielsweise durch ein Cookie-Popup. Der Link muss mit maximal zwei Klicks erreichbar sein. Das gilt auch für Smartphones. In Browsern wie dem Firefox können Sie die mobile Ansicht simulieren (Tastenkombination Strg + Shift + M), wenn Sie zu faul sind, Ihr Handy für den Test zu nutzen.

Die Datenschutzhinweise sollten in derselben Domäne vorhanden sein wie die Webseite, die auf diese Hinweise verlinkt. Viele Unternehmen, die mehrere Webseiten haben, nutzen ein und dieselbe Datenschutzerklärung. Erstens hat die Angabe spezifisch zu sein, was gegen eine gemeinsame Seite spricht. Zweitens sorgt die Unverfügbarkeit des Servers, auf dem die Datenschutzhinweise liegen, dafür, dass bei Besuch einer Webseite, die auf einem anderen Server liegt, Probleme entstehen.

Cookies

Nahezu sämtliche Cookies sind nicht notwendig und bedürfen somit einer Einwilligung (§ 25 TDDDG). Eine Einwilligung muss abgefragt werden für das Setzen oder Auslesen eines Cookies. Ebenso muss die Weiterverarbeitung des Cookie-Wertes mit einer Rechtsgrundlage aus Art. 6 Abs. 1 DSGVO legitimiert werden, weil Cookies immer personenbezogene Daten darstellen.

Allerdings wird eine Einwilligung nicht für Cookies abgefragt, sondern für Dienste. Denn ein Cookie entsteht nie von selbst, sondern immer durch einen Dienste. Auch die vom Besucher aufgerufene Webseite ist ein Dienst (nämlich ein Telemediendienst).

Beispiele für einwilligungsfreie Cookies:

• Warenkorbverwaltung im Online-Shop (geht zwar theoretisch auch ohne Cookies, hätte dann aber u. a. Sicherheitsimplikationen)
• Verwaltung angemeldeter Nutzer (Login für Admins, Redakteure etc.) = Sitzungsspeicher
• Spracheinstellung bei mehrsprachigen Webseiten, aber erst nach Wahl einer (anderen) Sprache durch den Nutzer
• Vermerken der erteilten Einwilligung durch den Nutzer. Dann aber nur mit minimalinvasiven Werten
• Vermerken der nicht erteilten Einwilligung des Nutzers. Dann aber nur mit einem Wert wie „0“, „Nein“ oder „-“ und nicht mit einer Zeichenfolge. Ausnahme: Der Nutzer hatte zuvor bereits mindestens einmal eingewilligt und danach den Widerruf abgesetzt. Dann muss ja bekannt sein, wie lange die Einwilligungsentscheidung bestand.

Cookie Popups

Vermeiden Sie Cookie Popups. Der Begriff ist schon falsch. Es geht nicht um Cookies. Es geht um einwilligungspflichtige Vorgänge. Dazu gehören unter anderem

• Datenabrufe aus unsicheren Drittländern wie den USA (Art. 44 ff DSGVO sowie Schrems II-Urteil). Beispiele: Google Analytics (gibt Google selber zu), Google Fonts. Auch irische Ländergesellschaften, die nur zur Abrechnung erfunden wurden, ändern daran nichts.
• Nutzerprofilbildung („Tracking“), vgl. Art. 5 Abs. 1 DSGVO.
• Nicht notwendige Zugriffe auf das Endgerät des Nutzers, also insbesondere Zugriffe durch
  • Cookies
  • JavaScript-Funktionen (siehe Google Analytics oder falsch konfiguriertes Matomo, wenn der Viewport abgefragt wird; der Viewport ist die momentane Größe des Browser-Fensters)

Achten Sie darauf, dass die Seite mit den Datenschutzhinweisen aufrufbar ist, ohne dass das Cookie Popup erscheint!

Cookie Blocker funktionieren nicht. Wenn Sie ein Plugin einbinden, das einwilligungspflichtig ist, dann sorgen Sie gefälligst selber dafür, dass es erst geladen wird, nachdem eine Einwilligung erteilt wurde. Automatisch kann das nicht stattfinden. Auch Cookie Scanner sind ein großer Haufen Bullshit. Weitere Begründungen gegen Cookie-Popups finden Sie hier und hier.

Sind Sie tatsächlich so verzweifelt, ein Cookie Popup nutzen zu müssen, dann lesen Sie wenigstens meine Checkliste durch. Vielleicht möchten Sie mein kostenfreies Consent Tool verwenden. Bitte beachten Sie, dass ein gutes Werk eigene Arbeit erfordert. Sie müssen mehr Mühe investieren als in „Lösungen“ von der Stange, die nicht richtig funktionieren.

Nutzen Sie ein Cookie Popup, dann muss es auch bei eingeschaltetem Werbe-Blocker funktionieren. Solche Blocker sind etwa Ghostery oder uBlock Origin. Probieren Sie es aus.

Hosting

Diw Wahl des Anbieters, der den Web Server bereitstellt, auf dem die Webseite läuft, ist entscheidend.

Deutsche Anbieter sind bezüglich Datensicherheit am besten, weil amerikanische oder andere außereuropäische Anbieter nationalen Spionagesetzen unterworfen sind, die mit der DSGVO nicht vereinbar sind.

Mit der Domain Analyse kann für bestehende Websites geprüft werden, ob Sicherheitsprobleme existieren. Geprüft werden unter anderem der Hoster, der verwendete DNS-Provider, das CDN (falls vorhanden) und einiges mehr.

Weitere Tipps

Das Wichtigste in Kürze:

• Plugins prüfen: Nutzen Sie ein CMS wie WordPress, Typo3 oder Magento, dann deaktivieren Sie alle nicht benötigten Plugins. Vorinstallierte Plugins deaktivieren und höchstens nach genauer Prüfung von Datenschutz und Nutzen wieder aktivieren.
• Rechtsgrundlagen prüfen: Meist bleiben nur die Einwilligung und das berechtigte Interesse. Letzteres ist oft nicht anwendbar. Bleibt die Einwilligung. Diese sollten Sie vermeiden. Sie bringt nur Probleme mit sich. Nutzen Sie daher datenschutzfreundliche Alternativen. Weiter oben habe ich einige genannte. In meinem Blog finden Sie zahlreiche weitere Hilfestellungen.
• SSL-Zertifikat: Beispielsweise von Let’s Encrypt. Bei kostengünstigen Tarifen von ALL-INKL ist ein solches Zertifikat enthalten. Mit der Option „SSL erzwingen“ wird dafür gesorgt, dass die Weiterleitung auf SSL bei Aufruf der Webseite mit http://website-adresse.de automatisch funktioniert.
• Login-Seiten: Sichern Sie diese mit einem serverseitigen Passwort. Das geht über die Datei .htaccess. Damit sichern Sie Ihr Login ab und brauchen sich zudem keine großen Sorgen um die Verlinkung Ihrer Datenschutzhinweise auf dieser Seite zu machen. Auch Cookies, die von vielen Website-Systemen auf der Loginseite platziert werden, sind dann entschärft.
• Kontaktformulare: Fragen Sie nur nach den nötigsten Daten. Prägen Sie Mussfelder sehr sparsam aus. Fragen Sie nach „Name oder Pseudonym“ oder verzichten Sie auf diese Frage (es gibt Ausnahmen, in denen der Name wichtig ist zu wissen, ob aber eben nicht)
• Datenschutzhinweise für Kontaktformulare: Fragen Sie nicht nach einer Bestätigung über eine Checkbox, weil eine Wissensbestätigung rechtlich problematisch ist. Informieren Sie nur am Formular: „Wir verwenden Ihre Angaben nur, um mit Ihnen wegen Ihres Anliegens zu kommunizieren. In unseren Datenschutzhinweisen finden Sie weitere Informationen.“ (bitte den Link so gestalten, dass er in neuem Fenster aufgeht)

Zusammenfassung

In Kürze hier der Schnellstart:

• Deutscher Provider, kein Homepage-Baukasten.
• Ein CMS wie WordPress verwenden, oder eben reine HTML-Dateien (für technikaffine, die nur selten Inhalte ändern, oder einen Dienstleister haben).
• SSL-Zertifikat mit Weiterleitung; Ausnahme: Webseite hat kein Formular.
• Nur das tun, was sinnvoll und richtig ist, also am besten fast nichts (damit kommt man sehr weit. Sehen Sie auf meiner Webseite eine Einwilligungsabfrage?)
• Datenschutzfreundliche Dienste nutzen, Cookie-Popup vermeiden.
• Datenschutztexte einmal sorgfältig schreiben, anstatt dauern nachzubessern.
• Klein starten und wachsen anstatt die Seite mit zig Plugins zuzuballern.
• Regelmäßig einen Website-Check durchführen. Die reine Automatik hilft schon viel. Wer mehr will, muss etwas Geld bezahlen. Hatte ich schon erwähnt, dass wir im Kapitalismus leben?

Datenschutzfreundliche Webseiten entstehen fast automatisch, wenn nur die Dinge getan werden, die nützlich und dem gesunden Menschenverstand zugänglich sind. Lassen Sie sich nicht von anderen verwirren. Manche behaupten ja, Cookie Popups seien notwendig. Ich kenne einen Vorgang der Firma Velux, die Handwerkern für deren Webseiten ein Cookie Popup vorschreibt, wenn diese einen Velux Konfigurator einbinden wollen. Velux verrät aber selbst auf mehrfache Nachfrage nicht, warum eine Einwilligung abgefragt werden soll und gibt keine Informationen für die rechtliche Ausgestaltung der Abfrage.

FAQ

Frage: Wie kann man eine DSGVO-konforme Webseite erstellen?
Antwort: Eine DSGVO-konforme Webseite kann erstellt werden, indem man einen deutschen Provider und kein Homepage-Baukasten verwendet, datenschutzfreundliche Dienste nutzt, Cookie-Popups vermeidet, Datenschutztexte sorgfältig erstellt und regelmäßig Website-Checks durchführt.

Frage: Welche Alternativen gibt es für Google Analytics?
Antwort: Eine Alternative zu Google Analytics ist Matomo, das bei richtiger Konfiguration ohne Einwilligungsabfrage eingesetzt werden kann.

Frage: Warum sollte man einen rein deutschen Provider wählen?
Antwort: Ein rein deutscher Provider ist empfehlenswert, da er sich besser mit einheimischen Gesetzen und Vorschriften auskennt und der Gerichtsstand im eigenen Land bei Streitigkeiten unkomplizierter ist.

Frage: Warum sollte man Homepage-Baukästen vermeiden?
Antwort: Viele Homepage-Baukästen weisen Datenschutzmängel auf, die nicht abgestellt werden können, weshalb sie für denjenigen, der keine Datenschutzprobleme haben möchte, ungeeignet sind.

Fazit

Von Anfang an das richtige Fundament zu wählen, erspart nicht nur beim Hausbau viel Ärger, sondern auch bei der Webseite.

Wer alle Tools der Welt nutzen will, wird keine datenschutzfreundliche Webseite erhalten. Gleiches gilt für Marketing-getriebene Unternehmern, die nicht bereit sind, zu reflektieren, sondern erst tätig werden, wenn Gefahr droht. Marketing und Datenschutz schließen sich nicht aus. Selbst Google-Dienste können mit geringem rechtlichen Risiko verwendet werden, wenn auf die richtige technische und rechtliche Ausgestaltung geachtet wird.

Eine Webseite, die kein Cookie-Popup benötigt, ist meistens im Datenschutz sehr gut aufgestellt. Der Betreiber hat viel weniger Arbeit und kann ruhiger schlafen als alle, die die lästige Einwilligungsabfrage auf ihrer Webseite vorhalten und jeden Besucher damit belästigen müssen. Wenn dann noch ein Nutzer auf die Idee kommt, vom Website-Betreiber den Nachweis einer zuvor erteilten Einwilligung zu verlangen (siehe Art. 7 Abs. 1 DSGVO), geht der Spaß erst richtig los. Oft scheitert es aber bereits am Widerruf, der gar nicht oder nicht ordentlich bereitgestellt wird. Sogar den vorgeschriebenen Hinweis auf die Widerrufsmöglichkeit (Art. 7 Abs. 3 DSGVO) bekommen viele nicht hin, obwohl es nur ein Text ist. Kommt jemand daher, der ein Auskunftsgesuch nach Art. 15 DSGVO stellt, bricht für viele Verantwortliche eine Welt zusammen. Ich hatte kürzlich einen Kunden, dessen amerikanische Konzernmutter den europäischen Webshop komplett lahmlegen wollte, wenn nicht binnen weniger Wochen alles datenschutzkonform sei. Der Webshop hatte einen sechsstelligen Monatsumsatz alleine für Deutschland. Der Auslöser war ein Auskunftsgesuch.

Weniger ist mehr. Das Brain washing durch Google & Co. war bis vor kurzem erfolgreich. Jetzt beginnt eine neue Zeit.

Haben Sie Ihre Webseite auf Vordermann gebracht, schaue ich gerne kurz drauf und gebe Ihnen eine kurze Einschätzung, wenn Sie möchten.

Übrigens hat eine saubere eigene Webseite den Vorteil, dass Sie sich viel leichter gegen andere wehren können. Denn wenn mich jemand attackiert, schaue ich mir zuerst dessen Webseite an…

Wann Ihre Website trotzdem eine Einwilligung braucht und was Consent-Tools leisten, fasst die Übersicht zu Cookies und Einwilligung zusammen.

Alle Bilder in diesem Beitrag wurden von einem Computer-Programm erzeugt. Verwendet wurde das selbst entwickelte KI-System von Dr. DSGVO, ähnlich zu Midjourney. Die Bilder dürfen auf Webseiten frei verwendet werden, mit der Bitte, eine Verlinkung auf diesen Blog zu setzen.

Erst kürzlich hatte ich Cookie-Bilder veröffentlicht. Das war mehr zur Erheiterung gedacht. Vielleicht können manche diese Bilder auch in nützlicher Umgebung verwenden. Im Beitrag zu den Bildern habe ich auch ein paar Grundlagen zu Cookies genannt.

Hier ein paar weitere Fakten, die die im Beitragstitel besagten Probleme mit sich bringen.

Cookies sind unkontrollierbar.

Jedenfalls stimmt das in der Praxis für Cookies, die Dienste von Drittanbietern setzen. Man muss unterscheiden zwischen fachlicher und technischer Ausprägung.

Technische First Party Cookies haben dieselbe Domäne wie die gerade besuchte Webseite. Die Domäne einer Webseiten-Adresse (URL) ist der Hauptnamensbestandteil. Für die Webseitenadresse https://dr-dsgvo.de lautet die Domäne dr-dsgvo.de. Technische Third Party Cookies sind alle Cookies mit einer Domäne ungleich der besuchten Webseite. Genauer gesagt, sind es „nur“ die Domänen von Webseiten, die nicht denselben Verantwortlichen haben wie die gerade besuchte Webseite.

Fachliche First Party Cookies sind alle Cookies, die denselben Verantwortlichen haben wie die gerade besuchte Webseite. Fachliche Third Party Cookies sind alle anderen Cookies.

Wer Google Analytics einbindet, erhält somit technische First Party Cookies und fachliche Third Party Cookies. Rechtlich kommt es dann darauf an, ob ein AVV mit Google geschlossen wurde bzw. wie es mit einer gemeinsamen Verantwortlichkeit aussieht.

Warum sind Cookies faktisch nun unkontrollierbar? Weil beim Widerruf einer erteilten Einwilligung alle Cookies vom Endgerät des Nutzers zu entfernen sind, die durch die Einwilligung aus § 25 TTDSG legitimiert wurden. Dummerweise gibt es für die meisten populären Dienste keinen Abräum-Mechanismus. So sind zwei Fälle zu unterscheiden:

Ein technisches First Party Cookie kann von der besuchten Webseite, auf der der Widerruf abgesetzt wird, theoretisch selbst gelöscht werden. Dazu muss die Webseite dies erstens tun wollen und zweitens wissen, wie die Namen dieser Cookie-Biester lauten.

Ein technisches Third-Party Cookie hingegen kann grundsätzlich nur vom Dienst entfernt werden, der es erzeugt hat. Das ist ein technisches Faktum. Wenn der Dienst keine Funktion dafür anbietet, darf dieser Dienst nicht verwendet werden, weil er nicht rechtskonform nutzbar ist. Bietet der Dienst eine Funktion an, kennt ihn hoffentlich jeder Verantwortliche und ruft diese Funktion auch richtig auf.

Problematisch sind Cookies von Konzernen wie Google. Die Google Suchmaschine, Google Maps und andere Google Webseiten setzen Cookies in Domänen, die gleich denen sind von Diensten, die Google als Plugin für Ihre Webseite anbietet. Das ist wohl kein Zufall, sondern Kalkül. Mehr Daten sind gut, jedenfalls für Google. Diese Cookies, die als Beifang hinzugekommen sind, haben Sie auch zu verantworten, wenn Sie Google Dienste auf Ihrer Webseite einbinden. Der Widerruf scheitert dann, weil Sie diesen Beifang gar nicht kennen können.

Cookie Tools sind problematisch

Hierüber hatte ich schon viel geschrieben. Mehrere Gründe in Kürze:

• Cookie Blocker funktionieren nicht. Die Gründe sind objektiv gegeben und technischer Natur.
• Cookie Hinweise sind Bullshit: Diese Pflichtinformationen sind meist falsch, weil geraten.
• Cookie Zentrierung ist Blödsinn: Manche meinen, es ginge nur um Cookies.
• Der Widerruf ist nicht ordentlich möglich: Siehe oben.
• Google Fonts, der Google Tag Manager usw. werden absichtlich nicht blockiert. Wäre noch schöner, wenn eine Webseite nur deswegen etwas hässlich aussieht, damit sie rechtskonform ist.

Wer es genauer wissen will, kann es sich im Datenschutz Deluxe Podcast anhören.

Die bisherigen Folgen des Datenschutz Deluxe Podcasts sind:

• Folge 1: Spannende Datenschutzfragen
• Folge 2: Cookies und Cookie Tools (andere Fragen, anderer Moderator)
• Folge 3: Google Topics und Google FloC (das Ende aller Cookies? Nein!)
• Folge 4: Reichweitenmessung für Webseiten und Apps
• Folge 5: Server Side Tracking und Cookies
• Folge 6: Datenschutzverstöße: Diskussion zwischen Informatiker und Rechtsanwalt
• Folge 7: Smart Home Geräte: Datenschutz und gesetzliche Vorgaben
• Folge 8: Conversion Tracking
• Folge 9: Google Tag Manager: Weder ein Cookie noch eine Domäne noch erforderlich

Weitere Folgen finden Sie hier in der Übersicht zum Datenschutz Deluxe Podcast:

Der Deutschen IT-Security Kongress 2022 widmete sich hauptsächlich der IT-Sicherheit. Dankenswerterweise hatte mich Philipp Wachhorst im Vorfeld gefragt, ob wir nicht auf dem Kongress über Datenschutz diskutieren könnten. Immerhin vereint der Art. 32 DSGVO beide Aufgabengebiete.

Der Titel unserer Panel-Diskussion lautete (ursprünglich „Datenschutz-Guru's im Talk“. Aber weil wir keine Guru's sind oder sein wollen, wurde der Titel geändert):

Moderiert wurde das Gespräch der „Datenschutz-Guru's“ (die gar keine sind) Philipp und mir durch Emily Feldscher, die auch Fragen aus dem Publikum aufgegriffen hat.

Auf gemütlichen Chesterfield-Sesseln sprachen über die aktuelle Datenschutz-Lage im Internet und auf Webseiten. Die Sessel standen im Alando Palais, sonst eine Nobel-Disco, zum Kongress ein perfekter Ort für den fachlichen Austausch (inklusive Catering, Grill-Buffet im Außenbereich am Wasser sowie After-Show Party mit Live-Band).

Die Themen unseres Gesprächs waren insbesondere:

• Ziehen sich Philipp und ich aus (Stichwort "Erotik" bzw. sexy) oder ist das Antlitz der Moderatorin erotisch genug (siehe Beitragsbild oben)?
• Wie gut stehen große deutsche Unternehmen aktuell beim Datenschutz da?
• Was ist mit Google Tools?
• Was ist mit der geplanten zentralen Einwilligungsverwaltung (PIMS)?
• Müssen Cookie-Banner eine direkte Ablehnen-Möglichkeit anbieten?
• Welche guten Nachrichten gibt es?

Zu den Themen im Einzelnen hier ein kurzer Rückblick.

Erotik und Datenschutz:

Sexy bezieht sich auf die Möglichkeiten, die Datenschutz bietet. Es geht nicht darum, dass ich meinen perfekten Körper präsentiere, sondern darum, wie Datenschutz dabei helfen kann, Unternehmen nach vorne zu bringen. Allerdings haben das bestimmte Gruppen von Unternehmen noch nicht in Gänze erfasst, beispielsweise folgende.

Große deutsche Unternehmen:

Große deutsche Unternehmen haben oft große Probleme mit dem Datenschutz auf deren Webseiten. Das verwundert etwas, weil doch genügend Ressourcen da sein müssten, um gesetzliche Regelungen in den Griff zu bekommen.

Datenschutz ist wichtig für Unternehmen, weil er Innovation fördert, wenn er richtig angewendet wird. Investitionen in Datenschutz können späteren Aufwand reduzieren und helfen, rechtliche Probleme zu vermeiden. Datenschutz und IT-Security sind eng miteinander verbunden und tragen zur Absicherung der digitalen Infrastruktur bei.

Erst kürzlich musste ich feststellen, dass sowohl die Deutsche Bahn als auch Google (zum Glück kein deutsches Unternehmen) anscheinend nicht wissen, dass auch für andere Dinge als Cookies eine Einwilligung erforderlich ist.

Immerhin fragen beide Giganten nur nach einem Consent für Cookies. Dass auch Endgerätzugriffe über JavaScript, wie sie bei Google Analytics im Standard immer stattfinden, einwilligungspflichtig sind, sei nur als ein Beispiel für etwas anderes als Cookies erwähnt. Ein anderes Beispiel ist die Nutzerprofilbildung (auch ohne Cookies), die immer dann stattfindet, wenn das YouTube-Plugin auf eigenen Webseiten eingebunden wird (Stand: 17.10.2022).

Google-Tools:

Spätestens seit der Abmahnwelle zu Google Fonts ist bekannt, dass der Einsatz von Google-Tools auf eigenen Webseiten hochkritisch ist. Google Analytics wurde von zahlreichen Datenschutzbehörden in Europa gebrandmarkt und in Frankreich durch die CNIL gänzlich verboten. Wie Google bereits im Jahr 2021 zugab, werden alle Analytics-Daten immer in den USA verarbeitet.

Wer etwas für seine Rechtssicherheit tun und dazu noch aufhören möchte, immer mehr Daten an rein profitorientierte Unternehmen zu liefern, sollte Google-Plugins aus seinen Webseiten und Apps verbannen. Hier ein Anregung:

• Google Fonts –> Lokal einbinden
• Google Maps –> Mein Karten-Plugin
• Google Analytics –> Matomo, Conversion Tracking durch URL-Parameter
• Google Ads –> sinnvolle Maßnahmen. Kann man relevanten Erfolg mit mäßig viel Geld kaufen? Ich sage: Nein

Wichtig ist der richtige Berater. Glauben Sie nicht alles, was manche meinen. Orientieren Sie sich an Fakten. Wer behauptet, dass Cookies Textdateien seien, blendet beispielsweise die Realität aus. Genauso hellhörig sollten Sie werden, wenn jemand immer noch behauptet, der Google Tag Manager sei eine cookielose Domäne. Das ist Bullshit.

Könnten Sie mir erklären, warum jemand, der nicht viel Ahnung von Technik hat, kompetent sein soll, wenn es um technische Fragen geht? Internet-Anwendungen bedingen eigentlich immer technische Betrachtungen, oder irre ich mich da? Andererseits: Bin ich der richtige, um für Sie Vertragswerke zu erstellen?

Cookie-Tools:

Wir sprachen auch über Cookie-Tools. Wer meinen Blog kennt, weiß, was es damit auf sich hat. Wem meine Beiträge noch nicht bekannt sind, dem empfehle ich das Lesen meiner Untersuchung mit dem Titel Cookiegeddon.

Aus dem Publikum kam eine Frage zur Ablehnen-Möglichkeit. Der Fragesteller wollte wissen, ob diese gleichwertig wie der „Alles akzeptieren“-Button angeboten werden müsse. Meine Antwort lautete: Ja. Nudging ist rechtswidrig, sage ich und sagen viele andere. Begründungen: Siehe Informationen in diesem Blog. Sogar Google hat es mittlerweile eingesehen. Vor kurzem musste man noch fünf oder sechsmal klicken, um Google mitzuteilen, dass Google die Nutzer-eigenen Daten nicht misshandeln darf. Jetzt reicht ein Klick. Das hat Google nicht freiwillig gemacht, sondern musste erst von außen geeignet motiviert werden.

Aus dem Publikum kam die Nachfrage, ob das mit der Ablehnen-Möglichkeit „im Gesetz stehen“ würde. Nein, tut es nicht (siehe DSGVO: Diese ist zwar kein Gesetz, sondern eine Verordnung, aber viele verstehen darunter das gleiche). Gesetze sind oft abstrakte Regelungen, die im Allgemeinen nicht besonders konkret werden können. Ansonsten bestünde die DSGVO nicht nur aus 99 Artikeln, sondern aus 9999.

Zentrale Einwilligungsverwaltung (PIMS):

Auf die Frage von Philipp Wachhorst zum § 26 TTDSG, der zentralen Einwilligungsverwaltung, nahm ich gerne Stellung. Zahlreiche in der Praxis nicht lösbare Probleme sprechen gegen das, was der Gesetzgeber sich als Lösung vorgestellt hat. Beispielsweise sind Browser-Plugins keine Möglichkeit, die praxisrelevant erscheint. Weitere der über 66 Gründe, die gegen PIMS sprechen, werde ich in Kürze veröffentlichen.

Datenschutz kann sexy sein:

Kommen wir zurück zum erotischen Teil. Zugegeben: Ich kann Datenschutz nicht in den Bereich der Erotik bringen, wenn wir über Datenverarbeitung sprechen. Höchstens der Datenschutzbeauftragte könnte eine gewisse Erotik ausstrahlen, die aber wahrscheinlich für die Erhöhung der Rechtssicherheit nicht förderlich wäre. Allerdings sollten Datenschutzberater den Begriff der Datenverarbeitung öfters in den Mund nehmen. Dann würde auf Consent Popups nämlich nicht fälschlicherweise behauptet, man bräuchte eine Einwilligung (nur) für Cookies. In Wahrheit reicht eine Einwilligung nur für das Setzen oder Auslesen von Cookies quasi niemals aus. Denn die Weiterverarbeitung der ausgelesenen Werte ist schon eine andere Datenverarbeitung (vgl. § 25 TTDSG).

Es ist möglich, Webseiten ganz ohne nervige Cookie Popups zu gestalten. Siehe diese Webseite und mittlerweile auch einige andere. Wie schön ist das denn? Forget about § 26 TTDSG.

Große deutsche Unternehmen haben oft Probleme mit dem Datenschutz auf ihren Webseiten, obwohl sie genügend Ressourcen haben sollten, um gesetzliche Regelungen einzuhalten. Beispiele sind die Deutsche Bahn und Google, die anscheinend nicht wissen, dass auch für andere Dinge als Cookies eine Einwilligung erforderlich ist. Einwilligungspflichtige Endgerätzugriffe über JavaScript und Nutzerprofilbildung sind Beispiele für solche datenschutzrelevante Aspekte.

Spätestens seit den Massenabmahnungen zu Google Fonts gilt: Datenschutz lohnt sich wieder und zahlt sich aus. Weniger Ärger, weniger Stress, weniger Probleme. Mein Blick in die Zukunft verrät mir: Das waren nicht die letzten Massenabmahnungen. Legal Tech ist immer mehr im Kommen. Sicher sind Sie dann gerüstet, ebenso wie auf zukünftige Cybersecurity-Bedrohungen. Lösungen für das Sicherheitsthema gab es jedenfalls auf dem IT-Security Kongress zuhauf.

Ein Leben ohne Google funktioniert genauso wie ein Leben ohne Energie aus Russland. Siehe oben für einige Beispiele (oder auch das Fairphone). So erhöht sich ganz nebenbei auch die Rechtssicherheit Ihrer Internetauftritte.

Weil PIMS nicht kommen wird, brauchen Sie erst einmal nichts weiter zu berücksichtigen und müssen keinen Zusatzaufwand betreiben. Selbst wenn PIMS kommen sollte, brauchen Sie sich keine Sorgen zu machen. Es wird keine Bußgelder von deutschen Aufsichtsbehörden geben.

Wenn Sie gegenüber Ihren Kunden und Interessenten zeigen, dass Sie den Schutz von deren Daten ernst nehmen, wirkt sich das wahrscheinlich positiv auf die Kundenbindung und auf Ihren Umsatz aus.

Wer 10.000 Euro Geld in Online-Marketing investiert, kann leicht 1.000 Euro in den richtigen Berater oder Entwickler investieren, um möglichst datenschutzkonform und rechtssicher aufgestellt zu sein.

Datenschutz sorgt für Innovation, wenn er richtig angewendet wird. Oft werden die Regeln falsch verstanden. Siehe beispielsweise die Corona-Warn App. Dem Gesetzgeber und dessen Berater schien der Art. 6 DSGVO nicht bekannt gewesen zu sein. Dort steht nämlich etwas von Einwilligung als Rechtsgrundlage. Auch ein Erlass einer gesetzlichen Regelung hätte die Corona-Warn App zu einem Erfolgsmodell werden lassen können.

Jetzt etwas Energie in Datenschutz zu investieren, bedeutet, später weniger Aufwand zu haben. Immer diese fruchtlosen Diskussionen zwischen Firmeninhaber, DSB und Web-Agentur. Das muss doch nicht sein. Erster Lösungsansatz: Nehmen Sie Ihren Web-Dienstleister in die Haftung. Fragen Sie mal nach einer Haftungsübernahme und warten Sie ab, was passiert.

Sie kennen es aus dem normalen Leben: Einmal etwas richtig gemacht kostet es weniger Zeit, Geld und Energie als spontan und halbherzig zu reagieren. Nutzen Sie die Chance jetzt!

Weil Datenschutz und IT-Security eng miteinander zusammenhängen, sollte die eigene digitale Infrastruktur gegen Angriffe abgesichert werden.

Fazit

Der Deutsche IT-Security Kongress war ein perfekt organisiertes Event an einem einmaligen Ort, das ich jedem für das nächste Mal ans Herz lege. Dort treffen Sie sicher auf sehr interessante Kontakte aus dem IT-Security Umfeld. Diesmal war unter anderem ein Vertreter des BKA in einer Podiumsdiskussion vertreten. Auch der Verfassungsschutz gab sich die Ehre (zum Glück als Aussteller).

Hier finden Sie das Video von unserem Datenschutz-Talk (hochgeladen von der pco GmbH auf YouTube):

Danke an die pco GmbH für die Einladung und die Gelegenheit, Teil dieser sehr relevanten Veranstaltung sein zu dürfen, die mittlerweile zum dritten Mal stattfand. Das Gespräch mit Philipp Wachhorst auf der Konferenz haben hoffentlich die Zuhörer genauso positiv in Erinnerung wie ich. Gerne wieder! Ich hoffe, das Video ist auch für Sie kurzweilig. Kommen Sie doch beim nächsten Mal auch auf den Kongress oder nehmen Sie online teil.

PS: Alle Bilder bereitgestellt von der pco GmbH und verwendet mit deren freundlicher Genehmigung.

Kurzfassung

Der § 26 TDDDG soll eine Einwilligungsverwaltung einführen, die auf den Zugriff auf Endgeräte und Endeinrichtungen, insbesondere das Speichern von Daten in diesen Geräten, bezogen ist. Es gibt jedoch mindestens fünf verschiedene Arten von einwilligungspflichtigen Vorgängen, die nicht alle durch eine Einwilligungsverwaltung abgedeckt werden können. Dies wurde auch auf der Herbstakademie der Deutschen Stiftung für Recht und Informatik (DSRI) in Hannover im September 2022 festgestellt. Somit ist PIMS als zentrale Einwilligungsverwaltung beschränkt auf den Zugriff auf Cookies, nicht aber auf die Verarbeitung der Cookie-Werte. Weitere Gründe sprechen gegen PIMS. Am 14. Mai 2024 ging das TTDSG in das TDDSG über. Damals wurde noch vom TTDSG gesprochen, was den gleichen Inhalt hat.

Einleitung

In den nächsten Wochen und Monaten werde ich 66 Gründe benennen, warum eine zentrale Einwilligungsverwaltung scheitern wird. Dabei führe ich vor allem rein logische und praktische Gründe auf. Rechtliche Problemchen müssen nicht einmal herangezogen werden, um PIMS oder ADPC, wie der zentrale Verwaltungsdienst auch genannt wird, ad absurdum zu führen. Eine andere lateinische Formulierung ist im Einleitungstext genannt: ex ante. Das bedeutet „in die Zukunft gerichtet“ oder „im Voraus“. Was mit der Zukunft zu tun hat, ist in der Regel mit großen Unsicherheiten behaftet. So auch hier.

PIMS steht übrigens für Personal Information Management System. Ab und an steht das P auch für Private und das S für Service. ADPC steht für Advanced Data Protection Control und ist als Browser-Plugin gedacht. PIMS kann als zentrale Webseite oder als Browser-Plugin ausgestaltet sein. Wie auch immer, es wird nicht funktionieren.

Zentrale Verwaltung von Cookie-Einwilligungen

Grund 1 für das Scheitern von PIMS thematisiert den § 26 TDDDG. Dieser Paragraph soll eine Einwilligungsverwaltung einführen, und zwar genau für Einwilligungen, die nach § 25 Absatz 1 TDDDG eingeholt werden müssen. Der § 25 TDDDG wiederum thematisiert ausschließlich Zugriffe auf Endgeräte und Endeinrichtungen, insbesondere das Speichern von Daten in diesen Geräten.

Ein solcher Zugriff liegt insbesondere bei Verwendung von Cookies vor. Dass auch Javascript-Routinen auf das Endgerät zugreifen können, soll hier nicht näher thematisiert werden. Als Stichwort sei hier die Größe des Viewport genannt (=Größe des Browser-Fensters).

Arten einwilligungspflichtiger Vorgänge

Wie sicher vielen bekannt ist, geht es nicht nur um Cookies. das Wort Cookie taucht im Gesetzestext von DSGVO und TDDDG nicht einmal auf.

Ich sehe mindestens folgende einwilligungspflichtige Vorgänge:

1. Zugriff auf das Endgerät (Cookies, JavaScript oder Updates bei Smart Home Geräten): § 25 TDDDG.
2. Verarbeiten von personenbezogenen Cookie-Daten: Art. 6 Abs. 1 DSGVO.
3. Datentransfer in unsichere Drittländer: Art. 44ff DSGVO + EuGH-Urteil Schrems II.
4. Nutzerprofilbildung: Vgl. § 15 Abs. 3 DDG als Anhaltspunkt sowie Art. 5 Abs. 1 DSGVO (Grundsätze der Datenverarbeitung). Als übergeordneter Fall: Verarbeitung personenbezogener Daten ohne Rechtsgrundlage (insbesondere ohne berechtigtes Interesse).
5. Milderes Mittel vorhanden: Vgl. Art. 5 Abs. 1 DSGVO.

Ei wo sind denn die Cookies? Entweder im Backofen oder in der obigen Auflistung unter den Punkten eins und zwei, aber nicht unter den Punkten drei bis fünf.

Zentrale Einwilligungsverwaltung greift viel zu kurz

Somit kann eine Einwilligungsverwaltung aus § 26 TDDDG lediglich für ein oder zwei von mindestens fünf verschiedenen Arten von einwilligungspflichtigen Vorgängen eine Einwilligung einholen.

Noch schlimmer: Der § 25 TDDDG bezieht sich nur auf Speicherung und Zugriff von Cookies. Somit ist lediglich Punkt eins meiner obigen Liste berücksichtigt. Das TDDDG ist ein Sondergesetz (lex specialis) zur DSGVO. Es sperrt die DSGVO also genau dann, wenn es speziellere (und strengere) Regeln als die DSGVO enthält.

Vom 15. bis zum 17. September 2022 fand die Herbstakademie der Deutschen Stiftung für Recht und Informatik (DSRI) in Hannover statt. Dort trug nicht nur ich zum § 26 TDDDG vor (aus technischer und etwas rechtlicher Sicht), sondern auch – ganz unabhängig von mir – Bernhard Harle (als Jurist). Auch Herr Harle hatte bemerkt, dass der § 26 TDDDG sich nur auf den § 25 TDDDG bezieht und nicht auf Einwilligungen, die sich aus anderen Rechtsvorschriften ergeben.

Somit ist PIMS als zentrale Einwilligungsverwaltung beschränkt auf den Zugriff auf Cookies.

Dumm nur, dass ein Cookie, welches m. E. immer einen Personenbezug darstellt, sinnlos ist, wenn man zwar dessen Wert erhält, mit diesem Wert aber nicht arbeiten darf (siehe § 25 TDDDG). Die Verarbeitung des Cookie-Wertes ist in der DSGVO, nicht aber im TDDDG geregelt. Wer negiert, dass Cookies an sich einen Personenbezug über die personenbezogene IP-Adresse hat, die mit einem Cookie immer zusammen übertragen wird, der sollte sich folgende Beispiele ansehen. Die Beispiele zeigen Cookie-Werte, die bereits aufgrund ihrer Wertausprägung einen Personenbezug zulassen.

• Identifizierer: nfdmsnd3457sl. Siehe beispielsweise Google Analytics (somit auch ohne Cookies alleine deswegen problematisch, siehe Client Id). Der Wert muss nicht sehr lange sein. Für 8 Milliarden Menschen reichen bei einem Alphabet von 36 Zeichen (26 Kleinbuchstaben + 10 Ziffern) bereits sieben Stellen (36^7 = 78.364.164.096 Kombinationsmöglichkeiten = 78 Milliarden)! Eine Stelle mehr würde dann ganz sicher für alle Endgeräte der Welt reichen (36^8 = 2,8 Billionen)
• Mailadresse: newsletter-abonnent@ichbins.nit. Siehe beispielsweise Formulare für Newsletter auf Webseiten.
• IP-Adresse im Cookie als Wert: Auch das kommt gelegentlich vor (damals bei Google Analytics, heutzutage in manch anderem Tool. Beispiel gerade nicht zur Hand).
• Cookie-ID: Haben CMP-Anbieter als Konstrukt erfunden. Damit soll eine Einwilligung nachgewiesen werden können, was Unsinn ist, weil ein vom Nutzer gelöschtes Cookie, das die Cookie-ID enthielt, das Verfahren zunichtemacht.
• Geo-Koordinate: OneTrust führt diese nach meiner Beobachtung mit. Ist sie genau genug und/oder sind weitere Angaben vorhanden, kann daraus eine Person ermittelt werden. Es soll Menschen geben, die in dünn besiedelten Gebieten leben.
• Kundennummer: Online-Shop o. ä., kein Problem, wenn als Kunde angemeldet. Was aber, wenn nicht angemeldet?
• Fingerprint: Siehe zahlreiche alle Analyse-Tools und Tracker, die ohne Cookies auskommen wollen oder müssen.

Noch dümmer, dass die anderen drei oben von mir genannten Arten nicht einwilligungsfreier Vorgänge ganz und gar nicht vom PIMS aus § 26 TDDDG erfasst sind. Zu diesen Vorgängen gehören beispielsweise auf Webseiten:

• Google Fonts
• Adobe Fonts (typekit.net), Monotype Fonts, Fast Fonts (verwenden oft auch Zählpixel, angeblich zu Abrechnungszwecken)
• Google Tag Manager (ohne Cookies)
• Google Maps (ohne Cookies)
• Google Analytics (ohne Cookies)
• YouTube Video Player (ohne Cookies, dafür aber mit DoubleClick-Werbetracker Script)
• Google irgendwas-Plugins ohne Cookies
• Facebook irgendwas-Plugins ohne Cookies
• Abruf von JavaScript-Bibliotheken wie jQuery von einem CDN, mit dessen Anbieter kein AVV abgeschlossen wurde, vor allem, wenn der Anbieter aus den USA stammt

Der § 26 TDDDG und PIMS wurden ja ins Leben gerufen, um Cookie Popups möglichst weitgehend zu eliminieren. Wenn man Cookie Popups als Cookie-Einwilligungsabfragen ansieht, stimmt das immerhin zur Hälfte. Wenn man unter Cookie Popup eine Einwilligungsabfrage versteht, stimmt es nur zu einem Fünftel.

Wie auch immer, PIMS ist ein zum Scheitern verurteilter Ansatz. Selbst wenn dieses Problemchen der mangelnden Abdeckung des § 26 TDDDG gelöst werden sollte, sprechen immer noch 65 andere Gründe gegen PIMS. Sie werden alle davon erfahren, sofern der Gesetzgeber nicht vorzeitig einsieht, dass es sinnvoll ist, die Einwilligungsverwaltungs-Verordnung zu stornieren.

Fazit

Eine Einwilligungsverwaltungs-Verordnung wird nicht kommen. Sofern sie doch das Licht der Welt erblicken wird, wird das Desaster riesengroß und an Peinlichkeit kaum zu überbieten sein.

Es ist egal, ob Browser-Plugins oder eine zentrale Webseite zur Verwaltung von Einwilligungen kommen sollen. Beide Ansätze können nicht funktionieren. Zu Browser-Plugins werde ich in Kürze rein logische Gründe für deren Scheitern nennen. Übrigens hat auch der oben genannte Herr Harle einiger dieser Gründe in seinem Beitrag für den Tagungsband der DSRI-Herbstakademie 2022 benannt.

Wer weniger Popups will, hat zwei Möglichkeiten: Selber dafür sorgen, dass die eigenen Webseiten keine einwilligungspflichtigen Vorgänge enthalten. Wenn Sie wissen wollen, wie das geht, fragen Sie nach. Für visuelle Elemente wie Videos kann eine Einwilligung zudem In-Place, also am Platze des Elements, abgefragt werden. Das nervige und seitenweit erscheinende Popup entfällt dann für das visuelle Element. Die zweite Möglichkeit ist, daran mitzuwirken, dass Website-Betreiber für Datenschutzverstöße verantwortlich gemacht werden. Dafür gibt es mehrere Eskalationsstufen, die Sie als Privatperson nutzen können:

• Deutliches Anschreiben per Mail mit Androhung weiterer Konsequenzen
• Nicht anonyme Beschwerde bei einer Aufsichtsbehörde (anonym bringt quasi nix, nicht anonym quasi fast nix)
• Berichterstattung
• Abmahnung als Privatperson
• Klage als Privatperson
• Verbandsklage (Verbraucherzentrale o. ä.)

Für viele Zwecke gibt es datenschutzfreundliche Lösungen. Hier eine Auswahl:

• Google Maps: Mein Karten-Plugin
• Google Analytics: Matomo
• Google Fonts: Schriften lokal einbinden
• Google Tag Manager: Kein Tag Manager oder Untagmanager
• Facebook Pixel: Besseren Marketing-Ansatz wählen
• Shopify: Anderes Shop-System (leider nicht anders möglich)
• Homepagebaukästen von Wix usw.: Deutschen Anbieter oder noch besser: Selber hosten auf deutschem Server
• Consent Tools von UserCentrics (Google Cloud), Cookiebot (Akamai) oder OneTrust (US-Mutter): Kein Consent-Tool oder eines von rein europäischem Anbieter+Speicher oder mein Consent-Tool, das nur das Nötigste kann (nämlich das, was eigentlich nur möglich ist).
• VG Wort Pixel: Hierfür gibt es eine gesetzliche Grundlage. Wer anderer Meinung ist, sollte die VG Wort anschreiben: datenschutz@vgwort.de und Metis.Support@vgwort.de
• Berater der bisherigen Bundesregierung: Neue Berater (vielleicht gibt es diese schon?). Fragen Sie doch mal nach: Ref-DP25@bmdv.bund.de (Bundesministerium für Digitales und Verkehr – Referat DP 25 – Datenschutz in der digitalen Welt, Cybersicherheit, Vertrauensdienste)

Welche Vorgänge auf Websites eine Einwilligung brauchen, ordnet der Überblick zu Cookies und Einwilligung ein.

Einleitung

Dieser Beitrag beleuchtet ein paar der 66 Gründe, die gegen eine Lösung per Einwilligungsverwaltungs-Verordnung aus § 26 TTDSG sprechen.

Die Gründe wurden mittlerweile in einem eigenen Beitrag veröffentlicht.

Zuletzt hielt ich am 16.09.2022 in Hannover anlässlich der Herbstakademie der Deutschen Stiftung für Recht und Informatik (DSRI) einen Vortrag zum § 26 TTDSG, der zentralen Einwilligungsverwaltung. Damit soll eine Plattform (zentrale Webseite oder Browser-Plugin) geschaffen werden, mit der Sie am besten einmalig Ihre Datenschutzvorlieben hinterlegen können. Später fragen Webseiten und Apps, die Sie aufrufen, diese Vorlieben zentral ab und nerven Sie nicht mehr mit Cookie Popups. So die Idee, die gut klingt, aber leider nicht zu Ende gedacht wurde. Sie wird nicht funktionieren, wie ich in mehreren weiteren Beiträgen belegen werde.

Aktuell diskutieren manche die Abfrage einer Generaleinwilligung als Lösung für eine zentrale Einwilligungsverwaltung. Diese Totschlag-Einwilligung soll, so schlagen es manche vor, in Form von Kategorien gestaltet sein. Welche Kategorien das sind und welche Inhalte diese haben sollen, wird nicht verkündet. Ungeachtet dessen, funktioniert das Konstrukt einer Totschlag-Einwilligung aus rein praktischen Gründen bereits nicht. Die rechtlichen Mängel lasse ich hier mal beiseite, obwohl sie bereits ausreichen würden, die Einwilligungsverwaltungs-Verordnung zunichte zu machen, sofern diese nur mit Kategorien statt mit Einzeleinwilligungen arbeitet. Immerhin hatte ein Forschungsgutachten so getan, als würde die Kategorien-basierte Totschlag-Einwilligung funktionieren, was zahlreich bestritten wird. Auch die angedachte Änderung der Gesetzeslage durch eine ePrivacy-Verordnung wird an der Problemlage wenig ändern. Zudem gibt es diese Verordnung nicht (wo ist sie?).

Bereits mehrfach hatte ich darüber geschrieben, warum es keine zentrale Einwilligungsverwaltung geben wird. Jedenfalls wird es keine Einwilligungsverwaltungs-Verordnung geben, die eine funktionierende Lösung hervorbringen könnte. Dafür gibt es sowohl rechtliche als auch technische Gründe. Zum Rechtlichen: Wir leben bekanntlich in Europa, was manche aus Deutschland noch nicht zur Kenntnis genommen haben.

Wer sich einlesen möchte, findet hier einige Beiträge, die zeigen, warum eine Einwilligungsverwaltungs-Verordnung kläglich scheitern wird:

• Warum die Zentrale Einwilligungsverwaltung in der Praxis nicht funktionieren kann
• Podcast: Cookies, Cookie Consent Tools, PIMS und Weltwunder
• Cookie Popups für Toaster
• Cookie-Umfrage. So funktioniert Lobbyismus
• Warum Browser-Voreinstellungen, Plugins oder eine zentrale Einwilligungsverwaltung keine Lösung sind

Die zentrale Einwilligungsverwaltung soll so funktionieren, kann aber so nicht funktionieren:

1. Sie besuchen eine zentrale Webseite. Dort geben Sie Ihre Datenschutzvorlieben an.
2. Dann besuchen Sie beliebige Webseiten, so wie bisher.
3. Jede von Ihnen besuchte Webseite soll nun die Zentrale nach Ihren Datenschutzvorlieben fragen und diese berücksichtigen.
4. Die Webseiten sollen dann kein böses Cookie Popup mehr anzeigen.
5. Wahlweise wurde ein Browser-Plugin oder ein Browser-Signal diskutiert:
   1. Das Plugin soll die Rolle der Zentrale übernehmen.
   2. Das Signal soll aus dem „Off“ rufen: „Nein, nein, nein! Der Besucher der Webseite will jetzt keine Gemeinheiten mit seinen Daten veranstaltet wissen“. Die besuchten Webseiten sollen sich dann daran halten (weil auch niemand vor einer Feuerwehrzufahrt parkt, wenn dort ein Verbotsschild aufgestellt ist, das ein negatives Signal sendet). Wir alle wissen, wie gut das Do not Track-Signal funktioniert hat (nur vorsichtshalber für alle, die dieses Signal nicht kennen: Do Not Track ist vollständig gescheitert).

Das Thema mit der zentralen Abfrage einer Einwilligung gewann wieder an Schwung, weil kürzlich vom zuständigen Bundesministerium ein Entwurf einer Einwilligungsverwaltungs-Verordnung erstellt wurde. Dieser Entwurf lag mir beim Schreiben dieses Beitrags nicht vor. Ich konnte nur Drittquellen dazu lesen.

Die Totschlag-Einwilligung

Diskussionen auf Social Media zeigten mir, dass ein zentrales Konzept der Einwilligungsverwaltungs-Verordnung die Totschlag-Einwilligung zu sein scheint. Dies ist eine Einwilligung in „Alles“ (Das Leben, das Universum und der ganze Rest) aus einer Kategorie. Im Gegensatz dazu wäre allerdings ein völliges Ablehnen aller nicht notwendigen Cookies und weiterer Verarbeitungsvorgänge praktisch machbar!

Das Gesamtkonstrukt eines Consent Hub (anderer Name für Privacy Hub, PIMS oder zentrale Einwilligungsverwaltung) kann nicht funktionieren. Es enthält unheilbare Mängel, wie ich an den beiden Möglichkeiten zeige, die einer Zentrale theoretisch jedenfalls generell zur Verfügung stehen: Abfragen von Einwilligungen für einzelne Vorgänge sowie Abfragen einer einzigen Einwilligung für alles. Ob „alles“ als Gesamtentität verstanden wird oder aufgeschlüsselt wird in eine handvoll Kategorien, spielt keine wesentliche Rolle.

Nun gibt es zwei Gruppen von Personen. Die eine hält sich an den Erwägungsgrund 32 zur DSGVO. Ebenda steht:

Eine Einwilligung sollte also (bzw. muss, sobald der EuGH es festgestellt hat, was in diesen komischen Sätzen von eben steht) für den konkreten Fall erteilt werden. Zum einen muss eine Einwilligung pro Zweck erfolgen können. Dient eine Verarbeitung mehreren Zwecken, muss eine Einwilligung für jeden dieser Zwecke erteilt werden (können), bevor die Verarbeitung dadurch legitimiert ist. Leider hat das Gutachten, welches das Wirtschaftsministerium in Auftrag gab, diesen Umstand nicht ausreichend berücksichtigt. Auch fehlen konkrete Beispiele im Gutachten.

Gehen wir spaßeshalber einmal davon aus, dass eine Generaleinwilligung erteilt werden darf bzw. genauer: Wir gehen davon aus, dass eine Frage nach einer Generaleinwilligung erlaubt ist, um die daraus resultierende Einwilligung als Rechtsgrundlage nutzen zu können. Diesen Fall betrachte ich nun folgend, auch wenn die ePrivacy-Verordnung dann scheitern wird, wenn eine Einwilligung in pauschale Kategorien angedacht ist. Hingegen ist ein Ablehnen aller nicht notwendigen Cookies praktisch möglich. Übrigens thematisiert die ePrivacy-Verordnung (irgendwann mal) doch Zugriffe auf Cookies, oder? Es geht dann doch wohl nicht um die Verarbeitung der Cookie-Daten, oder? Wissen Sie mehr als ich, dann bitte ich um eine Nachricht. Cookies setzen und erhalten, ohne deren Werte verarbeiten zu dürfen, ist nahezu sinnlos.

Konsequenzen einer Totschlag-Einwilligung

Bevor harte Argumente kommen, folgt eine generelle, eher moralische Einordnung. Die Moral spielt tatsächlich des Öfteren eine Rolle, wie das gleich genannte Beispiel zeigt. Ob der Begriff „Moral“ heißt oder „Verbraucherschutz“, sei dahingestellt. TLDR: Nächste Überschrift suchen.

Zunächst einmal halte ich eine Generaleinwilligung für menschenverachtend. Regelmäßig werden gesetzliche Regeln aufgestellt, um Verbraucher besser zu schützen. Oft muss der Verbraucher vor vorschnellen oder unüberlegten oder spontanen Entscheidungen bewahrt werden, deren Konsequenzen er zum Zeitpunkt der Entscheidungsfindung nicht absehen konnte. Ein Beispiel aus der Vergangenheit: Banken dürfen nicht mehr einfach so Allgemeine Geschäftsbedingungen ändern und ein Stillschweigen des Kunden als Zustimmung werten. Vielmehr müssen sie um eine Einwilligung bitten. Soweit ich weiß, dürfen Banken (auch) nicht eine Einwilligung von Ihnen erfragen, die es der Bank erlaubt, alles mit Ihrem (!) Geld zu machen, was die Bank will. Daten sind kein Geld, aber Daten sind der Rohstoff der heutigen Zeit, wie viele Beispiele zeigen.

Die Totschlag-Einwilligung, wie ich die Einwilligung in „alles“ hier auch nenne, ist jedenfalls verbraucherfeindlich. Sie ist zwar auch rechtswidrig, aber das wollen wir hier ja spaßeshalber mal ignorieren.

Möchten Sie gerne folgendes im normalen Leben gefragt werden?

Sicher will das niemand ernsthaft gefragt werden. Diejenigen, die sich an einer solchen Frage nicht stören, werden aber hoffentlich keine Generalvollmacht erteilen. Das Beispiel ist natürlich keine vollständige Analogie. Denn ausgeraubt zu werden (und dem hätten Sie ja womöglich zugestimmt) ist oft schlimmer als die Nutzung personenbezogener Daten zum Nachteil der betroffenen Person.

Wenn Sie eine Totschlag-Einwilligung für Ihre Daten erteilen, darf ich dann folgendes mit Ihren Daten machen?

• Weitergabe an beliebige Dritte;
• Weiterverarbeitung zu jedem beliebigen Zweck;
• Kombination mit beliebigen anderen Daten;
• Beliebig lange Speicherung;
• Weitergabe an Geheimdienste;
• Falschaussagen zu Ihren Daten machen (ich behaupte dann einfach, die Aussagen wären richtig)
• Ihre Daten löschen, obwohl die in einem fiktiven Fall zu Ihrem Nachteil ist. Wie wäre es damit: Sie buchen ein Hotelzimmer und wundern sich bei der Anreise, dass das Zimmer für Sie nicht bereitsteht. Das Hotel hat aufgrund Ihrer Generalvollmacht über Ihre Daten einfach Ihre Daten gelöscht (die rechtlichen Feinheiten, nämlich, dass ein Vertrag vorliegt, lassen wir hier mal für das überspitzte Beispiel beiseite).

Ihre Daten wären Ihr Name, Ihre Adresse, Ihre Bankdaten, Ihre Kreditkartendaten, Ihre gesundheitlichen Merkmale und Krankheiten, ebenso Ihre sexuellen Vorlieben (oft möchte man nicht alles dazu wissen).

Angenommen, Sie sind mit jedweder Nutzung Ihrer Daten einverstanden oder es gibt rechtliche Regeln, die dies trotz Generalvollmacht über Ihre Daten verhindern. Ich glaube das zwar nicht für alle eben genannten und weitere fehlende Fälle, aber nehmen wir es mal an.

Kommen wir zum nächsten spannenden Punkt, der mit der Einwilligung zusammenhängt.

Der Widerruf einer zuvor erteilten Einwilligung

Sicher sind sich alle einig, dass der Art. 7 Abs. 3 DSGVO besagt, dass jede Totschlageinwilligung widerrufen werden können muss.

Die Totschlageinwilligung wird von Ihnen als Person und Inhaber Ihrer Daten in der Zentrale, dem Content Hub, erteilt. Der Widerruf kann ebenfalls dort erfolgen. Dann allerdings könnte der Widerruf nur für „Alles“ erfolgen. Das will doch niemand. Es wäre sogar zum Nachteil von Datenschützern, wenn sie jedes Mal in „Alles“ einwilligen müssen, damit sie irgendwo ein Video sehen können, nur um danach „Alles“ widerrufen zu müssen. Dadurch sehen sie nach der Alles-Einwilligung nicht nur das Video, sondern werden auch noch von Google Analytics getrackt. Außerdem sehen sie nach dem Alles-Widerruf dann später gar nix mehr und müssen jedes Mal wieder einen Zirkus veranstalten.

Es ergibt also keinerlei Sinn, eine Generaleinwilligung nur vollständig widerrufen zu können. Die Nachteile für verantwortliche Betreiber von Webseiten und Apps, aber auch für Verbraucher wären wirklich immens. Diese Nachteile würden außerdem wieder Erwägungsgrund 42 zur DSGVO widersprechen („Es sollte nur dann davon ausgegangen werden, dass sie [die betroffene Person] ihre Einwilligung freiwillig gegeben hat, wenn sie eine echte oder freie Wahl hat und somit in der Lage ist, die Einwilligung zu verweigern oder zurückzuziehen, ohne Nachteile zu erleiden.“). Im Erwägungsgrund 43 steht noch einmal (!), dass es einfach Bullshit ist, eine Generaleinwilligung für das gesamte Universum einzuholen:

Kommen wir also zur nächstbesseren Möglichkeit des Widerrufs. Der Widerruf muss also auf einer besuchten Webseite möglich sein. So ist das bisher auch bzw. sollte es sein.

Nur nebenbei weise ich auf Satz drei des Art. 7 Abs. 3 DSGVO hin:

Die Widerrufsmöglichkeit sollte nicht nur an sich benannt werden. Es sollte im Consent Hub (PIMS) auch noch konkret geschrieben stehen, wie genau die Einwilligung widerrufen werden kann. Das leite ich aus dem vorhin genannten Satz des Erwägungsgrundes 42 ab. Der Widerruf einer Einwilligung muss genauso einfach wie die Erteilung der Einwilligung sein. Außerdem muss die Widerrufsmöglichkeit so gestaltet sein, dass die betroffene Person keine Nachteile erleidet. Man könnte das so regeln, indem auf jeder Webseite, die die Einwilligung als Rechtsgrundlage nutzt, an immer derselben Stelle (oder einer von beispielsweise zwei möglichen Stellen) mit derselben Beschriftung eine Widerrufsmöglichkeit angeboten wird. Nur so könnte eine zentrale Einwilligungsverwaltung diese Stelle auf ad hoc völlig unbekannten Webseiten kennen und benennen. Viel Spaß!

Zurück zum Kernthema, dem Widerruf einer erteilten Universaleinwilligung.

Teilwiderruf einer Totschlag-Einwilligung

Wie eben dargelegt, muss wenigstens der Widerruf spezifisch erfolgen können. Das bedeutet, eine betroffene Person möchte nicht mehr, dass Google Analytics gegen sie verwendet wird, möchte aber eine Videoeinbindung (nicht über Google/YouTube) weiterhin gestatten.

Der Widerruf für den Google Analytics-Teil der zuvor über die Zentrale erteilte Totschlag-Einwilligung kann also nur auf der gerade besuchten Webseite stattfinden. Warum das so ist, habe ich mehrfach beschrieben. Kurzfassung: Die Zentrale kann unmöglich alle einwilligungspflichtigen Dienste (Tools, Plugins, Scripte, Dateiabrufe, Datenverarbeitungen) kennen, die auf jeder Webseite, die für Deutschland relevant ist oder sein wird, schon eingesetzt werden oder noch eingesetzt werden werden (Ist das die Zukunftsform?).

Somit wird also eine Einwilligung in „Alles“ um genau ein Element verringert. Ich schreibe das mal pseudo-mathematisch:

E∞ \ W1 = E(∞-1)

Eine kurze Erklärung zur Formel, die ausdrückt, dass durch einen Einzel-Widerruf die Gesamteinwilligung um ein Element verringert wird:

• E_∞: Totschlag-Einwilligung in „Alles“, also in faktisch beliebig viele Elemente. beliebig viele = unendlich.
• \: Symbol für den Ausschluss eines Elements aus einer Menge (die Menge ist die Liste der nur abstrakt bekannten Elemente aus der Einwilligung). Quasi das Minuszeichen für Mengen.
• W₁: Widerruf der für Google Analytics erteilten Einwilligung.
• E_(∞-1): Die Einwilligung gilt nach Widerruf nun für alles abzüglich Google Analytics.

Ich bin kein Mathematiker, sondern Informatiker und sehe somit folgende Aussage als halbwegs gewagt an:

Mit Unendlichkeiten lässt es sich so schlecht rechnen. Rechnen ist bereits gegeben, wenn Einwilligungen verwaltet werden. Ungeachtet der Probleme mit dem Rechnen im Unendlichen haben wir bzw. hat der Consent Hub (= PIMS = Zentrale Einwilligungsverwaltung = § 26 TTDSG Konstrukt) noch ein Problemchen:

Nun müsste die an sich dumme Zentrale spätestens jetzt wissen, dass es Google Analytics gibt. Damit kommen wir wieder zum Grundproblem von vorhin:

Woher weiß eine zentrale Instanz (PIMS = Zentrale Einwilligungsverwaltung) eigentlich, welche einwilligungspflichtigen Vorgänge es jetzt schon und zukünftig auf allen deutschen Webseiten gibt und geben wird?

Antwort: Eine zentrale Instanz weiß es nicht. PIMS ist somit bereits aus rein theoretischen Gründen gescheitert. OK, Google-Dienste sind weit verbreitet. Aber kennen Sie den Dienst der australischen Firma QuantiHupf, mit der Kängurus und Koalas auf Webseiten abhängig von Ihrem Verhalten als Internetnutzer dargestellt werden?

Was ist mit Einwilligungskategorien?

Angenommen, ein Consent Hub fragt verbotenerweise für Kategorien nach Ihrer Einwilligung. Ignorieren wir mal, dass das europarechtswidrig ist. Sie stimmen also zu, dass alle Tools der Kategorie „Analyse“ gegen Sie verwendet werden dürfen.

Kategorien sind übrigens weder vorgeschrieben noch festgelegt. Sie sind eine willkürliche Festlegung, die durch Consent Tool Anbieter zustande kam.

Jetzt haben Sie in die Kategorie „Analyse“ eingewilligt. Damit werden YouTube Videos geladen, denn diese Videos sind im Beispiel dieser Kategorie zugeordnet worden, weil der YouTube Player das Verhalten von Website-Besuchern nachverfolgt.

Dann merken Sie, dass zur Kategorie „Analyse“ auch Google Analytics gehört. Nun wollen Sie dem widersprechen. Dumm nur, dass Sie entweder nur die gesamte Kategorie „Analyse“ zulassen oder die ganze Kategorie ablehnen können. Wäre es anders, dann gäbe es wieder das oben und in meinen anderen Beiträgen beschriebene Problem, dass eine zentrale Consent Plattform leider nicht weiß, welche Tools und Plugins es da draußen so gibt.

Kategorien sind unbekannt

Kategorien, in die eingewilligt werden soll, sind sowohl namentlich als auch inhaltlich unbekannt. Niemand kennt diese Kategorien. Niemand. Kategorien sind eine Erfindung einzelner Marktteilnehmer.

Cookie Tool-Anbieter haben selbst völlig willkürlich irgendwelche Kategorien erdacht. Hier eine beispielhafte Aufzählung:

• Unbedingt erforderlich
• Statistik
• Marketing
• Leistung
• Sonstige

Oft werden die Bezeichnungen mit dem Suffix „-Cookie“ versehen. Was ein Leistungs-Cookie ist, weiß nicht jeder, vermute ich mal.

Eine Kategorie kann nicht die Wirklichkeit abbilden. Genauso wenig kann die objektorientierte Programmierung die Wirklichkeit abbilden. Das Problem bei beiden: Welche Kategorie darf es denn sein, wenn ein Tool in mehrere Kategorien reinpasst? Spoiler: Es gibt keine befriedigende Lösung (auch in der Objektorientierung nicht, worüber ich damals meine Doktorarbeit geschrieben habe).

Nun stelle ich mir folgende Fragen?

• Woher weiß der Betreiber einer zentralen Einwilligungsverwaltungs-Plattform, welche Kategorien es gibt und welcher Dienst jeweils welcher Kategorie zuzuordnen ist?
• Woher wissen Sie als Betreiber einer Webseite und Ihre Millionen Leidensgenossen eigentlich, welche Dienste welchen Kategorien zuzuordnen sind?

Ein plastisches Beispiel hierzu:

Sie möchten den Google Tag Manager einsetzen. Gehen wir mal davon aus, dass er einwilligungspflichtig ist, was ich behaupte. Ein Besucher Ihrer Webseite hat zuvor in der Zentrale in die Kategorie „Marketing“ eingewilligt. Dürfen Sie nun den Google Tag Manager laden? Liegt also hierfür eine Einwilligung vor?

Immerhin ordnet Google den Google Tag Manager (GTM) der Google Marketing Platform zu. Ich habe schon einige Consent Banner gesehen, in denen der GTM stattdessen einer anderen Kategorie zugeordnet war, beispielsweise Sonstige.

Was verbirgt sich eigentlich genau hinter der Kategorie Sonstige? Könnten Sie mir das bitte rechtssicher erklären?

Anbieter sind oft unbekannt

Nun könnte man statt den eben genannten schwammigen und völlig undefinierten Kategorien die Anbieter von Diensten als eine Art Kategorien nehmen. Beispielsweise „Google Dienste“. Ein PIMS würde also um Erlaubnis bitten, dass alle Tools vom Anbieter „Google“ geladen werden dürfen.

Könnten Sie mir bitte etwas genauer erklären, was Sie unter „Google“ verstehen? Wenn ich in meinen Beiträgen von „Google“ spreche, meine ich den Google-Konzern. Ich muss allerdings keine Pflichtinformationen gemäß Art. 12 DSGVO bereitstellen, was Google angeht. Sie als Website-Betreiber müssen das sehr wohl. Fragt die Zentrale also jetzt nach einer Einwilligung für

a) Google Ireland Ltd., oder für

b) Alphabet Inc., oder für

c) Google LLC., oder für

d) alle vier zusammen?

Wie Sie womöglich wissen, macht es schon einen Unterschied, wer der Anbieter ist. In jedem Land herrschen schließlich andere Gesetze, und manche Länder sind EU-Mitglieder, andere nicht. Auch gebietet es die DSGVO, dass der genaue Anbieter (Firmierung = Firmenname, Adresse, Land) bekannt ist.

Wer nimmt also die rechtliche Bewertung für jeden Anbieter eines Dienstes vor, wenn der Anbieter mehrere Standorte weltweit hat? Und wer findet die Anbieterdaten für jeden Dienst heraus? Ich freue mich schon auf das Chaos mit PIMS und die Ausreden derer, die PIMS befürwortet hatten.

Dienste sind in ihrer Gesamtheit unbekannt

Selbst die Einwilligungsabfrage nach einzelnen Diensten, die rechtskonform wäre, kann nicht funktionieren. Die Gründe habe ich in einigen weiter oben verlinkten Beiträgen genannt.

In Kürze, sei hier nur gesagt: Niemand weiß, welche Dienste für Webseiten, Apps und Smart Home Geräte es gibt. Ein Dienst ist ein Tool, Plugin, Script oder auch nur eine Datei, die von einem Dritt-Server geladen wird.

Angenommen, Sie wüssten, welche Dienste es weltweit gibt, die für deutsche Webseiten relevant sind. Wissen Sie dann auch, welche dieser Dienste einwilligungspflichtig sind? Können Sie jeden Dienst einer Kategorie zuordnen (sofern Sie mit Generaleinwilligungen arbeiten wollen)? Über Cookies brauchen wir hier noch gar nicht zu sprechen (aber später dann schon).

Angenommen, die Liste der Dienste wäre vollständig vorhanden. Wie sieht es morgen aus, wenn Hersteller Y aus Land Z ein neues Tool auf den Markt bringt?

Die Idee, dass sich Anbieter von Diensten bei der Zentrale registrieren sollen, verfängt nicht. Der australische Anbieter eines Dienstes wird die Details der Einwilligungsverwaltungs-Verordnung nicht kennen. Warum sollte ein Anbieter überhaupt die Zentrale über seinen Dienst informieren? Bekommt er dafür Geld? Darf der Dienst nicht mehr geladen werden, wenn die Zentrale ihn nicht kennt? Wer sanktioniert Verstöße eigentlich?

Weitere strukturelle Probleme

Der § 26 TTDSG bezieht sich nur auf § 25 TTDSG. Das bedeutet:

Ein Consent Hub nach § 26 TTDSG kann nur Einwilligungen abfragen, die das Setzen oder Auslesen von Cookies legitimieren.

Eine solche PIMS-Zentrale kann aber grundsätzlich NICHT legitimieren, dass die Werte aus Cookies verarbeitet werden dürfen. Dies fällt nämlich nicht in den Anwendungsbereich des Art. 6 DSGVO. Ebenso kann eine PIMS nicht über Einwilligungen aus Art. 49 DSGVO verfügen. Dort geht es um Datentransfers in die USA („Schrems II“) und andere Drittländer ohne ausreichendes Datenschutzniveau.

Ein Browser-Plugin wird die genannten Probleme auch nicht lösen (warum auch?). Zudem muss für JEDEN Browser auf JEDEM Endgerät ein Browser-Plugin bereitgestellt und von Ihnen installiert werden. Sie müssen dann jedes Mal Ihre Datenschutzeinstellungen im Plugin definieren. Ich habe ca. 15 Browser auf 5 verschiedenen Endgeräten. Wie viel Spaß würden Sie mit einem Browser-Plugin haben? Erklärt mir mal jemand, wie ein Browser-Plugin die Kontrolle über eine native Smartphone App übernehmen soll? Bullshit bleibt Bullshit.

Insgesamt 66 Argumente und kritische Punkte, die gegen eine PIMS sprechen, werde ich in Kürze veröffentlichen. Dafür suche ich einen Musiker, der ein (einfaches) Lied analog zu „666 is the number of the beast“ (Song von Iron Maiden) beisteuern möchte und der gerne namentlich in meinem erscheinenden Beitrag „66 is the number of the PIMS“ genannt werden wird.

Fazit

Wie man es auch dreht und wendet: Ob mit Einwilligungskategorien oder nur einer Superkategorie ("Alles“) oder mit einzelnen Diensten, für die nach einer Einwilligung gefragt wird: Es funktioniert schon aus rein logischen Gründen nicht. Man muss hierzu noch nicht einmal die Rechtswissenschaft bemühen.

Ein Consent Hub ist Bullshit. Es gibt zwei grundsätzliche Ansätze, die beide rechtswidrig zu sein scheinen. Ignoriert man die Rechtswidrigkeit an manchen Stellen, entsteht oder bleibt Rechtswidrigkeit an anderen Stellen. Weiterhin entstehen somit praktisch unlösbare Probleme, wie ich vielleicht zusätzlich mithilfe der etwas überspitzten Unendlichkeitsrechnung zeigen konnte.

Entweder eine zentrale Einwilligungsverwaltung versucht, für jede Datenverarbeitung einzeln eine Einwilligung zu erfragen, so wie es vorgeschrieben ist. Dann stellt sich die Frage, woher die Zentrale dieses Wissen nehmen will. Wahrscheinlich weiß es nur die United Internet AG samt Lobbyisten.

Oder eine zentrale Einwilligungsverwaltung fragt noch rechtswidriger nach einer Generaleinwilligung. Dann klappt das aber mit dem Widerruf leider nicht so doll.

Die Einwilligungsverwaltungs-Verordnung sollte also am besten verordnen, dass § 26 TTDSG abgeändert wird oder wegfällt.

Ganz nebenbei erwähne ich, dass sich wohl niemand mehr Mühe geben wird, Gesetze einzuhalten, wenn die Sanktionen sich auf dem gleichen Niveau bewegen werden wie bisher. Es wäre schon fraglich, ob jemand den gleichen Aufwand wie bisher betreiben würde, um unter dem kastrierten Sanktionsregime in Deutschland zukünftig die rechtlichen Regeln einzuhalten. Warum dann plötzlich mehr Aufwand betreiben?

Nahezu jede deutsche Webseite ist meiner Ansicht nach rechtswidrig, weil Datenschutzregeln nicht eingehalten werden. Ganz bestimmt wird das besser, wenn eine Einwilligungsverwaltungs-Verordnung kommt. Die meisten bekommen schon vom Wort Angst.

Nur vorsichtshalber erwähne ich, dass das Einbinden von sogenannten Cookie-Tools keine Lösung für das Problem mit der Einwilligung ist. Siehe meine Cookie Tool-Praxistests.

Die einzige Lösung aus dem „Cookie Popup-Dilemma“ ist mehr oder weniger einfach: Webseiten sollten keine einwilligungspflichtigen Vorgänge verwenden. Für visuelle Elemente, wie Videos oder interaktive Karten, kann eine Einwilligung direkt vor Ort, am Platz der Anzeige, eingeholt werden. Ein Popup ist dafür also nicht nötig. Die interaktive Karte funktioniert allerdings auch ganz ohne Einwilligung, wenn das richtige Plugin verwendet wird.

PS: Wie mir von jemandem mitgeteilt wurde, der eine Anfrage an das Bundesministerium für Digitales und Verkehr – Referat DP 25 – Datenschutz in der digitalen Welt, Cybersicherheit, Vertrauensdienste geschickt hatte, kann es wohl aufgrund des Regelprozesses noch eine ganze Weile dauern, bis die Einwilligungsverwaltungs-Verordnung offiziell das Licht der Welt erblicken wird. Es besteht also noch Hoffnung, diesen Unsinn zu stoppen.

Wie Einwilligungen auf Websites heute wirksam eingeholt werden, beschreibt die Übersicht zu Cookies und Einwilligung.

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:

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/). 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).

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.

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:

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:

• Untersuchung der aepd (spanische Datenschutzbehörde) zu Device Fingerprinting: https://www.aepd.es/sites/default/files/2019-09/estudio-fingerprinting-huella-digital-EN.pdf
• Untersuchung der Electronic Frontier Foundation (EFF): „How unique is your browser”: https://coveryourtracks.eff.org/static/browser-uniqueness.pdf

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).

Welche Alternativen es gibt und wie Sie Ihre Website selbst prüfen, zeigt die Übersicht zu Cookies und Einwilligung.

Einleitung

Auch ohne Gerichtsurteil leuchtet es ein, dass die Lieferung personenbezogener Daten an ein weltweit tätiges Unternehmen wie Google, das Daten zur extensiven Nutzerprofilbildung verwendet, an sich rechtswidrig ist. Das gilt umso mehr, wenn diese Datenlieferung durch den Einsatz einer Alternative vermeidbar ist.

Genau so verhält es sich mit Google Fonts. Google Fonts sind Schriftarten für Webseiten, die von einem Google Server abgerufen werden. Es handelt sich um Schriftarten freier Designer, die nichts mit Google zu tun haben. Google stellt eine Infrastruktur bereit, über die Designer ihre Schriften hochladen und Webseiten die Schriften danach einbinden können. Nicht mehr und nicht weniger, jedenfalls, was Ersteller und Nutzer der Schriften angeht. Google selbst freut sich über die zahlreichen Signale von Internetnutzern, die beim Abruf der Google Fonts zustande kommen. Damit können wunderbar Nutzerprofile gebildet werden, mit denen personalisierte Werbung noch besser verkauft werden kann.

Das LG München entschied am 20.01.2022 (Az.: 3 O 17493/20), dass der Abruf von Google Fonts rechtswidrig ist. Denn dabei wird die IP-Adresse des Webseitenbesuchers an Google übertragen. Die IP-Adresse ist ein personenbezogenes Datum. Das gilt auch für die dynamische IP-Adresse. Siehe EuGH- und BGH-Urteile „Breyer“ (EuGH-Urteil vom 19.10.2016 – C-582/14, BGH-Urteil vom 16.05.2017 – VI ZR 135/13). Google wiederum ist ein amerikanisch geführtes Unternehmen. Das widerspricht der DSGVO. Siehe Art. 49 DSGVO, das EuGH-Urteil „Schrems II“ sowie die Tatsache, dass die USA ein DSGVO-widriger Überwachungsstaat sind (EO 12333, FISA 702, Cloud Act).

Bereits ein Jahr vor dem Urteil habe ich ausführlich untersucht, dass es mildere Mittel für Google Fonts gibt. Es ist wirklich „einfach“, die Schriften herunterzuladen, auf den eigenen Server hochzuladen und von dort einzubinden. Klingt nicht nach Raketenwissenschaft. Für den Fall, dass das jemandem zu kompliziert ist: Pech gehabt, Experten suchen. Wer keinen Parkplatz findet oder zu weit weg vom Ziel, darf auch nicht falsch parken. Steuererklärung zu kompliziert? Einfach nicht abgeben, oder wie war das? Kein Geld mehr? Bank überfallen. Einfach die Gesetze bestmöglich einhalten. Die Ausreden interessieren niemanden (jedenfalls mich nicht).

Anschreiben wegen Google Fonts

Einige Trittbrettfahrer nutzten die Gelegenheit, Betreiber von Webseiten mit einem Schreiben zu bedenken, weil auf den jeweiligen Webseiten Google Fonts (in rechtswidriger Weise) eingebunden waren.

Das Schreiben hat meist seine Berechtigung. Jemand hat sich ein Progrämmchen geschrieben und massenweise Webseiten abgegrast, um Opfer zu finden. Technisch weniger versierte Personen haben einfach selber zahlreiche Webseiten aufgerufen und schnell manuell geschaut, ob dort Google Schriften eingebettet waren. Weil viele Webmaster oder Agenturen leider die falschen oder keine Berater hatten, wird man auf der Suche nach Datenschutzfehlern schnell fündig.

Ein Trittbrettfahrer ist in diesem Fall jemand, der Webseitenbetreiber anschreibt, obwohl er deren Webseite eigentlich gar nicht besucht hätte. Es geht demjenigen "nur" darum, Ärger zu machen. Hier ein Auszug eines Schreibens von Loris Bachert:

Herr Bachert fordert, dass der Datenschutzverstoß abgestellt und eine Unterlassungserklärung abgegeben wird. Letztere ist strafbewehrt. Als Vertragsstrafe sind "bis zu 3.000 €" angegeben, eine wie ich finde sehr merkwürdige Formulierung. Das Schreiben ist als PDF-Anhang zu einer Mail gestaltet.

Ein anderes Schreiben stammt vom Serienschreiber Vernis Jankovskis. Es sieht so aus:

Hierin wird ein Betrag von 100 Euro per Banküberweisung gefordert. Danach sei die Sache erledigt.

Ein ähnliches Schreiben stammt von Susanne Schober. Es sieht so aus:

Auch hierin werden 100 Euro verlangt, damit die Sache sich erledigt. Genau wie im vorigen Schreiben wird die betreffende Webseite nicht direkt genannt, sondern mit einem merkwürdigen Link (safelinks.protection.outlook.com), der auf eine Copy & Paste Vorgehensweise hindeutet.

Jedesmal wird auf das Urteil des LG München hingewiesen.

Selbst in Österreich mahnen Privatpersonen Unternehmen bzw,. Betreiber von Webseiten ab. Eine Person nennt sich Eva Z., wie mir von einem Leser aus Österreich berichtet wurde. Der Leser berichtete mir auch, dass in seinem Webserver-Protokoll quasi zeitgleich zum Zugriff durch Eva Z. ein Zugriff durch einen Bot mit der technischen Kennung "SEO Scanner" erfolgte. Es sieht also danauch aus, und das berichten auch andere, dass manche Abmahner einen Crawler benutzen, um automatisiert Opfer zu finden.

Übrigens arbeiten manche Anwaltskanzleien mit Privatpersonen zusammen, um Geschäfte zu generieren. Das Vorgehen ist immer gleich:

1. Privatperson P schreibt Webseitenbetreiber an, entweder mit Bitte um Zahlung von X Euro oder mit Abmahnung
2. Anwaltskanzlei A schreibt einen Beitrag. Darin erwähnen Sie die Abmahnung durch Person P und bieten ihre Hilfe an. So finden Hilfesuchende über Suchmaschinen die Dienstleistung von A, wenn sie von P abgemahnt wurden.
3. A und P teilen sich den Gewinn

Schritt 3 entfällt manchmal, weil A und P unabhängig voneinander sind und A auf der gleichen Welle surft, die P hervorgerufen hat.

Empfehlungen

Zunächst sind die Anliegen an sich berechtigt. Google Fonts einzusetzen, bedeutet einen Datenschutzverstoß. Wenn die Schriften erst nach Einwilligung geladen werden, ist das was anderes. Aber was soll das? Niemand tut so etwas und die meisten könnten es nicht einmal realisieren, selbst wenn sie es wollten.

Daher die erste und wichtigste Empfehlung: Entfernen Sie Google Fonts von Ihrer Webseite. In einem eigenen Beitrag beschreibe ich, wie vorzugehen ist. Vorher kommt aber Empfehlung Nummer null: Führen Sie einen Webseiten-Check durch:

Sie können auch im Firefox Browser die Taste F12 drücken, um die Entwicklerkonsole einzublenden. Danach rufen Sie Ihre Webseite auf. Dann schauen Sie in der Entwicklerkonsole im Karteireiter Netzwerkanalyse, ob Dateien von fonts.googleapis.com o. ä. abgerufen werden.

Achtung: Auch Google Maps und Google reCAPTCHA laden Google Fonts nach. Zwar ist die Sachlage hier anders als beim direkten Laden von Google Fonts. Aber wahrscheinlich wollen Sie nicht unnötigerweise herausfinden, wer im Recht ist.

Haben Sie das Gefühl, ein Standardanschreiben erhalten zu haben, dann antworten Sie nicht darauf, ist meine zweite Empfehlung. Ein PDF-Anhang gilt übrigens nicht als zugestellt, wenn die Mail als zugestellt gilt, die den Anhang enthält. Sie brauchen hierfür (bis auf Weiteres) keinen Anwalt.

Enthält Ihre Webseite keinerlei Google Fonts und wurden sie somit zu Unrecht abgemahnt, dann denken Sie darüber nach, den Abmahner wegen rechtsmissbräuchlicher Abmahnung selbst abzumahnen.

Mittlerweile kursieren sogar Musterantwortschreiben von Anwaltskanzleien. Die Kanzlei bietet Ihnen gleich noch ein Rundum-Sorglos-Paket für 249 Euro (netto = 296,31 Euro brutto) an. Dafür antwortet die Kanzlei mit einem Schreiben auf das Anschreiben. Die weiteren Leistungspunkte (Prüfung der Abmahnung, ggf. Abgabe einer Unterlassungserklärung, Vergleichsverhandlung sofern Zahlung sinnvoll erscheint) scheinen bei den Trittbrettfahrern aus meiner Sicht nicht nötig zu sein bzw. laufen auf ein Antwortschreiben hinaus.

Wenn jemand Sie redlich anschreibt, etwa ich (was ich gelegentlich tue, wenn ich Probleme mit produktiv besuchten Webseiten habe), dann sollten Sie das Schreiben ernst nehmen. Wirklich! Bei den o.g. Anschreiben ist das aber wohl nicht der Fall. Wenn Sie ein ernst gemeintes Schreiben nicht ernst nehmen, kommt oft viel Ärger auf Sie zu. Ich kenne mindestens zwei Leute, die nicht vor einer Abmahnung oder Klage zurückschrecken, weil sie eine respektlose Behandlung bei höflichem Anschreiben nicht dulden.

Wenn Sie jemand abmahnen wird, der das massenweise tut, handelt er wahrscheinlich rechtsmissbräuchlich. Auch auf diese Abmahnungen sollten Sie dann eher nicht reagieren. Im schlimmsten Fall kommt es zur Klage. Ein Massenabmahner hat aber andere Ziele als Klagen zu führen. Er möchte die niedrig hängenden Früchte ernten. Selbst eine erfolgreiche Klage wird Ihr Unternehmen nicht ruinieren, dafür aber für mehr Rechtssicherheit in Datenschutz-Deutschland sorgen.

Bei einer Klage wiederum stehen die Chancen gut, dass der Kläger nicht beweisen kann, dass er Ihre Webseite aufrief und dass dabei Google Fonts eingebunden waren. Bei hunderten abgearbeiteten Webseiten, deren Betreiber dann angeschrieben wurden, lohnt der Aufwand der Beweissicherung nicht.

Wenn nur jeder zehnte die 100 Euro zahlt, sind das 10 Euro kalkulatorische Einnahmen pro Google Fonts Fall. Würden Sie für 10 Euro eine gerichtsfeste Beweissicherung betreiben? Ich jedenfalls nicht (ich würde es für null Euro tun, nämlich dann, wenn mir die Sache wirklich wichtig ist, wie etwa bei der Webseite gesetze-bayern.de. In dem Fall antwortete der Datenschutzbeauftragte auf meine informelle Rüge des unerlaubten Datentransfers in die USA mit dem Hinweis, man werde demnächst die Datenschutztexte anpassen. Nun warte ich auf die Beantwortung meines fünfseitigen Auskunftsgesuchs gemäß Art. 15 DSGVO, dessen Beantwortung ich nötigenfalls einklagen werde, um danach die Klage für den gerügten Datenschutzverstoß samt weiterer dann gefundener Verstöße auf den Weg zu bringen).

Cookie Tools statt echter Maßnahmen

Ist Ihnen das mit dem Google Fonts Dings zu kompliziert? Sie wollen lieber einfach nur eines dieser tollen Cookie-Tools auf Ihrer Webseite einbinden, damit die Welt danach in Ordnung ist. Sie glauben also an das achte Weltwunder.

Gehen Sie in die Kirche, wenn Sie glauben wollen. Oder lesen Sie die Bibel. Cookie Tools taugen rein gar nichts, um das Google Fonts Dings loszuwerden.

Cookie Tools werden auch als Consent Tools, Cookie Blocker, Consent Management Platform (CMP) oder Cookie Popups bezeichnet. Egal, wie der Begriff auch lautet: Diese Cookie-Tools taugen nicht viel. Sie funktionieren erst recht nicht für Google Schriften. Google Schriften nutzen nämlich gar keine Cookies. Wenn ein Cookie Tool die Google Schriften auf Ihrer Webseite blockieren würde (was nicht passiert), dann sähe Ihre Webseite ganz schön traurig aus. Das wollen Sie doch auch nicht.

Um Google Fonts abzuschalten, müssen Sie Ihre Webseite anpassen. Dazu müssen Sie in die Technik eingreifen. Haben Sie eine Agentur oder einen Webmaster, dann muss dieser Zuständige die Anpassung vornehmen, am besten auf eigene Rechnung. Denn wenn eine Agentur Ihnen Google Fonts auf die Webseite jubelt, ohne dass Sie das bestellt haben, dann hat die Agentur wohl was falsch gemacht.

Weigert sich Ihre Agentur, die Anpassung auf eigene Kosten vorzunehmen oder redet sich raus, dann würde ich Ihnen einen Agenturwechsel empfehlen. Vielleicht finden Sie ja eine Person, die sich mit Datenschutz und Technik auskennt.

Übrigens haftet die Agentur oder der Webmaster oft mit Ihnen zusammen, wenn Sie wegen eines Datenschutzverstoßes auf Ihrer Webseite belangt werden. Denn meist haben Sie das Problem selbst nicht verursacht. Und von einem Webseiten-Dienstleister wird wohl jeder erwarten können, dass die Webseite nicht durch Probleme verunstaltet wird, die leicht zu vermeiden sind. Wenn Sie Ihr Auto in die Werkstatt zur Inspektion bringen, dann erwarten Sie doch auch, dass das Auto danach besser, mindestens aber genauso gut wie vorher funktioniert und natürlich StVO-konform ist. Genauso verhält es sich mit Webseiten und der DSGVO. Anders kann es nur sein, wenn die Haftung der Agentur über einen Individualvertrag weitgehend ausgeschlossen wird. Über AGB kann man schlecht in rechtskonformer Weise vereinbaren, dass man als Agentur nicht für Problemchen wie Google Fonts haftet. Hierzu bedürfte es wohl eines Individualvertrags.

Was ist mit Google reCAPTCHA und Google Maps?

Sowohl Google reCAPTCHA als auch Google Maps laden Google Fonts nach. Beide Dienste können durch datenschutzfreundliche Alternativen ersetzt werden.

Google Maps etwa kann durch eine interaktive Karte auf Basis von OpenStreetMap ersetzt werden. Siehe meinen Konfigurator für interaktive Karten. Das funktioniert sogar für die Anzeige mehrerer Standorte auf einer einzelnen Karte. Vielleicht reicht Ihnen aber auch einfach ein Button mit der Beschriftung „Anfahrt planen“.

Statt Google reCAPTCHA als Formularschutz kann ein Eingabefeld mit Rechenaufgabe in Textform, ein Plugin wie Contact Form 7 Image Captcha oder eine PHP-Lösung genutzt werden. Weitere Möglichkeiten findet der, der sucht. Meine CAPTCHA-Lösung habe ich mal angefangen, aber bis jetzt noch nicht fertiggestellt. Es kamen immer andere Dinge dazwischen. Jedenfalls weiß ich, dass eine CAPTCHA-Lösung auch ohne Google möglich ist und kann es nötigenfalls auch beweisen (falls es mal vor Gericht geht).

Es gibt also mildere Mittel für beide Google Plugins. Beide Plugins funken Daten an Google, und somit ist bereits hypothetisch ein Zugriff für amerikanische Behörden möglich. Dies reicht laut Beschluss der Vergabekammer Baden-Württemberg vom 13.07.2022 (Az. 1 VK 23/22) aus, damit die DSGVO bedroht ist. Analog hatte der EuGH übrigens im IP-Adressenurteil „Breyer“ bereits im Jahr 2016 geurteilt. Es reicht aus, dass objektiv die Möglichkeit besteht, zu einer Netzwerkadresse den Anschlussinhaber zu ermitteln. Auch Sie als Webseitenbetreiber haben diese objektive Möglichkeit. Es reicht ja, wenn einer Ihrer Besucher straffällig wird und Sie eine IP-Adresse herausgeben müssten. Hoffentlich speichern Sie diese IP-Adressen nicht anlasslos in Server Logs, denn das ist nach meiner Untersuchung nicht mit der DSGVO vereinbar.

Was Google angeht, könnte man auch noch anführen, dass diese Datenkrake selbst erklärt (siehe Datenschutzhinweise von Google) sämtliche erhaltenen Daten auch für eigene Zwecke, wie etwa personalisierte Werbung, zu nutzen.

Exkurs: Shopify

Vorweg: Ich kann Shopify nicht empfehlen, kenne es aber auch nicht besonders gut. Was mir nur an den paar Shopify-Shops aufgefallen ist, die ich untersuchen durfte: Sie alle hatten größere, teils unheilbare Probleme mit dem Datenschutz. Das fing an bei einem unbrauchbaren Cookie-Addon und hörte nich auf bei einer recht technischen Ausgestaltung, die Anpassungen schwierig macht.

Shopify hat anscheinend wenigstens erkannt, dass Google Fonts keine gute Idee mehr sind. Das leite ich aus folgender Meldung ab, die in der Admin-Oberfläche eines Shopify-Shops erscheint:

Besonders bedienfruendlich ist die Empfehlung nicht. Erstmal ein Asset anlegen. Aber nicht mal das geht einfach. Denn "adding a new asset" ist kein Link, sondern nur ein Text. Wer ahnt schon, dass sich hinter diesem Pseudocode die Google Fonts Deklarationen verbergen?

{% render 'css-variables' %}

Anscheinend war das nicht die einzige Stelle, sondern nur eine von dreien in dem Shop, den ich mir im Auftrag anschauen durfte. Eine weitere Stelle war noch etwas versteckter. Sie lautete {% include 'appikon-discounts' %}. Statt Google Fonts am besten gleich Shopify ersetzen, das geht schneller und ist sicherer.

Fazit

Wenn Sie keinen Ärger haben wollen, nutzen Sie keine Google Dienste auf Ihren Webseiten. Auch keine von Facebook usw. Um Missverständnisse zu vermeiden: Es geht um Plugins für Ihre Webseite. Wenn Sie unbedingt den Google Maps Routenplaner nutzen wollen, obwohl er oft falsche Reisezeiten berechnet, ist das Ihre Sache. Sie könnten auch den Service von Graphhopper nutzen. Um den Ärger maximal zu reduzieren, sollten Sie einen Webseiten-Check durchführen. So sehen Sie sofort, was eine erste Prüfung der Startseite und weiterer Unterseiten zutage fördert.

Wenn Sie Ärger haben wollen, nutzen Sie Google Fonts und andere kritische Plugins weiterhin.

Wenn Sie noch mehr Ärger haben wollen, nutzen Sie zusätzlich ein Consent Tool.

Und wenn Sie viel Ärger haben und viel Geld dafür ausgeben möchten, dann beauftragen Sie einen Dienstleister oder Berater oder Anwalt, der entweder wenig von Technik oder wenig von Datenschutz oder wenig von beidem versteht.

Das Problem mit den Cookie Popups

Wie oft habe ich schon über sogenannte Cookie Popups berichtet, die auch als Cookie Tools, Cookie Blocker oder Consent Management Platform (CMP) bezeichnet werden. Sie alle sorgen nicht dafür, dass rechtskonforme Webseiten entstehen. Das einzige, was sie mehr oder weniger rechtssicher können, ist die Verwaltung einer Zustimmung (Einwilligung) oder Ablehnung eines Besuchers einer Webseite. Das bedeutet, das Cookie Tool speichert für Sie, ob ein Nutzer eingewilligt hat und wenn ja, wann. Viel mehr dürfen Sie von einem Cookie Tool nicht erwarten.

Die Liste der Unzulänglichkeiten von Cookie Tools ist so lang, dass ich hier nur eine kurze Aufzählung bringen kann:

• Es geht nicht nur um Cookies. Die meisten Cookie-Tools tun aber so, als ginge es nur um Cookies. Es geht auch um IP-Adressen, Datentransfer in die USA, Nutzerprofilbildung sowie ausufernde Datenverarbeitungen (vgl. Art. 5 DSGVO oder Art. 25 DSGVO).
• Google Fonts können von Cookie Tools faktisch nicht blockiert werden, müssten es aber. Sonst kann ein Schadenersatzanspruch gegen Sie entstehen.
• Datenabrufe von amerikanischen Firmen oder Servern oder von Firmen mit amerikanischer Mutter können von Cookie Tools faktisch nicht zuverlässig blockiert werden, müssten es aber. Vergleiche EuGH-Urteil Schrems II, Art. 44 ff DSGVO und die Tatsache, dass die USA ein Überwachungsstaat sind (Cloud Act, EO12333, FISA 702)
• Sogenannte Cookie Blocker können aus rein technischen Gründen nicht zuverlässig funktionieren.
• Die Pflichtinformationen auf Cookie Popups sind oft mangelhaft. Grund: Niemand weiß, was Google & Co. mit unseren Daten macht. Wie soll es dann ausgerechnet vom Anbieter einer Cookies Popups für Sie als verantwortlichem Webseitenbetreiber erklärt werden können?
• Alle Cookie Tools sind Versager. Siehe meinen umfangreichen Testbericht.

Wenn Sie also eine Webseite mit Cookie Popup aufrufen, werden bereits beim Aufruf, ohne dass Sie eine Aktion ausgeführt haben, oft schon rechtswidrige Datenverarbeitungen vorgenommen.

Zentrale Einwilligungsverwaltung (PIMS)

Auf Druck von Lobbyisten entstand der § 26 TTDSG. Der deutsche Gesetzgeber hat sich darin zwei Jahre Zeit gegeben, also bis Ende 2023, eine Verordnung für eine zentrale Einwilligungsverwaltung zu erlassen. Die Idee ist, Cookie Popups weitgehend zu eliminieren. Sie sollten zentral an einer noch zu schaffenden Stelle Ihre Datenschutzvorlieben hinterlegen können. Besuchen Sie dann eine Webseite, soll diese Webseite die Zentrale abfragen, um das Cookie Popup nicht mehr anzeigen zu müssen.

Niemand weiß, wie das funktionieren soll. Die Wahrheit ist, dass es nicht funktionieren kann und nicht funktionieren wird. Hierfür gibt es neben großen europarechtlichen Problemen auch rein praktische Probleme. Siehe hierzu meine Beiträge:

• Zentrale Einwilligungsverwaltung: Darum funktioniert die Idee nicht
• Podcast zu PIMS
• Cookie-Umfrage von GMX: Lobbyismus in eigener Sache

Zahlreiche weitere Kritikpunkte habe ich dabei nicht einmal thematisiert. Demnächst halte ich einen Vortrag hierzu vor einem Fachpublikum. Bin gespannt, wer mir erzählt, wie PIMS in der Realität funktionieren soll.

Der Privatmodus im Browser

Dieser Abschnitt ist nur relevant, wenn Sie keinen Google Browser nutzen. Denn dann wäre sowieso alles zu spät (siehe Folgeabschnitt).

Zum Privatmodus schreibt Mozilla als Anbieter des Firefox-Browsers selbst:

Der Privatmodus macht also niemanden anonym. Lediglich, aber immerhin, verspricht Mozilla, dass keine Chronik der besuchten Webseiten geführt wird und nach Ende einer Sitzung alle (in der Sitzung erzeugten?) Cookies entfernt werden. Das ist schon mal für die Privatsphäre besser als den normalen Browser-Modus zu verwenden.

Dennoch werden personenbeziehbare Daten von Ihnen weitergegeben, die Sie im Internet identifizierbar und somit nachverfolgbar machen. Das gehören Ihre Netzwerkadresse (IP-Adresse) und Ihr sogenannter Browser-Fingerabdruck (User-Agent etc.). Sogar die dynamische IP-Adresse wurde von EuGH und BGH sogar als personenbezogenes Datum deklariert, weil es in Deutschland möglich ist, den Anschlussinhaber herauszufinden. Auch Sie könnten einen Anschlussinhaber herausfinden (lassen). Stellen Sie sich vor, es besteht der Verdacht einer Straftat. Schon ist der Anschlussinhaber „gefährdet“. Wie so oft hat das ganze zwei Seiten. Wer hat schon Mitleid mit einem Straftäter? Aber ist es auch einer oder hat jemand dessen WLAN-Anschluss gekapert? Oder war der Verdacht an sich unbegründet? Fragen über Fragen, die Sie und ich nicht beantworten können oder dürfen.

Ungeachtet dieser Probleme mit dem Privatmodus nützt er kaum etwas, wenn Sie einen Browser oder ein Endgerät von Google nutzen. Dazu gleich mehr.

Das Google Universum

Wer den Chrome Browser von Google nutzt, ist selber schuld. Einfacher kann man Daten kaum an Google liefern. Einfacher geht es nur bei Nutzung eines Android Smartphones, am besten noch in der Standardkonfiguration und mit dauernd eingeschaltetem GPS-Signal.

Für beides gibt es eine Abhilfe. Statt dem Chrome Browser stehen zahlreiche sehr gute Alternativen zur Verfügung, die sicher jedem bekannt sein dürften. Wer es nicht weiß, kann eine datenschutzfreundliche Suchmaschine wie Ecosia oder DuckDuckGo nutzen. Auch für das Handy gibt es geeignete Browser. Wer Android mag, aber Google nicht, dem empfehle ich ein ent-Google-tes Smartphone. Ich nutze selber eines. Es ist das Fairphone mit dem Betriebssystem /e/OS. Wahrscheinlich tausendmal besser als jedes Google Endgerät, was den Datenschutz angeht.

Wer die Google Suchmaschine nutzt, hat es nun leichter. Bis vor kurzem erlaubte Google es Ihnen, ganz einfach mit nur einem Klick der allumfassenden Nachverfolgung Ihrer Persönlichkeit zuzustimmen. Wollten Sie dies überraschenderweise nicht zulassen, mussten Sie mindestens fünfmal klicken. Ich hatte bereits darüber berichtet.

Viel besser geworden ist es aber nicht. Sie müssen nun tatsächlich nur einmal klicken für „Alle ablehnen“:

Bevor Sie überhaupt etwas angeklickt haben, wird Ihre Privatsphäre aber schon nicht respektiert. Ein Teil dessen sind drei in Ihrem Endgerät in Summe rechtswidrig angelegte Cookies, von denen zwei Werte haben, die zu Ihrer Nachverfolgung geeignet sind:

Außerdem werden Google Beacons abgeschickt:

Die Werte enthalten so viele potentielle Identifikatoren, dass in meinem Screenshot große Teile der Daten unscharf gemacht werden mussten. So geht Datenschutz mit Google. Einfach mit einem Klick gar nicht zustimmen oder auch mit null Klicks nichts tun. Sie werden garantiert trotzdem von Google im Internet nachverfolgt.

Das Facebook Universum

Kürzlich erfuhr ich davon, dass Facebook etwas gegen sogenannte Scraper tun möchte. Scraper sind Programme, die Inhalte automatisch abgrasen. Facebook hat deswegen Links auf Facebook Posts, die Facebook Nutzer teilen können, in Ihrer Struktur verändert.

Bisher war es so, dass eine geteilte Facebook-URL die Zielseite auf Facebook sowie einen Parameter namens fbclid enthielt. Dieser Parameter fbclid war für das Tracking gedacht. Damit konnte Meta Sie nachverfolgen, wenn Sie auf einen Link geklickt hatten, der über die Facebook Social Media Plattform geteilt wurde.

Nun hat Facebook die Zielseite und die Tracking-ID in einem Parameter vereint. Facebook sagt, dass dies dem Kampf gegen das Scraping diene. Möglicherweise ist es auch ein Kampf gegen datenschutzfreundliche Browser, die URL stripping betreiben, um sensible Informationen zu entfernen, damit Meta nicht noch mehr über Sie und mich erfährt.

Allerdings ist eine Tracking-ID eine Tracking-ID, egal, was Meta behauptet. Wenn Sie demnächst unbedingt ins Metaverse gehen wollen, warten Sie dort bitte nicht auf mich. Ich werde nicht da sein. Auch auf Facebook werden Sie mich nicht finden, seit ich dort mein Konto gelöscht habe. Übrigens sind Facebook Fanpages rechtswidrig. Betreiben Sie selbst eine solche Fanpage, dann sind Sie gemeinsam mit Meta verantwortlich für diesen Rechtsbruch. Hoffentlich ist der Nutzen Ihrer Fanpage gigantisch. Nicht, dass Sie sich viel Arbeit machen und wenig bis gar nichts davon haben, außer möglichem Ärger.

Browser-Plugins

Auch ein Plugin wie I don't care about cookies, welches Cookie-Abfragen automatisch eliminiert, schützt Sie nicht davor, dass Ihre Daten unerlaubt (oder vielleicht sogar erlaubt, aber von Ihnen nicht erwünscht) an Dritte weitergegeben werden. Das Plugin sorgt dafür, dass diese nervigen Cookie-Abfragen nicht mehr erscheinen bzw. automatisch weggeklickt werden. So weit, so gut. Leider hat das ganze einen Haken.

Zunächst existiert mit „i dont' care about cookies“ das gleiche Grundproblem, wie oben schon beschrieben. Weiterhin simuliert das Plugin einfach ein Akzeptieren aller Datenverarbeitungen. Es nimmt Ihnen also lediglich die Arbeit ab, allem zuzustimmen. Schön wäre es ja, wenn das Plugin „alles ablehnt“, aber genau das Gegenteil passiert. Hier der Beweis:

1. Aufruf der Webseite https://www.dw4it.de/ (zufällig ausgewählt)
2. Eine Einwilligungsabfrage erscheint:

3. Das Plugin „i dont' care about cookies“ klickt die Abfrage weg.

4. Das Cookie „allowCookie“ wird erzeugt und hat den Wert 1, Google Analytics wird geladen (was erst nach Akzeptieren auf der Einwilligungsabfrage passiert)

Das eben genannte Plugin macht also genau das, was der Name vermuten lässt: Cookies werden im wahrsten Sinne des Wortes hingenommen.

Browser-Plugins wie Ghostery oder uMatrix blockieren wirksam zahlreiche Tracker und Werbe-Scripte. Sie haben keinen Nachteil. Jedenfalls muss man das wohl im Summe so sehen. Zu Ghostery sagen manche, dass die Daten dann bei Ghostery landen würden. Das ist sicher so, wäre aber technisch notwendig. Womöglich werden die Daten dort auch ausgewertet (darauf käme es nur an). Selbst wenn diese Auswertung stattfindet, gehe ich davon aus, dass der Datenschaden weit geringer ist, als wenn die Daten ungefiltert direkt an die Werbeindustrie samt Google und Facebook gelangen.

Empfehlungen

Es schadet nicht, den Privatmodus des Browsers zu nutzen. Wichtiger ist aber, den richtigen Browser und eine datenschutzfreundliche Suchmaschine zu verwenden. Plugins wie die oben genannten sind teilweise mit Vorsicht zu genießen. uMatrix ist sicher empfehlenswert.

Wer ein Android Smartphone von Google nutzt, sollte wenigstens einen anderen Browser und eine andere Suchmaschine als die von Google verwenden. Ein Fairphone o. ä. ist eine gute Möglichkeit, sich von Google loszueisen. Auch als Handy mit einer zweiten SIM-Karte (Dual-SIM oder eigenständige Telefonnummer) kann es sinnvoll sein.

Wenn Sie das Gefühl haben, dass von Ihnen besuchte Webseiten die Datenschutzregeln nicht einhalten, empfehle ich zur Vertiefung der Analyse meinen Webseiten-Check. Schreiben Sie den Verantwortlichen doch einfach per Mail an und fragen Sie, warum es rechtmäßig sein soll, dass Google Fonts, der Facebook Pixel, Google Maps oder Google Analytics ohne Einwilligung geladen werden. Sie können sich danach überlegen, ein Auskunftsgesuch nach Art. 15 DSGVO zu stellen. Das dient als gute Grundlage für eine Abmahnung oder Klage. Soweit muss es aber meist nicht kommen. Die Vernunft überwiegt bei vielen dann doch. Bei größeren Firmen wird es allerdings oft anders sein. Vielleicht lohnt es sich da, hartnäckig zu bleiben. Kommen Sie gerne auf mich zu, wenn Sie das Bedürfnis verspüren, Datenschutzregeln durchzusetzen.

Was Website-Betreiber tun können, damit ein Ablehnen auch wirkt, zeigt die Übersicht zu Cookies und Einwilligung auf Websites.