Häufige Fehlannahmen zu KI

Aufgrund einer oft einseitigen Berichterstattung, die sich immer wieder um ChatGPT oder Microsoft KI-Produkte dreht, entstehen anscheinend zahlreiche Fehlannahmen. Einige davon sind:

• Sprachmodelle würden auf Statistik basieren und seien somit nicht intelligent.
• Ein KI-System sei ein Algorithmus.
• KI sei ein Tool.
• Ein KI-System könne exakt arbeiten.
• ChatGPT sei nicht intelligent.
• ChatGPT sei die beste Lösung.
• KI sei gleichzusetzen mit ChatGPT (OpenAI), Claude (Anthropic), Mixtral (Mistral) oder Command R+ (Cohere). Etwas anderes gäbe es nicht.
• Bei Microsoft seien die Daten sicher.
• KI sei rechtskonform betreibbar.
• Tokens seien keine echten Daten.
• KI-Modelle speicherten keine personenbezogenen Daten.

Aus diesen Fehlannahmen entstehen oft Falschaussagen. Einige davon werden nachfolgend klargestellt. Stellvertretend für andere Cloud-Dienste wird folgend nur von ChatGPT gesprochen.

Falschaussagen zu KI

Die folgenden Aussagen waren so oder so ähnlich in sozialen Medien zu lesen. Die Aussagen waren an den Fundstellen jeweils allgemein formuliert, oder spezifisch und dennoch falsch.

ChatGPT sei nicht intelligent

Nach der Definition von KI auf Dr. DSGVO ist ChatGPT intelligent. Diese Definition von KI lautet:

Auch nach Alan Turing, brillanter Mathematiker im Zweiten Weltkrieg und Enschlüsseler der Enigma-Kodiermaschine, ist ChatGPT intelligent: ChatGPT besteht den Turing-Test. Der Test prüft, ob Antworten einer Maschine von denen eines Menschen ununterscheidbar sind. Im Gegenteil: ChatGPT liefert oft (fast immer könnte man sagen) deutlich bessere Antworten als der durchschnittlich intelligente Mensch.

Die neue Definition der KI-Verordnung der KI definiert ChatGPT (hoffentlich) auch als intelligent. Siehe Artikel 3 AI Act vom 12.07.2024.

Was ist Intelligenz? Eben wurde die Definition von künstlicher Intelligenz genannt. Streichen Sie einfach das Attribut „künstlich“ zweimal aus der Definition. Schon steht die Definition von Intelligenz. Der Mensch hat keinen Anspruch auf das Intelligenzmonopol, auch wenn viele es gerne so hätten.

ChatGPT sei die beste Lösung

Es kommt darauf an, wofür. Für Allerweltsaufgaben ist ChatGPT oft eine tolle Antwortmaschine. Das gilt vor allem für Weltwissen oder häufige Aufgaben, die sich auch in den Trainingsdaten von ChatGPT wiederfinden.

Für alle konkreten Aufgaben, die halbwegs professionell bearbeitet werden sollen, scheint ChatGPT ungeeignet zu sein. Ein Beispiel: Zusammenfassen eines Textes ohne Haluzinationen. Anderes Beispiel: Finden von Wissen.

ChatGPT kann und will ganz sicher nicht einen größeren Teil des Internets oder einer Webseite für Sie abgrasen. Immerhin zahlen Sie entweder „nur“ mit Ihren Daten und den Daten anderer. Oder Sie zahlen $20 pro Monat oderr einen mickrigen Betrag pro Aufruf der API.

ChatGPT kann also nur auf Inhalte zurückgreifen, die entweder schon bekannt sind oder die unbekannt sind und einen geringen Umfang haben. Mit „geringer Umfang“ ist die Anzahl der Dokumente bzw. Webseiten gemeint.

Für Aufgaben wie die Digitalisierung von Dokumenten scheidet ChatGPT als gute Lösung aus, weil hier viele Spezialitäten zu beachten sind.

ChatGPT sei schlecht

Es kommt darauf an, wofür. ChatGPT ist keine Suchmaschine. Wer das System entgegen seiner Bestimmung nutzt, muss sich über mäßige Antworten nicht wundern. Ein KI-System ist auch nicht dafür gemacht, Buchstaben eines Wortes zu zählen.

Eine KI ist gut darin, komplexe Aufgaben kreativ zu lösen. Dieselbe KI ist schlecht darin, exakte Arbeiten auszuführen. Genau wie der Mensch!

KI-Training sei teuer

Richtig ist: Das Training von großen Sprachmodellen wie ChatGPT ist sehr teuer und zeitaufwändig.

Richtig ist aber auch: Das Training eigener KI-Sprachmodelle ist sehr günstig möglich. Der Grund ist, dass diese eigenen Modelle für bestimmte Anwendungsfälle spezialisiert werden. Das Training solcher Modelle ist in vielen Fällen auf einem Laptop oder einem eigenen KI-Server in ein paar Stunden möglich.

Weil eigene KI-Rechner meist sowieso an sind und laufen, sind die Kosten für das KI-Training bei null.

KI-Training ist also in den meisten Fällen kostenfrei möglich.

Inferenz sei teuer

Inferenz ist das Befragen eines KI-Modells, also etwa das Chatten mit einem Sprachmodell wie ChatGPT.

Richtig ist: Große Sprachmodelle wie ChatGPT benötigen dutzende oder gar hunderte von Servern gleichzeitig, um eine Antwort auf Ihre Frage zu generieren. Das ist teuer.

Richtig ist aber auch: Wird ein selbst betriebenes KI-Sprachmodell befragt, kostet das gar nichts.

Somit liegen die Kosten für Inferenz in den meisten Fällen bei null. Was OpenAI für seine Server bezahlt, kann uns genauso egal sein wie es OpenAI egal ist, was wir für unsere Rechner bezahlen.

Microsoft Azure und ChatGPT seien sicher

Viele verkaufen ihre „Lösung“ als innovativ. Eine Bank hat sogar von der Einführung einer eigenen (privaten) KI gesprochen, meint damit aber Microsoft Azure. Azure ist das Gegenteil von sicher. Microsoft selbst ist Gegenstand zahlreicher Hacker-Angriffe. Weiterhin muss man feststellen, dass Microsoft dem Thema Sicherheit nicht die höchste Priorität widmet.

Hinzu kommt dermassive Datenhunger von Microsoft. Das neue Outlook will Mails von Kunden für eigene Zeecke abrufen; Windows sendet dauernd Nutzerdaten an Microsoft usw.

Microsoft Copilot sei gut

Erste Tests zeigen, dass das Gegenteil richtig ist. Copilot sollte einen Text zusammenfassen. Die Anweisung (Prompt) dafür war supersimpel und unmissverständlich. Der Text wurde direkt vorgegeben. Die Textlänge war recht kurz, weil das Eingabefeld in der Web-Oberfläche von Copilot nicht mehr zuließ.

Der Testbericht mit Screenshots offenbart, dass Copilot anscheinend für einige Aufgaben völlig unbrauchbar ist. Selbst bei wohlwollender Betrachtung gelingt es nicht, den Copilot-Ergebnissen etwas Positives abzugewinnen. Die Zusammenfassung eines Auszugs eines Dr. DSGVO Blog-Artikels war dermaßen falsch, dass ein Mensch sich dafür schämen würde. Copilot erfand zahlreiche Aussagen einfach und erfüllte die gestellte Aufgabe komplett gar nicht.

Stattdessen tut Microsoft an der jeder Stelle so, als sei Copilot eine tolle Lösung und die Antworten seien so direkt verwendet. Nirgends konnte gelesen werden, dass eine Antwort mal falsch sein könnte oder ähnliches.

Sprachmodelle basierten auf Statistik

Ja, richtig. Genau so funktioniert Grammatik. Genau so funktioniert Intelligenz. Siehe das menschliche Gehirn. Sprachmodelle sind eben nicht derart trainiert wie der Mensch, der weitere Schritte vollzieht, um eine Antwort zu geben.

Unsere gesamte Existenz basiert auf Wahrscheinlichkeiten: Vergleiche den radioaktiven Zerfall oder, noch allgemeiner, die Quantenphysik. Alles basiert auf Zufall. Alles. Bitte fragen Sie bei Bedarf jemanden, der sich mit Quantenphysik etwas auskennt.

Es spielt keine Rolle, wieso ein System intelligent ist. Entscheidend sind alleine die Ergebnisse. Wer noch daran glaubt, dass das menschliche Gehirn nicht "hackbar" sei, für den ich vielleicht ein Bericht über ein künstliches Rattengehirn auch nicht interessant. Es gelang anscheinend, Bewegungen und die zugehörigen Gehirnaktivitäten über eine Simulation nachzuvollziehen.

KI sei rechtskonform nutzbar

Theoretisch mag dies so sein. In der Praxis stellen sich einige Fragen:

1. Woher kommen die Milliarden oder gar Billionen von Datensätzen, die in ein KI-System für dessen Training eingeflossen sind?
2. Bei Cloud-Diensten wie ChatGPT oder Azure stellt sich die Frage, ob die rechtlichen Bedingungen ausreichen.
3. Kann der § 44b UrhG (deutsches Urheberrechtsgesetz) überhaupt eingehalten werden?
4. Wie können Daten aus einem bestehenden KI-Modell gelöscht werden?

Zur Frage 3: Der deutsche Gesetzgeber fordert, dass Crawler Inhalte von Webseiten nur einlesen dürfen, wenn der Webseitenbetreiber dem nicht widersprochen hat. Der Widerspruch solle, so Deutschland, im Impressum oder den AGB verankert sei. Das ist aus technischer Sicht vollkommen praxisfern und nicht realisierbar. Crawler verstehen Widerspruchs-Formulierungen in natürlicher Sprache nicht. Es gibt keine KI-Crawler. Es gibt nur dumme Crawler, die Inhalte für Systeme liefern, die intelligent werden sollen oder es schon sind. Die robots.txt-Datei wäre eine gute Lösung gewesen. Leider hat Deutschland diese Lösung verpasst. Weiterhin müsse der Betreiber des Crawlers später nachweisen können, dass KEIN Widerspruch vorhanden war. Dies ist in der Praxis kaum bis gar nicht leistbar. Somit wäre das Crawling deutscher Webseite immer ein großes rechtliches Risiko und oft wohl auch verboten.

Zur Frage 1: Die Daten kommen aus dem Internet. Texte, Bilder und andere Werke sind per se urheberrechtlich geschützt. Der Urheberschutz entsteht bei der Schaffung eines Werkes automatisch, sofern das Werk die nötige Schöpfungshöhe besitzt. Somit dürfen diese Inhalte entweder gar nicht eingelesen werden (siehe Frage 3) oder nur solange, bis der Rechteinhaber dem eine Absage erteilt. Generative KI erzeugt Ergebnisse, die potentiell urheberrechtlich geschützt sind und somit unerlaubt wären. Denn nur das Einlesen mag erlaubt gewesen sein, nicht aber das Erzeugen von KI-Antworten.

Das Löschen von Daten in KI-Modellen ist nicht zuverlässig möglich. Ein KI-Modell muss also rechtswidrig weiterbetrieben werden, wenn jemand seine Daten im KI-Modell (oder spätestens in den Antworten der KI) nicht mehr sehen will. Ein KI-Modell wegzuwerfen und es neu zu trainieren, ist für riesige Modelle wie ChatGPT keine Option, da viel zu teuer und viel zu zeitaufwändig. Neue Löschanfragen würde den Vorgang ins Unendliche hinauszögern. Für Offline-KI hingegen besteht das Problem nicht derart.

Zu Frage 2: Siehe weiter oben für Belege, warum Microsoft und dessen Plattformen als unsicher anzusehen sind. Hinzu kommen die rechtlichen Dokumente, die Microsoft und OpenAI den Nutzern auferlegen. Es stellt sich die Frage, wer diese Dokumente ordentlich prüft und was passiert, wenn ein Mangel festgestellt wird. Das Wegdiskutieren von Problemen mag eine beliebte Taktik sein, die aber das eigentliche Problem nicht löst. Zudem möchte Microsoft, wie viele Praxisbeispiele zeigen (WIndows-Telemetriedaten, neues Outlook mit riesigem Datenhunger und Zugriff auf Kunden-Mails per Kunden-Zugangsdaten…), viele Daten sammeln und nichts anderes. Warum soll man diesen Unternehmen trauen? Es gibt keinen Grund dafür.

KI sei ein Algorithmus

"Ein Algorithmus ist […] eine eindeutige Handlungsvorschrift zur Lösung eines Problems oder einer Klasse von Problemen." (Quelle: Wikipedia, Fettdruck hier hinzugefügt).

Ein KI-System basiert auf einem neuronalen Netz. Ob dies als Algorithmus im engeren Sinne bezeichnet werden kann, ist mehr als fragwürdig. Eindeutig ist ein neuronales Netz für den menschlichen Betrachter jedenfalls nicht. Vor allem dann nicht, wenn es sich um tiefe Netze handelt (daher auch der Begriff des Deep Learning).

Immerhin wird auch der Mensch nicht als Algorithmus bezeichnet. Dessen Gehirn besteht auch aus einem neuronalen Netz.

Somit müsste man der Aussage, ein KI-System sei ein Algorithmus, bei strenger Betrachtung eine Absage erteilen. Auf Wikipedia wird ein KI-System Immerhin auch nicht mit einem Algorithmus gleichgesetzt. Vielmehr wird der Trainingsfortschritt einem Algorithmus zugeschrieben, was plausibel ist, weil diese Verbesserung des neuronales Netzes im Training über eindeutige Rechenvorschriften vonstatten geht.

Sofern Sie der Meinung sind, KI sei ein Algorithmus: Bitte teilen Sie einen Fall mit, in dem eine automatisierte Problemlösung Ihrer Meinung nach KEIN Algorithmus sei. Wir sind gespannt!

KI sei ein Tool

Das ist ungefähr genauso richtig wie zu sagen „Ein Auto ist ein Haufen Materie“ oder "Cookies sind Dateien". Dann wäre alles oder nichts ein Tool. Der Informationsgehalt wäre dann null. Somit ist die Aussage nicht zielführend.

Manche meinen KI-gestützte Tools, wenn Sie von KI als Tool sprechen. Sprachliche Ungenauigkeiten führen jedenfalls nicht zu einer besseren Verständigung.

Intelligenz ist jedenfalls nicht ein Tool (Werkzeug), sondern eine (herausragende) Eigenschaft eines Systems.

Sprachmodelle könnten nicht logisch folgern

Fakt ist: Sprachmodelle können hochkomplexe mathematische Fragen besser lösen als fast jeder Mensch der Erde. Angenommen, ein KI-System tut dies, indem es alle möglichen Problemstellungen einliest und daraus lernt. Dann hat man bereits das Wort "lernen" verwendet. Bleibt man bei "Einlesen", dann kann es sein, dass das KI-System alle möglichen, bisher unbekannten Probleme lösen kann, wenn sie nur halbwegs ähnlich den bekannten Problemen sind. Wo ist der Unterschied zu den allermeisten Menschen?

Bitte lesen Sie die Mathematikaufgabendurch, die bei der AI Math Olympiad (AIMO) an KI-Systeme gestellt wurden. Sofern Sie diese Aufgaben überhaupt verstehen, sind sie offenbar ein, prozentual gesehen, winziger Teil der Weltbevölkerung, die ein sehr tief gehendes mathematisches Verständnis ihr Eigen nennen können.

Übrigens konnte der Autor dieses Beitrags mit Hilfe des besten Mathematikmodells eine hochanspruchsvolle Mathematikaufgabe lösen, von der er nur wusste (von einem Mathematiker), dass sie sich mit Diophantischen Gleichungen lösen lässt. Keine Ahnung, was Diophantische Gleichungen sind. Das Rätsel handelt von Seeleuten und Kokosnüssen und dürfte von (prozentual gesehen) so gut wie keinem Menschen auf dem Erdball jemals eigenständig gelöst werden können. Dazu wurde der lange deutsche (!) Text der Aufgabe in das englischsprachige Mathematikmodell eingekippt. Die Antwort der KI war falsch, aber der versuchte Lösungsweg war so nah an der Lösung dran, dass es mit sehr wenig Aufwand gelang, die richtige Lösung von Hand zu finden.

Token seien keine Echtdaten

Genauer: Manche meinen, nur weil Texte in Sprachmodellen als Zahlen gespeichert werden, würden die Sprachmodelle keine Originaldaten speichern.

Token sind verlustfreie Komprimierer. Heißt: Die Umwandlung von Text in Token erhält alle Informationen. Aus Datenschutzsicht sind der Originaltext und der tokenisierte Text als gleichwertig anzusehen.

Siehe auch Forschungsarbeit Language Modeling Is Compression

Sprachmodelle speichern Text in Form von Zahlenreihen (Vektoren). Dazu werden Worte in Wotfetzen zerlegt. Diese Fetzen heißen Token. Jedes Token entspricht einer Zahl. Diese Zuordnung Wortfetzen zu Zahl ist pro Sprachmodell eindeutig in einem Wörterbuch (Vokabular) festgelegt. Dieses Wörterbuch ist bei jedem Sprachmodell als Textdatei angehängt. Man kann sich diese Textdatei jederzeit ansehen und sie auswerten.

Die Zahlenfolge 4711, 0815, 9933 könnte dabei den Buchstabefolgen Maxi, mi, lian entsprechen. Offenbar sind die Zahlen auf Worte rückführbar. Somit sind die Zahlenreihen personenbezogen, wenn die dadurch kodierten Buchstaben personenbezogen Daten darstellen. Auch indirekt auf eine Person herleitbare Daten sind personenbezogen (vgl. Art. 4 Nr. 1 DSGVO).

Weiterhin bilden Sprachmodelle ihre Ausgabe u.a. durch kumulative Wahrscheinlichkeitswerte von Token. Es werden also nicht nur zwei Token betrachtet, sondern eine ganze Kette von Token. Ein technischer Parameter, der dies steuert, heißt top_p.

Das Hamburger Thesenpapier (siehe folgend) liegt also in fundamentalen Aussagen falsch. Es scheint deswegen so geschrieben zu sein, um alle KI-Systeme zu legalisieren, von denen die meisten rechtswidrig sein dürften.

KI-Sprachmodelle würden keine personenbezogenen Daten speichern

Die Argumentation des Hamburgischen Datenschutzbeauftragten (HmbBfDI) geht so: Es sei unheimlich schwierig, personenbezogene Daten aus Sprachmodellen herauszuholen. Der EuGH sagte, dass die Rekonstruktion eines Personenbezugs nur dann als möglich angenommen werden kann, wenn die Mittel und Aufwände dafür im üblichen Rahmen liegen. Der HmbBfDI sagt, dass nur mit einer ausgeklügelten, rechtswidrigen Privacy Attacke die personenbezogen Daten aus Sprachmodelle herausgeholt werden könnten. Wegen des enormen Aufwands, der dafür nötig sei, seien es gemäß EuGH Rechtssprechung keine personenbezogene Daten.

Hier das einfache Gegenbeispiel, das den HmbBfDI leicht widerlegt:

Sprachmodelle speichern Daten aller Personen gleich. Auch Personen, die nicht öffentliche Personen sind, werden derart im Sprachmodell gespeichert, und zwar bei dessen Pre-Training über die Trainingsdaten. Die Trainingsdaten bestehen aus vielen Milliarden Dokumenten. Unwahrscheinlich, dass dort nur Angela Merkel oder andere völlig öffentliche Personen vorkommen, die anscheinend weniger Recht auf Privatsphäre haben als der Normalbürger.

Sprachmodelle sind verlustfreie Komprimierer bzw. können es sein. Sie sind es (quasi immer), wenn man sie entsprechend behandelt. Sie sind es sehr oft, wenn sie nicht speziell behandelt werden.

Siehe Forschungspapier Language Modeling Is Compression sowie die in diesem Beitrag genannten Experimente, die jeder selbst nachvollziehen kann.

Es ist sogar möglich, vollständige Zitate aus einem Sprachmodell herauszuholen. Der eben verlinkte Beitrag demonstriert auch, dass in LLMs sehr wohl personenbezogene Daten liegen. Im Gegensatz zur Annahme des HmbBfDI sind nämlich alle großen KI-Modelle Teil eines KI-Systems. Das bedeutet: Ein KI-System kann die Zahlen, aus denen ein KI-Modell besteht, interpretieren und in Text rückumwandeln. Nur ein KI-Modell alleine auf der Festplatte liegen zu haben, ohne die Fähigkeit der Interpretation, wäre unkritisch. Diesen unkritischen Fall gibt es aber offensichtlich bei ChatGPT oder GPT-4o nicht. Es gibt ihn höchstens bei Open Source Sprachmodellen, aber auch nur theoretisch. Denn es reicht, sich eine sehr weit verbreitete Progframmierbibliothek herunterzuladen, um den Inhalt des Modells interpretieren zu können. Leider hat der HmbBfDI einen technischen Unterschied zwischen ChatGPT und GPT-4o konstruiert, den es nicht gibt.

An sich ist es auch egal:

1. Wird ein LLM benutzt, gibt es oft personenbezogene Daten. Werden diese in Umlauf gebracht, haftet der Mensch, der dies tut.
2. Wird ein LLM nicht benutzt, spielt es praktisch meistens keine Rolle, welche Daten das LLM enthält. Niemand sieht es.
3. Es geht also vorrangig gar nicht um die Speicherung.

Allgemeine Künstliche Intelligenz könne es nicht geben

Diese Art der Intelligenz wird auch als AGI bezeichnet. AGI steht für Artificial General Intelligence. Wir stehen erst am Anfang. Offensichtlich sind intelligente Roboter, die in der Weltgeschichte herumlaufen, noch nicht häufig zu beobachten.

Wahr ist: Wenige Unternehmen alleine werden bereits tausende Milliarden Dollar in den Bau intelligenter Roboter investieren. Dazu benötigt man:

1. Einen Roboter (schon da, wird immer besser).
2. Ein elektronisches Gehirn (schon da, wird immer besser).
3. Jemanden, der den Gehirn-Kasten (Computer mit KI) auf den Roboter draufsetzt (dieser Jemand ist auch schon da).

Diese drei Komponenten gibt es also bereits. Selbstlernende Systeme gibt es offenbar bereits. Siehe ChatGPT oder NuminaMath (weiter unten). Es ist nur eine Frage der Zeit, bis Roboter lernen, unsere Welt besser zu beherrschen als wir selbst es jemand werden tun können.

Erst in vielen Jahren würde KI übermächtig sein

Beweisen lässt sich die Falschheit dieser Annahme nicht, ebenso wenig wie die Aussagen im vorigen Abschnitt zu AGI. Die Zeit wird es zeigen.

Richtig ist aber: Die KI-Entwicklung schreitet in Überlichtgeschwindigkeit voran. Was vor 2 Wochen noch nicht möglich war, ist es nun. Das gilt beispielsweise für die Fortschritte von Open-Source Sprachmodellen. Die oben genannte AIMO wurde von einem Open-Source Modell namens NuminaMath gewonnen. Es beantwortete 29 von 50 schwierigeren mathematischen Problemen korrekt, die in Textform gestellt wurden.

Google behauptet übrigens, ein Fortschritt in der Robotik sei mit Hilfe eines Sprachmodells erreicht worden.

Prognose von Dr. DSGVO: In 10 bis 15 Jahren werden Roboter in der Gegend herumlaufen, die eine ernsthafte Gefahr für die Menschheit darstellen. Es können auch 5 Jahre sein (um es genauer zu wissen, müsste man Robotikexperte sein). Ganz sicher wird es aber keine 35 Jahre mehr dauern, bis wir uns aufgrund der Überlegenheit von KI ernsthafte Sorgen um unsere Existenz machen müssen. Haben Sie Kindern, dann werden diese, so die Prognose dieses Beitrags, ihr Lebensende anders gestalten als es gutgefunden werden kann.

Was sind Ihre Fragen oder Erkenntnisse?

Was ist Intelligenz?

Diese Frage ist nicht leicht zu beantworten. Der naive Ansatz wäre, sich auf den Menschen als Maßstab zu beziehen. Dies ist völlig ungerechtfertigt. Alleine schon der Hinweis auf Tiere, die (in unseren Augen) intelligentes Verhalten an den Tag legen können, zeigt das Problem bei einer auf den Menschen zentrierten Sichtweise.

Die KI-Verordnung der EU definiert zwar nicht Intelligenz, aber versucht sich an der Definition von Künstlicher Intelligenz:

„System der künstlichen Intelligenz“ (KI-System) ein maschinengestütztes System, das so konzipiert ist, dass es mit unterschiedlichem Grad an Autonomie operieren kann und das für explizite oder implizite Ziele Ergebnisse wie Vorhersagen, Empfehlungen oder Entscheidungen hervorbringen kann, die das physische oder virtuelle Umfeld beeinflussen;“

Quelle: Artikel 3 Nr. 1 KI-VO vom 14.06.2023 (Fettdruck hinzugefügt)

Die neueste akzeptierte Fassung ist leicht anders, aber qualitativ genauso praxisfern. Die Version in der vorigen Fassung vom 21.04.2021 hatte in der Definition noch den Menschen als Maßstab genannt.

Diese Definitionen der EU bietet Raum für Kritik. Sie stellt beispielsweise in Frage, ob ChatGPT intelligent ist. ChatGPT war wohl allerdings das erste (prominente) KI-System, dass den Turing-Test bestand und somit intelligentes Verhalten ununterscheidbar vom Menschen imitierte.

Außerdem unterstellt die EU bei deren Definition mitunter Ziele, die bei den meisten generischen Programmen jedenfalls nicht aufgabenspezifisch vorhanden sind. Dass ein künstliches System maschinengestützt sein muss, darf nicht nur bezweifelt werden, sondern muss als falsch bezeichnet werden.

Das wäre so, als würde man den Diesel verbieten wollen, nur weil einem die Vorstellungskraft fehlt, dass Diesel auch mal umweltfreundlich hergestellt werden kann… Allerdings fehlt mir die Vorstellungskraft, wie ein extrem teurer und mit vielen Nachteilen behafteter Akku der aktuellen Technologiestufe als Batterie die Verkehrswende herbeiführen soll.

Weitere Kritikpunkte zum Intelligenz-Begriff der EU und mehr Details sind in einem eigenen Beitrag zur Definition von Künstlicher Intelligenz genannt. Dort wird auch eine neue Definition für den Begriff „Künstliche Intelligenz“ vorgeschlagen.

Was ist der Unterschied zwischen künstlicher und nichtkünstlicher Intelligenz?

Die meisten Menschen können diese Frage anscheinend nicht beantworten oder wollen es nicht. Die Antwort lautet: künstliche Intelligenz ist künstlich und nichtkünstliche Intelligenz ist nichtkünstlich. Mehr ist es nicht. Nun kann man lange darüber diskutieren, was künstlich genau bedeutet. Legen Sie es einfach selber fest. Es ist egal für die Frage, ob etwas oder jemand intelligent ist oder nicht.

Es geht bei Intelligenz nicht darum, wie und warum genau sie stattfindet. Es gibt nur ein einziges besonders hervorzuhebendes Kriterium, das als Merkmal für Intelligenz anzusehen ist: Das Ergebnis.

Damit ein Zufallsgenerator nicht als intelligent bezeichnet werden muss, muss noch etwas verfeinert werden. Ebenso kommt es oft gar nicht auf das Endergebnis in Form einer finalen Antwort an. Als Beispiel sei nur das sogenannte „Assessment Center“ genannt. Hier werden Bewerber eingeladen, um ihre Eignung für eine bestimmte Position im Unternehmen prüfen zu lassen. Manche Aufgaben sind so gestellt, dass sie in der zur Verfügung stehenden Zeit und mit den vorhandenen Informationen nicht gelöst werden können. Dennoch werden die Aufgaben gestellt. Warum?

Weil es darum geht, wie der Kandidat die Aufgabe lösen will. „Wie“ heißt, es geht um den Lösungsweg, und zwar um den nach außen erkennbaren. „Will“ heißt, es geht nicht vorrangig darum, dass ein finales Ergebnis vorgelegt wird.

Dies führt zur folgenden Definition von Intelligenz und somit auch von Künstlicher Intelligenz:

Nun folgt die Definition von Künstlicher Intelligenz:

Ersetze „System“ durch „künstliches System“.

Weil simpel simpel simpel ist (angelehnt an Simyo).

Ist KI nun ein Token-Papagei oder nicht?

Die Frage ist an sich irrelevant. Siehe Definition von Intelligenz oder künstlicher Intelligenz oben.

Beantworten wir die Frage mal mit „Ja“ und ignorieren, dass diese Frage irrelevant ist. Ist der Mensch nicht dann auch ein Token-Papagei? Ein Token ist übrigens ein kurzes Wort oder ein Wortteil. Token werden als eine Form der Kompression verwendet, damit KI-Sprachmodelle effizienter arbeiten.

Wie arbeitet das menschliche Gehirn?

Keine Ahnung. Niemand weiß es genau. Es gibt ein neuronales Netz, das alle Eingabesignale in analoge Signale umwandelt und verarbeitet. Das Ergebnis sind wieder analoge Signale.

Wie arbeitet ein künstliches Gehirn?

Keine Ahnung. Niemand weiß es genau. Es gibt ein neuronales Netz, das alle Eingabesignale in digitale Signale umwandelt und verarbeitet. Das Ergebnis sind wieder digitale Signale.

Das war kein Copy & Paste Fehler. Dass beide Aussagen identisch klingen, ist Absicht. Man muss nur bereit sein zu akzeptieren, dass analog und digital zwei Systeme sind, die ineinander überführbar sind.

Zurück zum menschlichen Gehirn (wir reden hier nicht über unseren Körper; falls doch, dann reden wir analog über Roboter mit einem eingebautem Computer ; dies wird in wenigen Jahren in erschreckender Art und Weise Realität sein).

Ein Aufsatz aus dem Jahr 2021 lautet: Can the Brain Build Probability Distributions?. Ziel der zugrundeliegenden wissenschaftlichen Untersuchung am Menschen war es „whether the brain can build probability distributions to represent experienced data and use this global representation to evaluate the likelihood of new information.“ (Fettdruck hinzugefügt).

Es sollte also herausgefunden werden, ob der Mensch neue Informationen aufgrund ihrer Wahrscheinlichkeit beurteilt. Das Ergebnis war, dass es eine neurophysiologische Evidenz gibt, das dem so ist. Nun kann man natürlich abstreiten (ich tue es nicht), dass diese Fähigkeit des Gehirns für intelligentes Verhalten notwendig sei.

Damals, vor vielen Jahren, hatte ich schon in Büchern über Intelligenz gelesen, dass das menschliche Leben im Wesentlichen auf Erwartung basiert. Wenn wir einen Fuß auf den Boden setzen wollen, erwarten wir eine bestimmte haptische Rückmeldung. Diese Rückmeldung ist ein Signal im Gehirn (mehr nicht!). Bleibt diese Rückmeldung aus oder hat sie eine andere Qualität als „erwartet“ (!!), also als „gelernt“ (!!), dann werden wir stutzig. Ist der Boden nass? Ist ein Loch im Boden? Sind wir auf etwas draufgetreten?

Stellen Sie Ihre „Intelligenz“ doch mal auf die (kleine) Probe:

Als typischer Rechts- oder Linkshänder nehmen Sie mal Augentropfen (Plastik-Fläschchen zum Herunterdrücken) und führen den Vorgang des Eintropfens in das Auge mit vertauschten Händen aus.

Als Kontaktlinsenträger führen Sie die Linse mit vertauschten Händen in das Auge ein.

Ihr Tablet oder Smartphone bedienen Sie bitte mal mit vertauschten Händen.

Ist angelernt ein Zeichen von Intelligenz oder nicht und nicht gelernt ein Zeichen von fehlender Intelligenz?

Weil die Erklärung von Verhalten über das Konzept der Erwartung so simpel ist, ist es für viele zu simpel. Sie wollen eine komplizierte Welt und geben sich nicht mit einfachen Erklärungen zufrieden, wenn diese Erklärungen einen kompliziert anmutenden Vorgang erklären.

Weitere Quellen, die zeigen, dass der Mensch ein Token-Papagei ist, existieren beispielsweise bei Nature: "There is strong behavioral and physiological evidence that the brain both represents probability distributions and performs probabilistic inference." (Fettdruck hinzugefügt). Inferenz ist das, was auch im KI-Umfeld als "Arbeiten" bezeichnet wird, also das Produzieren eines Ergebnisses zu einer gegebenen Aufgabenstellung.

Es ist allerdings völlig egal.

Denn es kommt bei Intelligenz nicht auf die Art des Mechanismus an (sofern nicht Zufallsgenerator o.ä.), sondern alleine auf das feststellbare Ergebnis. Siehe oben für die Definition von Intelligenz.

Viele sehen es anders als ich und haben eine andere Vorstellung von Intelligenz. Allerdings findet sich fast nirgends eine Definition von Intelligenz, geschweige denn eine belastbare Definition. Wer der KI kategorisch die Intelligenz (=Macht) abspricht, den würde ich gerne in wenigen Jahren noch mal sprechen. Ebenso alle (gerne alsbald), die "was mit KI" machen wollen und einen möglichen Anwendungsfall im Kopf haben.

Fazit

KI ist ein Token-Papagei. Der Mensch ist ein Token-Papagei. Komplexe Probleme können oft durch "simple" Mechanismen gelöst werden. Ein solcher "simpler" Mechanismus ist ein neuronales Netz. Die KI-Antworten basieren nicht auf Algorithmen, wie selbst manche Informatiker (die sich nicht mit KI beschäftigen) meinen. Ein neuronales Netz ist keine wohl definierte Rechenvorschrift, die es sein müsste, um als Algorithmus zu gelten.

Wären KI und Mensch kein Token-Papagei, wären sie wahrscheinlich (!) nicht intelligent. Warum wahrscheinlich? Weil unsere gesamte Existenz auf Wahrscheinlichkeiten basiert. Viele scheinen das nicht zu wissen und wollen es auch nicht akzeptieren. Welche physikalischen Prinzipien den Wahrscheinkeits-Charakter unserer Existenz unumstößlich belegen, habe ich im Kellergespräch gegenüber Michael Westphal von TV1 genannt, der mich auf dem Mainzer Digitalkongress kürzlich befragte und im Videobild festhielt.

Was können wir aus diesen Möglichkeiten der Künstlichen Intelligenz machen? Sehr viel. Was vor wenigen Jahren unmöglich war, ist jetzt möglich. Was vor wenigen Jahren mit sehr viel Aufwand möglich war, ist jetzt mit sehr wenig Aufwand möglich.

Sie finden eine Beta-Version einer Offline-KI

Einleitung

KI wird sowohl unterschätzt als auch überschätzt. Die meisten Menschen, oft auch ich, verstehen nicht, welche Möglichkeiten KI-Systeme bieten. Gestern erst wieder habe ich revolutionäre KI-Ansätze gesehen, die vor 2 Wochen noch nicht bekannt waren. So geht es mir als jemandem, der sich sehr intensiv mit Künstlicher Intelligenz beschäftigt, fast jeden Tag.

Viele denken also, KI wäre ein Hype, der sich schon wieder legen wird. Falsch! Mit dem Transformer-Ansatz wurde 2017 die Intelligenzfunktion des Menschen entschlüsselt, sage ich. Anstatt einen Algorithmus für die Lösung eines Problems zu programmieren, muss ich nur noch genügend Beispiele in mein KI-System, das unter dem Schreibtisch läuft, einfließen lassen. So wurden sogar bisher unbekannte Hieroglyphen entdeckt und entschlüsselt.

Aus der berechtigten Angst vor den negativen Folgen von immer mächtiger werdenden KI-Systemen fordern viele eine Regulierung. Sie sagen aber nicht, wie.

Dann gibt es Verharmloser, die sich als KI-Experten oder rechtliche Ermöglicher profilieren wollen. Sie sagen anderen, wie oder dass sie ChatGPT gewinnbringend nutzen können. Sogar auf der Tagung der DSRI (Deutsche Stiftung für Recht und Informatik) wurde in einem Beitrag behauptet, KI-Modelle würden keine personenbezogenen Daten verarbeiten.

Andere beruhigen, indem sie sich auf das neue informelle Datenschutzabkommen zwischen Europa und den USA berufen. Nur weil jetzt Daten ohne zusätzliche Garantien in die USA geschickt werden dürfen, suggerieren manche, dass jegliche beliebige Datenverarbeitung somit erlaubt sei.

Zu den einzelnen Punkten folgen ein paar Details.

Möglichkeiten von KI-Systemen

Eine KI kann alles, was ein Mensch kann, und noch viel mehr. Vielleicht jetzt noch nicht, aber potentiell (in einem bestimmten Anwendungsgebiet X) schon nächste Woche. Demnächst werden Roboter mit KI-Gehirnen in der Gegen herumlaufen und die Umwelt erfahren. Das wird genau gleich sein zu dem, wie Kinder lernen. Wer an die Stelle der Eltern tritt, wird man sehen. Das können menschliche Trainer sein, aber auch andere Roboter oder Algorithmen.

Ein Beispiel für die rasante Entwicklung: KI-Sprachmodelle konnten nur sehr wenige Zeichen Text gleichzeitig verarbeiten. Diese Textmenge wird als Kontextlänge bezeichnet. Bis vor wenigen Monaten betrug die Kontextlänge in fast allen mir bekannten KI-Sprachmodellen 1024 Zeichen, also ein Kilobyte.

Im Wochenrhythmus stieg die Kontextlänge an, zunächst auf 2048, dann auf 4096, dann auf 8192, dann auf 16.000 Zeichen, später auf 32.000 Zeichen. ChatGPT rühmte sich kürzlich mit 128.000 Zeichen Kontextlänge.

Gestern las ich von einem Ansatz, der in der Forschung schon seit ein paar Monaten bekannt ist. Damit kann eine Kontextlänge von einer Milliarde Zeichen (= 1.000.000.000) auf einmal verarbeitet werden. Kurz nachgerechnet: Vorher = 128.000 Zeichen, einen Wimpernschlag später = 1.000.000.000 Zeichen. Das ist eine Verbesserung um den Faktor 7800. Einfach mal eben so.

Weiteres Beispiel: Der oben genannte Transformer Ansatz hat ein paar Schwächen. Er ist sehr ressourcenhungrig. Selbst Hochleistungsrechner bzw. Grafikkarten benötigen einige Sekunden, um eine Antwort auf eine Frage an den Chatbot zu generieren. Jeder ChatGPT Nutzer weiß, wovon ich rede. Nun gibt es einen Ansatz, der dieselbe Antwortqualität bringt, aber 8 Mal schneller antwortet und nur ein Drittel des teuren und kaum verfügbaren Grafikkartenspeichers für seine Berechnungen benötigt.

Sofern Sie über 50 Jahre alt sind, habe ich eine gute Nachricht für Sie: Die Chance besteht, dass Sie eines natürlichen Todes und in Frieden sterben können. Alle wesentlich jüngeren werden das Ende der Menschheit miterleben, weil KI-Systeme uns massivst übertrumpfen, knechten oder auslöschen werden. Eventuell tritt vorher schon eine andere Katastrophe ein, aber darum geht es in diesem Beitrag nicht.

Ist KI nur Statistik?

Die Frage ist irrelevant. Es spielt ja auch keine Rolle, ob das menschliche Gehirn auf statistischen Prozessen basiert. Wichtig, was am Ende dabei rauskommt. Offensichtlich basiert unsere gesamte Existenz auf statistischen Prozessen. Vergleiche hierzu die Quantenphysik, einer sehr elementaren und leistungsfähigen Theorie. Der Quantenphysik liegt zugrunde, dass das Verhalten eines mickrigen Teilchens unserer Existenz nicht wirklich vorhergesagt werden kann. Vielmehr kann nur eine Aussage über Teilchen gemacht werden, wenn viele betrachtet und der Durchschnitt aus den Beobachtungen gezogen wird.

Offensichtlich basiert die deutsche Grammatik darauf, dass wir lernen, welche Worte typischerweise aneinandergereiht werden und zusammen passen. Das ist auch Statistik. Darüber redet aber kaum jemand.

Die Regulierung von KI

Die Fähigkeiten von KI machen vielen zurecht Angst oder bereiten ihnen Sorgen. Aus ihrer gefühlten Hilflosigkeit heraus fordern manche eine Regulierung von KI-Systemen. Was genau damit gemeint ist, wird meistens nicht gesagt. Die einzigen Forderungen, die mir im Kopf hängengeblieben sind, sind folgende:

• Kennzeichnung von KI-generierten Werken: Bilder, Videos, Texte…
• Offenlegen der Quellen, mit denen ein KI-System trainiert wurde
• Noch was? Mir fällt gerade nichts Nennenswertes ein

Zum ersten Punkt: ist geschenkt. Die Kennzeichnung von Werken ist eine gute Idee, ändert so gut wie nichts. Kriminelle werden ihre Fake-Videos und Fake-News nicht anfangen als künstlich generierte gefälschte Werke zu kennzeichnen. Alle anderen halten sich brav an die Kennzeichnung. Dadurch wird die Menschheit zwar nicht gerettet, aber kann man machen. Der Nutzen ist da, aber das ist nur ein punktueller Eingriff, der qualitativ kaum etwas bewirkt.

Offenlegen von Quellen, also Trainingsdaten: Wer so etwas fordert, hat einfach keine Ahnung, wie KI-Modelle aufgebaut sind. Diese Forderung kommt um Jahre zu spät. Die Quellen sind meistens bekannt:

• The Pile (Text)
• Common Crawl (Text)
• LAION-Datensatz (Bilder, deutscher Verein!)

In den Textdaten sind Insbesondere Wikipedia, News-Seiten und populäre Webseiten enthalten.

Wenn ich Ihnen sage, dass mein KI-Modell ein Chemielexikon eingelesen hat, was machen Sie dann? Theoretisch kann meine KI dann Kampfstoffe entwickeln. Praktisch hat das schon stattgefunden, allerdings als Experiment von gutmütigen Forschern, die Wirkstoffe KI-generiert hatten und testweise aus der „Eins“ eine „minus Eins“ gemacht hatten. Die Gefahren sind also erheblich.

Beispiel mit eigener KI

Meine Frage an meine KI am 01.12.2023:
Nenne mir konkret Veranstaltungen oder Gelegenheiten zum tagsüber Ausgehen am 02.12.2023 in der Nähe von Idstein (nahe Wiesbaden)! Nur Veranstaltungen in Gebäuden und nur Veranstaltungen, die mehr als 10 Kilometer von Idstein entfernt sind.

Antwort meiner KI (einige Teile weggelassen):
Am 02.12.2023 finden in Wiesbaden und Umgebung Veranstaltungen wie das Cello-Konzert mit Roger Morelló im Wiesbadener Burgfestspiele sowie der 
Wochenmarkt Wiesbaden ab 11:00 Uhr statt.
Alle Veranstaltungen sind mehr als 10 Kilometer von Idstein entfernt.

--> Gesucht habe ich Veranstaltungen für "morgen" in der Nähe, die aber nicht vor der Haustür liegen (weil sonst zu langweilig/altbekannt)
--> Gefunden wurde Veranstaltungen für morgen in der Nähe, die nicht direkt vor meiner Tür sind.
--> Aufgabe erfüllt. Das alles ohne jegliche Optimierung, die sicher noch möglich ist und die noch weit bessere Ergebnisse bringt.
--> Beginn Programmierung dieser Lösung (lokales Sprachmodell schon am Start): 01.12.2023
--> Ende Programmierung: 01.12.2023

Kurzum, ich muss es hier abkürzen: KI lässt sich nicht regulieren. Eine KI kann alles, was ein Mensch kann (siehe oben). Wie reguliert man Menschen? Solange sie nichts Böses getan haben, gar nicht. Nachdem etwas Schlimmes passiert ist (Dieb, Mörder, Terrorist, Volksverhetzer etc.) wird strafverfolgt. Dann ist es aber zu spät. Soweit ich weiß, gelang es in Demokratien noch nie und gelingt es auch jetzt nicht, einem Menschen das Denken zu verbieten. Eine KI kann aber viel schneller, länger und (sehr bald) besser denken als ein Mensch.

Übrigens halte ich die Frage, ob eine KI Urheber eines Werkes sein kann, für weitgehend unsinnig. Denn wenn ich ein Bild von meiner eigenen KI (ohne Wasserzeichen) vorgenerieren lasse und dann behaupte, es ist mein Werk, dann werden Sie mir das Gegenteil nicht oder nur unter allergrößter Anstrengung aufzeigen können. Vor allem können KI-generierte Bilder oder Musikstücke ja noch manuell nachbearbeitet und erweitert werden.

Verarbeiten Sprachmodelle personenbezogene Daten?

Ja, fast immer. Und zwar immer dann, wenn

a) in den Trainingsdaten personenbezogene Daten vorkommen oder

b) der Nutzer in seiner Eingabe (Prompt) an den Chatbot personenbezogene Daten verwendet.

Punkt a) ist bei allen mir bekannten Sprachmodellen gegeben. Siehe beispielsweise die riesigen Trainingsdatensätze The Pile und C4 (Collosal Cleaned Common Crawl), die in allen gängigen Chatbot-Modellen Verwendung finden.

Anscheinend wünschen sich manche, dass KI-Systeme keine personenbezogenen Daten verarbeiten. Die Realität sieht so aus: KI-Sprachmodelle verarbeiten personenbezogene Daten und speichern diese auch.

Manche akzeptieren das und behaupten dann, personenbezogene Daten könnten automatisch erkannt und anonymisiert werden. Das ist Bullshit. Jeder, der das behauptet, hat weder Ahnung von Künstlicher Intelligenz noch von Datenschutz. Leider gibt es ganz besonders naive Menschen und Organisationen, die für angebliche Lösungen, die haltlose Versprechen bezüglich der Anonymisierbarkeit von Daten machen, auch noch eine Nominierung zu einem Innovationspreis aussprechen.

Privacy Shield II (Data Privacy Framework)

Rein formal ist die Datenschutzwelt für den Datentransfer zwischen der EU und den USA wieder heile. Der Vorwurf, der zum EuGH-Urteil Schrems II und zum ungültigen Privacy Shield führte, war ja, dass die USA ein Geheimdienststaat sind (FISA 702, EO12333, Cloud Act). Anscheinend wurde das mit dem Data Privacy Framework (DPF) wegdiskutiert und wird wahrscheinlich demnächst vom EuGH wieder einkassiert.

Es geht darum, dass personenbezogene Daten jetzt wieder ohne besondere Garantien aus der EU in die USA übertragen werden dürfen. Daraus leiten manche Dummköpfe ab oder suggerieren, dass nun jegliche Datenverarbeitung in den USA erlaubt sei.

Richtig ist, dass jegliche Verarbeitung personenbezogener Daten gemäß einer der Rechtsgrundlagen aus Art. 6 (1) DSGVO erfolgen muss. Und ja, es werden immer personenbezogene Daten an ChatGPT übertragen, wenn die ChatGPT Oberfläche benutzt wird. Die IP-Adresse ist personenbezogen und wird immer übertragen. Leider hält sich OpenAI nicht so gerne an Datenschutzregeln, weil dann ja die eigene KI nicht so gut verbessert werden kann. Auch Microsoft als Anteilseigner von OpenAI ist nicht so sehr an Datenschutz interessiert. Siehe das neue Outlook, das sich sogar Ihren Benutzernamen und Ihr Passwort Ihrer Mail Accounts nimmt und Ihre Daten und die Ihrer Mail-Korrespondenz abruft und analysiert. Von den Sicherheistsproblemen von Microsoft (Azure), die Microsoft heruntergespielt und lange nicht (jetzt vielleicht?) gelöst hat, ganz zu Schweigen.

KI-Experten

Bemerkenswert sind die KI-Aufsätze vieler, die keinerlei oder nur sehr wenig Ahnung von Technik haben. KI basiert in ganz erheblichem Maße und mehr als fast alle anderen Errungenschaften auf Technik. Wie kann dann jemand, der davon wirklich nichts oder nur sehr wenig versteht, kompetente Aussagen treffen?

Dann gibt es ChatGPT-Jünger, die Geld mit Empfehlungen und Prompt-Verbesserungen verdienen möchten. Die verstehen wenigstens etwas von Technik, nämlich, dass man eine Computer-Maus nicht nutzt, um (wie Scotty) in die Maus reinzusprechen, sondern um mit ihr einen Cursor auf dem Bildschirm zu bewegen. Gilt nur für alle, die ab und zu mal den PC mit seinem unnötig großen Monitor und der unnötig effizienten Tastatur nutzen statt einer völlig ausreichend mickrigen Smartphone Tastatur samt Bildschirm für Menschen in den Jahren mit der besten Sehstärke.

Diese ChatGPT-Jünger, die womöglich ein Mini-Technik-Wissen haben und wissen, wie man das Internet bedient, haben aber leider oft bis fast immer keinerlei Ahnung von oder Interesse an Datenschutz.

ChatGPT ist ein tolles System und für unverfängliche Aufgaben durchaus guten Gewissens nutzbar. Aber was ist denn mit sensiblen Daten?

Grenzen von KI

Noch ist es so, dass insbesondere Sprachmodelle (LLMs) oft halluzinieren, also Falschaussagen liefern. Das wird auch so bleiben, sage ich. Oder würden Sie behaupten, dass Menschen keine Falschaussagen treffen? Selbst Experten sagen oft falsche Dinge, die sie später – Einsicht vorausgesetzt – revidieren. Anscheinend hat es die Menschheit in einigen Millionen Jahren der Existenz nicht geschafft, an ihrer Unzuverlässigkeit etwas zu ändern. Warum soll das bei künstlichen Systemen anders sein?

KI kann sicher in vielen Bereichen zuverlässiger sein als der Mensch und in Teilbereichen auch extrem zuverlässig. Aber wenn es um das Zusammenfassen von Klageschriften vor Gericht geht, dann versagt bei mir das Verständnis, wie man hierfür eine KI als Lösung ansieht.

Datenfreundliche KI-Systeme

Datenschutz interessiert viele Unternehmen nicht. OK, dann nehmen wir Geschäftsgeheimnisse. Wer gibt mir sein Geschäftsgeheimnis? Wieso denn nicht? Wenn mein Name ChatGPT ist, geben Sie es mir dann?

Es soll Dokumente geben, für die vertraglich Vertraulichkeit vereinbart wurde. Viele nennen das NDA (Non Disclosure Agreement). Wenn Sie ein solches Dokument in ChatGPT reinladen, um den Chatbot um eine Zusammenfassung zu bitten, haben Sie dann nicht bereits die Vertraulichkeit verletzt? Ich sage: Ja

Noch schlimmer wäre es nur, wenn Sie das neue Outlook nutzen, um vertrauliche Dokumente zu verschicken. Denn dann erhält Microsoft auromatisch tiefer gehende Kenntnis davon.

Was viele Unternehmen noch nicht verstehen: ChatGPT kann vieles nicht und vieles schlechter als eigene KI-Systeme. Eine Lösung sind autarke KI-Systeme, die Ihrem Unternehmen gehören. Nicht nur, dass damit das Datenproblem gelöst ist, denn Sie entscheiden, ob Daten Ihr System verlassen und falls ja, welche Daten und an welche Empfänger die Daten gehen sollen.

Zusätzlich, und das ist wohl für viele interessanter, können eigene KI-Systeme jederzeit und ohne Mühe auf Ihr Unternehmenswissen zurückgreifen und Ihnen Fragen dazu beantworten. Der Einstieg in ein eigenes KI-System könnte eine intelligente Dokumentensuchmaschine sein oder ein KI-Tool für die Datenanalyse. Nach der Dokumentensuche können Sie nahtlos zu einer Frage-Antwort-Maschinen übergehen. Wenn Sie wüssten, was jetzt schon alles möglich ist, würden Sie die letzten Jahre Ihrer Existenz noch mehr genießen.

Übrigens sind eigene KI-Systeme nicht teuer. Wir reden nicht von Raketenprojekten mit hunderten oder tausenden Personenstunden Aufwand. Ein erstes KI-System kann in Kürze errichtet werden.

Fazit

KI ist keine Modeerscheinung, sondern ein Zustand, der bis zu unserem Ende existieren wird. Die Frage ist nicht, ob KI so leistungsfähig sein wird, dass wir darunter leiden werden, sondern wann. Diese Entwicklung lässt sich nicht mehr aufhalten.

Zur Begründung sei gesagt, dass jeder jederzeit fast das gesamte geballte KI-Wissen samt KI-Software-Bibliotheken und KI-Modellen (= elektronische Gehirne) auf seinen eigenen Computer laden und nutzen kann.

Regulierung wäre nur dann möglich, wenn jeder Computerkauf und jeder Download aus dem Internet überwacht werden würde. Die Erkenntnisse, die ich täglich neu dazu gewinne, lassen mich erschaudern ob der massiven Möglichkeiten, die KI bietet. Ich rede hier davon, dass mir als Programmierer diese Möglichkeiten genau jetzt offenstehen und "morgen" noch mehr. Dazu reicht eine Recherche in einschlägigen Quellen, die ich täglich eine Stunde lang betreibe, gestern noch länger und bis halb ein Uhr nachts, weil die Möglichkeiten, von denen ich gelesen und für die ich Programmcodes gesehen habe, so faszinierend und atemberaubend sind. Das war auch der Auslöser für diesen Beitrag.

Viel Spaß beim Genießen der letzten Jahre Ihrer gewohnten Existenz!

Dies ist kein Aprilscherz, auch wenn sich die Einleitung so liest.

In der Datenschutzerklärung von Google sorgt Google für maximale Klarheit bezüglich des Google Tag Managers (GTM). Dort erklärt Google zum GTM:

Das wichtige Wort in dieser Google-eigenen Angaben zum Google Tag Manager ist von mir fett gedruckt. In der Grundform heißt der Begriff als Substantiv:

Datenerhebung

Ein Blick in den Art. 4 Nr. 2 DSGVO verrät, dass die Datenerhebung eine Datenverarbeitungstätigkeit ist:

„Verarbeitung“ jeden mit oder ohne Hilfe automatisierter Verfahren ausgeführten Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten wie das Erheben, das Erfassen, die Organisation, das Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die Einschränkung, das Löschen oder die Vernichtung

Art. 4 Nr. 2 DSGVO

Das Erheben kommt also vor dem Erfassen (wenn man anerkannt, was viele anerkennen, dass nämlich die Aufzählung eine zeitliche Reihenfolge vorweist). Auf jeden Fall ist das Erheben etwas anderes als das Erfassen, das Speichern, Anpassen, Verändern oder als eine sonstige Form der Datenverarbeitung.

Das Erheben von Daten beginnt bereits mit deren gewollten Erhalt. Es spielt keine Rolle, ob die Daten tatsächlich erhalten wurden. Vielmehr muss ein Angebot im weitesten Sinne vorliegen, aufgrund dessen ein Datenexporteur (oder spezieller: Dateninhaber) seine Daten auf einem vorgesehen Weg an den Datenverarbeiter schickt. Genauer untersucht habe ich die Datenerhebung in einem eigenen Beitrag. Siehe auch die Orientierungshilfe des BayLDA, etwa ab Rn. 78 (Daten werden zur Aufgabenerfüllung Übermittlung. Dort steht nicht, dass die Daten auch faktisch weiterverarbeitet werden müssen, was sich mit meiner Untersuchung deckt!). Diese Förmelei (Begriff habe ich bei Jens Ferner gelesen) tut hier aber nichts zur Sache, verzeihen Sie bitte diese Entgleisung.

Unstrittig ist, dass der Google Tag Manager Daten erhalten will, weil er ja von Google bereitgestellt wurde. Der Datenerhalt beginnt somit unstrittig, sobald der Google Tag Manager ordnungsgemäß eingebunden wurde, nämlich über eine Adresse wie googletagmanager.com.

Beim Laden des Google Tag Managers wiederum wird aus technisch notwendigen Gründen die IP-Adresse des Nutzers, der eine Webseite besucht, die den GTM einbindet, an Google bzw. den GTM geschickt.

Der GTM kann nur geladen werden, wenn die Netzwerkadresse des Nutzers zum GTM geschickt wird und der GTM diese entgegennimmt, damit das GTM-Script an die besuchte Webseite zurückgeschickt werden kann. Dieses Schicken der Netzwerkadresse kann nur stattfinden, wenn diese erhoben wird. Ohne Erhebung kein Empfang einer solchen Adresse.

Nun behauptet Google aber selbst (siehe ganz oben), dass der Google Tag Manager gar keine IP-Adresse erhebt. Somit kann der GTM gar nicht geladen werden. Somit kann der Google Tag Manager gar nicht genutzt werden.

Google erklärt also selbst, dass der Google Tag Manager nicht mehr funktioniert.

Kurzfassung der Logik, warum der GTM nicht mehr funktioniert:

• Um den GTM zu laden, muss die IP-Adresse des Nutzers zum GTM übertragen werden.
• Der GTM muss die IP-Adresse des Nutzers also zwangsläufig erheben, damit der GTM seinen Dienst verrichten kann.
• Google erklärt aber, dass der GTM die IP-Adresse des Nutzers aber gerade nicht erhebt.
• Somit kann laut Google der GTM gar nicht geladen werden.
• Der GTM ist somit funktionsunfähig.

Danke, Google. Jetzt können sich zahlreiche Marketing-Mitarbeiter endlich nach einer sinnvollen Beschäftigung umsehen. Wem langweilig ist, der kann sich ja mal überlegen, was an der folgenden Aussage falsch ist (diese Aussage ist Teil zahlreicher Datenschutzerklärungen).

Der falsche Satz lautet: Der Google Tag Manager ist keine cookielose Domäne.

Wer in diesem Satz nicht mindestens einen Fehler findet, weiß wenigstens, dass er/sie keine Ahnung von Technik hat. Dieses Wissen muss ja auch nicht jeder haben. Ich kann auch nicht alles. Wenn aber jemand nicht weiß, dass der GTM keine Domäne ist, dann sollte dieser jemand wenigstens nicht andere durch seinen Vortrag auf einer Datenschutzveranstaltung belästigen (kürzlich so geschehen und trotz Hinweis auf die Fehlleitung, dass der Google Tag Manager keine Domäne ist, erfolglos hinsichtlich der Einsicht des Verursachers dieser unsinnigen Aussage; wäre nicht so schlimm, wenn der Unsinnsverursacher nicht auch noch ein Produkt angepriesen hätte, was er als DSGVO-konform bezeichnet hat).

Nebenbei bemerkt, ist der Google Tag Manager auch nicht cookielos. Google gibt dies sogar selber zu.

Fazit

Der Google Tag Manager funktioniert nicht. Jedenfalls ist das die Konsequenz aus dem, was Google schreibt. Oder meint Google etwa, IP-Adressen hätten keinen Personenbezug? Diese Frage hatten EuGH und BGH doch schon beantwortet (siehe Urteile „Breyer“: EuGH-Urteil vom 19.10.2016 – C-582/14, BGH-Urteil vom 16.05.2017 – VI ZR 135/13). Selbst die Facebook-freundliche irische Datenschutzaufsicht hat schriftlich festgehalten, dass es ausreicht, einen Datenwert nur eine sehr kurze Zeit lang zu kennen, damit ein Personenbezug vorliegen kann. Google kann übrigens mindestens dann direkt einen Personenbezug herstellen, wenn ein Nutzer in seinem Google Konto angemeldet ist, während er eine Webseite besucht.

Alle, die den GTM immer noch einsetzen wollen, obwohl dieses Tool funktionsuntüchtig ist, sollten wenigstens die rechtlich relevanten Ausführungen von Google zum Tag Manager lesen. Dann nämlich besteht die Chance, dass der GTM nie wieder eingesetzt wird. Wer bis zu Ende lesen will, was Google da alles erklärt, wird einige Tage lang beschäftigt sein (sofern der Leser versucht, alles zu lesen und das auch alles zu verstehen).

Wer dann immer noch beim Google Tag Manager bleiben will, sollte ihn erst nach Einwilligung laden. Die Gründe dafür sind vielfältig.

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

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.

Zahlreiche deutsche Leitmedien berichteten über die Cookie-Umfrage von GMX und Web.de. Das Ergebnis der angeblich repräsentativen Umfrage lautete: Die Mehrheit der Deutschen sei genervt von Cookie-Abfragen. Diese Aussage kann sicher auch ohne Umfrage als gesichert angenommen werden. Der Grund für diese Unzufriedenheit ist aber nicht die DS-GVO, wie die Umfrage vielleicht suggeriert. Der Grund sind die hauptsächlichen Nutznießer der Datenverarbeitung, wie man Internetkonzerne mit überwiegend amerikanischen Wurzeln auch bezeichnen könnte.

Am Anfang des Beitrags von GMX (der Beitrag wurde am 23.03.2026 von GMX entfernt) wird eine angebliche Lösung aus dem Dilemma präsentiert: Die Cookie-Alternative PIMS. PIMS soll eine zentrale Einwilligungsverwaltung sein (weiter unten erkläre ich das Grundprinzip). Kaum überraschend, dass eine solche „Lösung“ von der United Internet AG vorgehalten wird. Hier muss man wissen, dass zur United Internet AG (, Adresse: Elgendorfer Str. 57, 56410 Montabaur) folgende Unternehmen gehören oder ihr zuzurechnen sind:

• 1&1 (1&1 Telecommunication SE, Adresse: Elgendorfer Str. 57, 56410 Montabaur)
• GMX bzw. offiziell 1&1 Mail & Media GmbH
• Web.de bzw. offiziell 1&1 Mail & Media GmbH
• European netID Foundation, Adresse: Elgendorfer Str. 57, 56410 Montabaur

Die netID mit derselben Adresse (Straße, PLZ, Ort) wie die United Internet AG hatte ein Gutachten bei Prof. Schwartmann zu PIMS in Auftrag gegeben. PIMS war das, was in der Umfrage von GMX und Web.de als Lösung für das Cookie-Dilemma präsentiert wurde. Prof. Schwartmann war zum Zeitpunkt der Gutachtenerstellung Mitglied des Stiftungsrates der netID und ebenfalls Vorstandsvorsitzender der GDD, einem Datenschutzverband. Außerdem ist Prof. Schwartmann Autor für Web.de. Es erscheint nicht als neutralste und glaubwürdigste Lösung, ein Gutachten in eigener Sache von einem engen Mitarbeiter erstellen zu lassen.

Zudem wurde im Rahmen des Gesetzgebungsverfahrens zum TTDSG im Jahr 2021 massiv Einfluss auf den Gesetzgeber genommen, woraufhin der § 26 TTDSG entstand. Das konnte man in den veröffentlichten Stellungnahmen zum Gesetzestentwurf und den jeweiligen Rückmeldungen einiger Unternehmen und Organisationen zum TTDSG-Entwurf nachlesen, weil der Bundestag diese veröffentlichte. Seit Mai 2024 heißt das TTDSG übrigens TDDDG.

GMX und Web.de haben also eine Umfrage in Auftrag gegeben, deren Ziel es ist, ihre eigene Lösung zu bestätigen. Was liegt da näher, als die Frage so zu stellen, dass die Antwort prozentual auf jeden Fall so ausfällt wie gewünscht? Ein fiktives Beispiel von mir:

Wie finden Sie die Bundesregierung? Bitte kreuzen Sie alle Antworten an, die zutreffen (bitte so viele wie möglich):

• Die Bundesregierung leistet nicht selten keine sehr gute Arbeit.
• Mindestens ein Mitglied der Bundesregierung ist mir nicht sympathisch.
• Ich kenne mindestens ein Mitglied der Bundesregierung, das nicht an jeder Kabinettssitzung teilnimmt.
• Manchmal kommen Entscheidungen zustande, die ich nicht nachvollziehen kann.
• Ich habe den Eindruck, dass diese vielen ausgeschütteten Corona- und Kriegshilfen nicht finanziert werden können.
• Ich habe den Eindruck, dass manchmal zu wenig Hilfsgelder und einige Male wiederum zu viele Hilfsgelder ausgeschüttet werden.
• Ich bin mit der Bundesregierung und all ihren Mitgliedern jederzeit und immer wirklich restlos zufrieden und glücklich und bin jederzeit froh, dass wir eine so tolle Bundesregierung haben und würde mir wünschen, dass diese Bundesregierung für die nächsten 7000 Jahre weiter regieren wird und dass deswegen sofort eine Grundgesetzänderung erlassen wird, die unseren aktuellen Bundeskanzler unsterblich macht und ihn auf alle Zeit einsetzt.

Das Ergebnis dieser fiktiven Umfrage wird aus rein logischen, mathematischen Gründen sein, dass über 90 % aller Befragten eine Antwort geben, die eine Unzufriedenheit mit der Bundesregierung ausdrücken.

Ähnlich wurde die tatsächliche Frage nach der Zufriedenheit der Deutschen mit Cookie-Abfragen formuliert:

"Nutzer von Websites und Apps werden häufig über Cookie-Banner gefragt, ob sie dem Einsatz von Cookies zustimmen, sie ablehnen oder individuelle Einstellungen vornehmen möchten. Welche der folgenden Aussagen treffen auf Sie persönlich im Umgang mit diesen Einwilligungs-Bannern zu? Markieren Sie bitte alles Zutreffende."

Als Antwortmöglichkeiten, die laut Umfragetext in beliebiger Anzahl markiert werden sollten, wurden genannt (Zitat):

• Mich nerven diese Einwilligungs-Banner.
• Ich lese mir die Hinweise auf den Einwilligungs-Bannern genau durch.
• Die Einwilligungs-Banner sind mir egal, ich klicke einfach irgendwas an.
• Die Einwilligungs-Banner geben mir ein Gefühl von Selbstbestimmung über meine Daten.
• Ich verstehe die Hinweise auf den Einwilligungs-Bannern nicht.
• Keine dieser Aussagen trifft auf mich zu.
• Weiß nicht / keine Angabe

Als Schlagzeile für das Ergebnis dieser Befragung wurde genannt: "Mehrheit der Internet-Nutzer von Cookie-Abfragen genervt". Die Mehrheit waren hier 53 %, die die erste Antwort ankreuzten. Das sind weniger als ich dachte.

Ich selbst würde die einzige positive Antwortmöglichkeit nicht ankreuzen, ebenso wenig wohl jeder andere, der genügend über Einwilligungsabfragen weiß.

Die Wahrheit über Cookie-Banner

Nicht die DSGVO ist schuld an den nervigen Cookie-Bannern, sondern in erster Linie die Internet-Industrie, auch wenn es Bitkom und andere Lobbyverbände es gerne anders darstellen. Das sind Unternehmen, die Geld mit bestimmten Internet-Geschäften verdienen. Ich gebe hierfür folgende Beispiele:

• Unternehmen, die viel Geld mit online Werbung verdienen. Beispiele: Google, Facebook oder Werbemarktplätze wie Criteo
• Cookie-Tool-Anbieter wie UserCentrics, Cookiebot, Borlabs Cookie oder OneTrust (viele davon transferieren die Consent-Tool-Daten in die USA oder zu Unternehmen mit USA-Bezug, was sie unbrauchbar macht)

Beide Unternehmensgruppen haben es geschafft, Webseitenbetreiber derart zu verwirren, dass viele meinen, sie müssten ein Cookie-Banner auf seiner Webseite integrieren. Weiterhin meinen viele, dass sie unbedingt Google Analytics oder den Facebook Pixel einsetzen müssten oder dass sie Google Ads Werbung buchen müssten oder unbedingt eine Facebook Unternehmensseite bräuchten (und auf Facebook dann Werbung machen müssten).

Genau dies führte zum völlig unnötigen Wildwuchs der an sich meist unbrauchbaren, rechtswidrigen Cookie-Abfragen. Nichts davon hat mit der DSGVO zu tun. Weiterhin verraten Internetkonzerne wie Google gar nicht, wie genau und wofür sie die Daten von Ihnen und mir verarbeiten und an wen sie diese weitergeben. Facebook weiß es ja selbst nicht einmal, wie ein geleaktes Dokument zeigt.

Wenn Sie als Webseitenbetreiber etwa das Google Maps Plugin mit Cookies einbinden, dann können Sie dies nicht rechtskonform tun. Denn Google Maps nutzt zahlreiche Cookies, deren Zwecke sie fast alle nicht kennen können. Sie müssen diese Zwecke (im allermindesten Fall die Namen und Lebensdauern der Cookies) aber kennen, damit Sie dieses Plugin rechtskonform nutzen können (vgl. Art. 13 DSGVO und EuGH-Urteil zu Planet49).

Die meisten Cookie-Abfragen funktionieren aus mehreren Gründen nicht. Hier in Kürze:

• Die Zwecke der Cookies sind oft unbekannt, müssen aber erklärt werden (siehe oben)
• Sogenannte Cookie-Scanner sind eher Bullshit als eine Lösung
• Sogenannte Cookie-Blocker sind aus technischen Gründen Bullshit
• Cookies sind nur ein Teil der Wahrheit (siehe Beitrag)
• Viele Anbieter von Cookie-Tools kennen Datenschutzregeln selbst nicht

Die Belege hierfür können Sie in meinem Blog nachlesen, etwa hier:

• Fünf Gründe für das Scheitern von Cookie-Tools
• Praxistest Consent Tools

Zentrale Einwilligungsverwaltung

Fast jeder möchte weniger Cookie-Popups sehen oder diese ganz eliminieren. Aber die angebliche Lösung, eine zentrale Abfrage einzuführen, die alle Einzelabfragen ersetzt, funktioniert nicht. Genau das wird aber von netID und "Anhang" (United Internet AG, GMX, Web.de, Teile der GDD) suggeriert.

Die Grundidee von PIMS ist, soweit ich es verstanden habe:

Das Konzept hinter der zentralen Einwilligungsabfrage kann mit folgenden Schritten erklärt werden, die sich in der Grafik widerfinden (bis auf Punkt 4, die Verzweiflung des Webseitenbetreibers):

1. Ein Nutzer, also Sie, geht auf eine Webseite, am besten von der netID bzw. der United Internet AG. Dort geben Sie Ihre Einwilligung für tausende bzw. hunderttausende von Zwecken oder lehnen etwas ab. Natürlich gehen Sie die Liste aller hunderttausend Einträge durch und wählen nur die Zwecke ab, die sie schlecht finden. Mit Zwecke meinen viele Cookies, nur zum Verständnis, auch wenn das falsch ist.
2. Dann besucht der Nutzer, also Sie, hunderte Webseiten, so wie heutzutage auch.
3. Die vom Nutzer, also von Ihnen, besuchte Webseite fragt nun bei der zentralen Einwilligungsverwaltung nach, also am besten bei der netID oder der United Internet AG. So erfährt die Webseite, dass
   1. Sie entweder mit allen Cookies einverstanden sind (gesetzlich geregelte Nebensächlichkeiten wie den Einsatz von Google Fonts von einem amerikanischen Server oder Tracking Requests von Google Analytics ohne Cookies lassen wir mal bei Seite, ist nicht so wichtig. Keine Ahnung, warum das LG München einem Kläger 100 Euro Schadenersatz zusprach oder warum die sich die französische Datenschutzaufsicht CNIL so geriert und Google Analytics generell für rechtswidrig hält)
   2. oder Sie mit allen Cookies nicht einverstanden sind (den Rest lassen wir mal weg, denn es geht bei der GMX und Web.de Umfrage ja nur um Cookies, nicht um weitere wichtige gesetzliche Regelungen wie Art. 5 DSGVO, Art. 25 DSGVO oder Art. 49 DSGVO),
   3. oder Sie mit einigen Cookies einverstanden, mit anderen nicht einverstanden sind,
   4. oder Sie gar nicht nach allen Cookies, die auf zukünftig von Ihnen besuchten Webseiten verwendet werden, gefragt werden,
   5. oder Sie noch gar keine Entscheidung getroffen haben oder die Zentrale noch gar nicht besucht haben.
4. Der Betreiber der Webseite ist nun weniger oder mehr verzweifelt, je nach Unterfall zu Punkt 3. Idealerweise (Punkt 3, Unterfälle 1 und 2) wird die Webseite
   • kein Cookie-Popup anzeigen
   • und außerdem natürlich alle „Cookies blockieren“, auch wenn das bisher nicht der Fall war, aber eine Zentrale kann vielleicht ein Wunder bewirken
   • und außerdem in der Datenschutzerklärung, Pardon Cookie-Erklärung, die Zwecke aller eingesetzten Cookies ordentlich und rechtskonform auflistet, obwohl dies bisher bei ca. 95 % der Webseiten mit Cookie-Popup nicht der Fall war

Wenn Sie die zentrale Einwilligungsverwaltung noch gar nicht aufgerufen oder dort keine Angaben gemacht oder dort nicht alle für die gerade besuchte Webseite relevanten Angaben gemacht haben oder nicht machen konnten, ja dann muss die besuchte Webseite leider doch ein Cookie-Popup anzeigen. Das ist viel mehr Aufwand für den Betreiber der Webseite.

Er müsste sogar teilausgefüllte Cookie-Popups präsentieren. Aber lassen wir diese ganzen nervigen Details, mit denen niemand belästigt werden will, einfach weg. Irgendwie wird das schon klappen. Das wird die United Internet AG, netID oder sonst wer sicher irgendwie hinbekommen. Schließlich bekommt es die United Internet AG ja auch hin, auf ihrer Webseite united-internet.de eine ordentliche „Cookie-Abfrage“ bereitzustellen. Ach nee, doch nicht:

Hier ein paar Problemchen mit der Cookie-Abfrage auf der United Internet AG Webseite:

• Es geht nicht nur um Cookies, siehe Beitrag. Leider kennt hier jemand die Datenschutzregeln nicht gut genug, wie es scheint. Auf dem „Cookie Popup“ fehlen leider genaue Angaben zur Datenverarbeitung und zu den eingesetzten Cookies, daher kann man nur spekulieren.
• Wie eben gesagt: Details (Pflichtinformationen gemäß Art. 13 DSGVO!) fehlen leider.
• Ablehnen kostet mehr Klicks als zustimmen. Schade für Sie und mich, gut für die United Internet AG.
• Das Ablehnen ist über einen Link „Einstellungen“ zugänglich (im Screenshot nicht gezeigt). Der genannte Link ist so ausgeprägt, dass der Mauszeiger nicht als Mauszeiger erscheint, wenn man über den Link führt, sondern als Textmarkierungs-Cursor angezeigt wird. Ganz anders bei „Zustimmen“. Da wird ein schöner Mauszeiger, wie man ihn kennt, präsentiert, wenn man über den Button fährt, der zudem optisch deutlich hervorgehoben ist.
• Der konkrete Hinweis auf die Widerrufsmöglichkeit gemäß Art. 7 Abs. 3 DSGVO fehlt.
• Sind die vier Cookies mit Laufzeiten von teils zwei Jahren und einer Wertausprägung, die teils als enorm und teils als Identifizierer bezeichnet werden darf, also alle technisch notwendig und somit einwilligungsfrei? Ich bezweifle das sehr stark, die United Internet AG anscheinend nicht.

Lassen wir mal beiseite, dass die United Internet AG selbst nicht ausreichend über Datenschutzregeln informiert zu sein scheint. Ist nicht so wichtig bei einer Firma, die sich für eine Datenschutzlösung einsetzt.

Die Wahrheit über Cookie Abfragen lautet:

Meine Kritik an PIMS, der zentralen Einwilligungsverwaltung, hatte ich bereits formuliert. Zuletzt gab es dazu auch einen Podcast.

Die zentrale Einwilligungsverwaltung ist Bullshit. Einige der Gründe in Kürze:

• Die zu benennenden Zwecke von Cookies und weiterer Datenverarbeitung von Plugins wie von Google kennt niemand. Sie zentral zu erklären funktioniert genauso wenig wie sie pro Webseite zu erklären.
• Pro Zweck ist eine Einwilligung einzuholen. Google Analytics kann für dutzende, eher für tausende verschiedene Zwecke verwendet werden. Wer sammelt diese in einer Liste und fragt diese dann ab?
• Wer ist verantwortlich für die zentrale Bullshit Abfrage? Die Webseitenbetreiber ja wohl nicht, denn sie dürfen sich auf die Abfrage an einer zentralen Stelle verlassen, auf die sie selber eher keinen Einfluss haben dürften (falls doch, wäre es ja keine zentrale Abfrage, sondern eine milliardenfache Sammelabfrage für Millionen von Einzelwebseiten).
• Wer erfindet eigentlich die Texte für die tausenden von Plugins, wie etwa Google Analytics oder Google Maps? Wird dafür ein Datenschutzgenerator eingesetzt? Nur zur Sicherheit: Das war natürlich ein Scherz.
• Für welche Plugins wird eigentlich eine Einwilligung abgefragt? Ich kenne jedenfalls die meisten Plugins weltweit nicht. Sicher weiß hier der United Internet AG Konzern mehr.
• Was passiert, wenn auf einer Webseite 10 einwilligungspflichtige Tools eingebunden werden, in der Zentrale (bei der netID?) aber nur 7 Einwilligungen abgefragt werden?
• Was passiert, wenn auf einer Webseite eine Einwilligung abgefragt werden müsste, der Besucher der Webseite die Zentrale (bei der netID?) aber noch gar nicht besucht hat?
• Nein, für einen vernetzten Toaster benötigt man kein PIMS von der United Internet AG oder netID oder wem auch sonst. Dafür reicht der bisherige Mechanismus, nämlich eine App vom Hersteller. Das Beispiel wurde von "United Internet AG Jüngern" mal gebracht, deswegen greife ich es hier auf.
• Cookie Blocker funktionieren noch weniger, wenn eine zentrale Einwilligungsabfrage verwendet wird, die (hoffentlich) technisch gar keine Kontrolle über die von Ihnen besuchten Webseiten hat.
• Warum soll ein Webseitenbetreiber, der jetzt schon Datenschutzregeln nicht einhält, auf einmal mehr Aufwand betreiben, um nun alles richtigzumachen?
• Die zentrale Einwilligungsabfrage ist nicht europarechtskonform, wie eine Stellungnahme von Rechtsanwalt Dr. Simon Assion ergab, der dieses vor der Gesetzgebung des § 26 TTDSG erstellte.

Anhand dieser sehr langen Liste mit Kurzgründen können Sie erahnen, wie schlecht die Idee einer zentralen Einwilligungsverwaltung ist.

Browser-Plugins sind übrigens auch keine Lösung, auch wenn die von mir ansonsten geschätzte Organisation noyb das meint. Sie finden die Argumente in meinem Blog.

Die Lösung

Leider gibt es keine einfache Lösung, die für alle gleich ist. Bedauerlicherweise funktioniert eine zentrale Einwilligungsabfrage nicht, wie sie die United Internet AG oder die netID oder GMX oder Web.de oder die GDD oder sonst wer einführen möchte.

Cookie-Popups können nur vermieden werden, wenn es keine einwilligungspflichtigen Vorgänge gibt. Das letzte Zeichen vor diesem Satz war ein Punkt. Sie finden Details hierzu in diesem Blog. Diese Lösung ist recht einfach, jedenfalls für die meisten Webseiten. Siehe besipielsweise meine Webseite, die zahlreiche Funktionen bereitstellt.

Übrigens ist es nicht erforderlich, für ein Video, welches nur auf einer Unterseite Ihrer Webseite eingebunden ist, ein Cookie-Popup zu präsentieren, welches beim Einstieg auf jeder beliebigen Unterseite Ihrer Webseite angezeigt wird. Man kann bei visuellen Elementen wie Videos oder Karten auch auf dem Element eine Einwilligungsabfrage vorhalten. Oder noch besser: Nutzen Sie doch datenschutzfreundliche Alternativen. Statt Google Maps etwa mein Karten-Plugin auf Basis von OpenStreetMap. Dafür brauchen Sie gar keine Einwilligung einzuholen. Oder statt Google Analytics lieber Matomo nehmen. Dieses Analyse-Tool kann auch ohne Einwilligung eingesetzt werden. Oder für das Conversion Tracking eine eigene Logik nutzen (die ist es Ihnen doch sicher Wert, wenn Sie schon tausende Euro auf Google Ads draufwerfen, oder?).

Einleitung

Update Ende 2024: Jentis versuchte mehrfach, den Verfasser dieses Textes direkt und indirekt zu kontaktieren. Hieran besteht allerdings kein Interesse, weil bisherige Gespräche mit Jentis fruchtlos waren (siehe unten).

Update Mai 2024: Das TTDSG heißt nun TDDDG. Außer dem Namen hat sich nicht wirklich etwas geändert.

Update 2023: Eine Kommunikation mit Jentis, die ich im März 2023 im Kundenauftrag führte, zeigte mir erneut, dass Jentis nicht empfehlenswert ist. Jentis wirbt mit „Cookieless“. Übersetzt heißt das „Cookielos“, also frei von Cookies. Jentis nutzt aber Cookies, wie deren eigene Webseite zeigte. Jentis konnte mir auf mehrere Rückfragen keine einzige Webseite (inklusive der Jentis-eigenen Webseite) zeigen, die Jentis so nutzte, dass ich der jeweiligen Webseite eine Einwilligungsfreiheit zugestehen würde. Vielmehr meint Jentis mit „Cookieless“, dass keine Drittpartei-Cookies eingesetzt werden. Entweder kann Jentis kein Englisch oder will die sogenannte Cookie-Regel nicht kennen, die durch die ePrivacy-Richtlinie europaweit eingeführt und in Deutschland in § 25 TTDSG ausgestaltet wurde. Dort gibt es keine Drittpartei-Cookies, sondern nur erforderliche und nicht erforderliche Cookies. Jentis-Cookies sind jedenfalls objektiv nicht erforderlich: Besucher können auch ohne Cookies gezählt werden. Sogar Google Analytics kann ohne Cookies genutzt werden (ist dann aber immer noch einwilligungspflichtig)

Motivation für diesen Beitrag ist meine Äußerung zum serverseitigen Tagging. Ich wurde dazu auch auf Meedia interviewt. Es ging konkret darum, wie man Google Analytics überhaupt noch rechtskonform nutzen kann. Viele sind sich mit mir einig, dass Google Analytics selbst nach Einwilligung nicht mehr rechtskonform über eine direkte Einbettung in eine Webseite nutzbar ist. In einem konstruktiven Gespräch wurde ich etwas provokant in einen Topf mit den Aussagen von Jentis gesteckt, weil ich einen serverseitigen Ansatz diskutierte, der auf Verschlüsselung basiert. Allerdings existierten bei Nutzeranalyse immer personenbezogene, personenbeziehbare oder pseudonyme Daten beim Datenexporteur. Rein anonyme Daten, wie Jentis sie in Aussicht stellt, gibt es nicht, wenn Daten exportiert werden, denn die Daten sind mindestens beim Exporteur nicht anonym.

Alles, was ich im Folgenden schreibe, beurteile ich nach deutschem und europäischem Recht. Jentis wird von einer Firma aus Österreich angeboten. Dort gilt das deutsche TTDSG nicht. Die ePrivacy Richtlinie sollte allerdings in Österreich ebenfalls Geltung haben, unabhängig davon, ob die Österreicher diese bereits in nationales Recht gegossen haben oder nicht (vgl. BGH-Entscheidung zu Planet49. Man könnte im Zweifel auch den EuGH fragen, was er davon hielte, dass ein Mitgliedsstaat eine Richtlinie nicht in Recht gießt, obwohl vorgeschrieben; gleiches gilt bei Abmilderung von ePrivacy aufgrund nationaler Vorgaben).

Meine Ausführungen beziehen sich auf bisherige Kommunikation mit Jentis sowie die auf der Webseite von Jentis gegebenen Aussagen. Außerdem betrachte ich Webseiten Dritter, die Jentis einbetten. Ob die Rechtsabteilung von Jentis die Sachlage anders beurteilt als die Werbeabteilung, die auf der Webseite öffentlich wird, kann ich nicht beurteilen.

Update: Mit Jentis gab es auf deren Wunsch hin eine gute Abstimmung per Videokonferenz. Wir haben über die Inhalte Vertraulichkeit vereinbart. Jentis ist als rein europäisches Unternehmen nach meiner Wahrnehmung besser als Google, was Datenschutz angeht und ist sicher auch erreichbarer, etwa bei Abstimmungsbedarf. Wir bleiben weiter im Austausch. Die Gesprächsinhalte habe ich nicht weiter in diesen Beitrag einfließen lassen, bis sie offiziell sind. Mittlerweile gab es ein weiteres Gespräch, initiiert durch Jentis. Mir wurden Informationen gegeben, wie die Daten pseudonymisiert werden, damit sie hoffentlich anonym bei Drittanbietern wie Google ankommen. Dabei wird unter anderem mit Paketen gearbeitet, die aus mehreren Einheiten (Hits) bestehen. Erst wenn ein Paket voll ist, wird es abgeschickt, etwa an Google. So soll der zeitliche Zusammenhang der Hits entfernt werden. Ich habe Jentis gebeten, eine konkrete Untersuchung anzustellen, aus der hervorgeht, dass die aus Datenschutzgründen verfremdeten oder reduzierten Daten, die zu Google gehen, dennoch zu einem fachlichen Nutzen des Tools Google Analytics (als ein Beispiel) führen. Bis auf Weiteres sehe ich diesen möglichen Nutzen nämlich nicht als besonders hoch an. Man könnte, sage ich, auch jedes andere Tool statt Google Analytics nehmen, wenn die Datenqualität für den Export aus rechtlichen Gründen reduziert wird.

Jentis hat sich dem serverseitigen Tracking angenommen und bezeichnet sich selber als „das fortschrittlichste und konformste serverseitige Tracking auf dem Markt“ (Quelle: https://www.jentis.com/de/compliance-mit-jentis/). Um es vorab zu sagen: Das halte ich persönlich für eine Veralberung der Leser, wenn man annimmt, dass mit "konformste" eben "datenschutzkonformste" gemeint ist. Wahrscheinlich soll eben dies suggeriert werden, denn in der genannten Quelle sind die ePrivacy-Richtlinie und die DSGVO "positiv abgehakt".

Woher weiß Jentis eigentlich, welche Angebote es auf dem Markt gibt? Da Jentis auch den California Consumer Privacy Act (CCPA) als erfüllt angibt, ist wohl der weltweite Markt gemeint.

Mit einem Mitarbeiter von Jentis hatte ich im April 2021 einmal kommuniziert und mir deren Präsentation zum angeblich datenschutzkonformen Tracking angesehen. Was mich damals schon wunderte, war das merkwürdige Verständnis von Datenschutzgesetzen. Verbiegt man die Vorgaben nur lange genug, kommt das gewünschte Ergebnis heraus, so meine Wahrnehmung der Argumentationslinie.

Doch bevor wir etwas tiefer einsteigen, hier der Werbeslogan von Jentis.

Die Aussage von Jentis ist fachlich falsch. Denn sie besagt, dass die Anonymisierung vor dem Datentransfer stattfindet. Das ist falsch. Anonyme Daten liegen höchstens beim Datenimporteur vor, nicht aber beim Datenexporteur. Wenn der Datenexporteur anonyme Daten hätte, wäre eine Nutzeranalyse per definitionem unmöglich.

Wer sich mit Datenschutz beschäftigt, weiß, wie schwierig die Anonymisierung von Daten ist. Wer bei sich selbst anonyme Daten haben will, muss sämtliche Verfremdungsmöglichkeiten so gestalten, dass sie nicht rückführbar sind. Dazu gehört auch das Vergessen von Schlüsseln. Ich bezweifle sehr, dass Jentis das tut. Vor dem Datentransfer an Dritte sind die Daten jedenfalls nicht anonym, außer, man verwendet Daten ohne jeden Gehalt. Mit rein anonymen Daten kann niemand irgendetwas analysieren. Etwas anderes mag es sein, wenn die Daten beim Datenexporteur im besten Fall pseudonym und beim Datenimporteur anzunehmenderweise anonym sind. Vergleiche etwa Art. 4 Nr. 5 DSGVO. Dazu muss mindestens gewährleistet sein, dass der Datenimporteur den Schlüssel zur De-Anonymisierung der Daten niemals erhalten kann. Hier spielt auch das EuGH-Urteil zu IP-Adressen ("Breyer") eine Rolle. Der EuGH hatte nämlich entschieden, dass IP-Adressen dann personenbezogene Daten sind, wenn es eine objektive Möglichkeit gibt, den Anschlussinhaber zu ermitteln. Dies bedeutet insbesondere eine Rechtsverfolgungsmöglichkeit, etwa in Form einer Strafverfolgung. Auch vertragliche Vereinbarungen wären eine solche Möglichkeit.

Webseite von Jentis

Bevor eine Analyse des Jentis Tools kommt, noch ein paar Worte zur Webseite von Jentis. Die Webseite jentis.com besticht aus meiner Sicht durch eine gewisse Ignoranz gegenüber Datenschutzgesetzen. Wer eine datenschutzrechtlich schlampige Webseite vorhält, hat es nach meinem Dafürhalten nicht verdient, Vertrauen zu genießen.

Ich habe mir erlaubt, meinen Webseiten-Scanner (Vollversion) einmal über die Seite laufen zu lassen. Hier ist das automatisiert ermittelte Ergebnis:

Es sieht also anscheinend nicht gut aus. Merkwürdig, dass ein Anbieter des angeblich konformsten serverseitigen Trackings so einfache Dinge wie die eigene Webseite nicht geregelt bekommt. Mein Cookie-Scanner liefert folgendes Ergebnis:

Das Analyseergebnis zeigt die ohne Einwilligung von der Jentis-Webseite verwendeten Cookies, die nach meinem Verständnis technisch nicht notwendig sind. Mindestens die rot gedruckten Einträge sind nach meiner Einschätzung rechtswidrig in Deutschland (§ 25 TTDSG) und in allen anderen EU-Ländern, in denen die ePrivacy-Richtlinie anzuwenden ist. Letzteres sollte überall in der EU der Fall sein, soweit ich informiert bin.

Wie ich durch weitere Untersuchungen herausfand, wird zudem Google reCAPTCHA samt einem Cookie ohne Einwilligung genutzt. Dabei hatte ich nicht mal ein Formular ausgefüllt (vielleicht wird das unsichtbare CAPTCHA verwendet, was bezüglich des Cookies immer noch kritisch wäre). Das oben genannte Pipedrive ist nach meiner Recherche ein Unternehmen mit Sitz in den USA. Hier sei als Stichwort nur Schrems II erwähnt. Ein kleiner Trost für Jentis. Auch die DSK und der BfDI kennen das Schrems II Urteil anscheinend nicht.

Jentis Cookies

Schön, dass Jentis die Verwendung von Cookies wenigstens selbst zugibt: „Die Websiten der JENTIS verwenden Cookies. Bei Cookies handelt es sich um Textdateien, die über einen Internetbrowser auf einem Computersystem abgelegt werden.“

Dies ist wieder einmal falsch, denn Cookies sind keine Textdateien. Den Nutzer interessiert es übrigens nicht, in welchem Datenformat Informationen oder personenbezogene Daten abgespeichert werden. Hat sich darüber schon einmal jemand Gedanken gemacht?

In den Datenschutzhinweisen von Jentis werden ein paar angeblich unbedingt erforderliche Cookies genannt:

Die weiter oben von mir genannten Cookies sind in dieser Übersicht nicht enthalten. Sie würden also rechtswidrig genutzt, wenn ohne Einwilligung, weil sie erklärtermaßen technisch nicht notwendig sind.

Ein superkonformes Tracking, welches gleich drei angeblich unbedingt erforderliche Cookies nutzt? Das ist sehr sportlich. Ich würde es als Volksverdummung bezeichnen (für den Fall, dass diese Erklärung den Tatsachen entspricht und jeder Nutzer anlasslos derartig nachverfolgt wird). Interessant, dass der Unterschied in den Zwecken der Cookies jts-rw und jctr_uid in einem Leerzeichen besteht.

In der Jentis Cookie Dokumentation steht jedenfalls, dass diese drei Cookies beim Einbetten des Jentis Javascript Codes genutzt werden.

Sonstige Probleme

Auf der Jentis-Webseite wird auch der Dienst Pipedrive verwendet. Was es mit Pipedrive auf sich hat, erklärt Jentis lieber ebenfalls nicht. Besser einen Verstoß gegen Art. 6 DSGVO oder andere Rechtsvorschriften (Art. 5 DSGVO, Art. 32 DSGVO, Art. 25 DSGVO, ggf. Art. 44ff DSGVO) begehen, ihn dann aber nicht auch noch zugeben und somit noch einen Verstoß, nämlich gegen Art. 13 DSGVO, begehen.

Auf weitere Probleme mit dem Datenschutz auf der Jentis-Webseite gehe ich hier nicht näher ein. Nur soviel: Vielleicht hat es sich bei Jentis noch nicht herumgesprochen, dass der Einsatz von Google Fonts keine gute Idee ist (Laden von Schriftarten über Google-Server). Vor allem gilt dies für Webseiten, die sich mit Datenschutz befassen. Die Abhilfe wäre sehr einfach: Die Schriften lokal einbinden.

Nach all dem, viele Grüße an Mira, die auf der Jentis Webseite als internationale Rechtsexpertin benannt ist:

Mira müsste das deutsche TTDSG kennen. Zumindest aber die ePrivacy Richtlinie und die DSGVO sollten ihr bekannt sein. Vielleicht wurde Mira nicht gefragt, als die Jentis Webseite gebaut wurde. Oder Mira hat verzweifelt versucht, den Jentis Verantwortlichen klarzumachen, dass bestimmte Dinge "Dudu" sind. Da hatten die Jungs und Mädels von Jentis aber gerade ihre Kopfhörer auf und hörten vielleicht Musik von Hubert von Goisern, der auch aus Österreich stammt.

Das Jentis Paradigma

Ich nenne den Ansatz von Jentis das Jentis Paradigma, weil ich diesen Ansatz für krude halte und in den Bereich der Verschwörungstheorien eingruppieren würde.

Die folgende Aussage von Jentis klingt zunächst einmal vertretbar.

Richtig ist: Wer die Datenhoheit hat, kann darüber entscheiden, was mit den Daten passiert. Er hat die Kontrolle über die Daten. Soweit so gut. Diese Form der Datenverarbeitung wird gelegentlich als First Party Data bezeichnet.

Ein Cookie zum Zweck der Anonymisierung

Dann geht Jentis aber mit den Werbeaussage in eine Richtung, die ich nicht gut finde.

Jentis nutzt also laut eigener Aussage ein Cookie für das Tracking und bezeichnet dieses sogar als technisch notwendig. Mir ist aus einem Gespräch mit einem Jentis Mitarbeiter hierzu etwas in Erinnerung. Jentis beruft sich tatsächlich auf das berechtigte Interesse, um ein Cookie zwecks Anonymisierung zu nutzen. Jentis beansprucht also anscheinend das Recht auf Anonymisierung. Dass dies an sich schon fragwürdig sein kann, hatte ich bereits in der Vergangenheit ganz unabhängig von Jentis untersucht. Unabhängig davon, hat Jentis gefälligst kein Cookie zu nutzen, um Daten zu anonymisieren, außer es liegt eine Einwilligung vor. Anonymisierung wäre im besten Fall analog zur Löschung, welche ebenfalls eine Datenverarbeitung darstellt, die legitimiert werden muss.

Wer Jentis richtig in Aktion sehen will, muss die Jentis Webseite anscheinend erst einmal verlassen. Womöglich ist es Jentis selbst doch zu heiß, das eigenen Tool mit einem „Anonymisierung-Cookie“ zu nutzen. Wer die Webseite der Sparkasse Österreich (sparkasse.at) aufruft, findet Jentis mit mehreren Cookies vor, die laut Datenschutzhinweisen der Sparkasse alle „wesentliche“ Zwecke haben.

Eine Netzwerkanalyse zeigt, dass diese Cookies tatsächlich ohne Einwilligung genutzt werden (etwa auf Seite https://www.sparkasse.at/tirolersparkasse/wir-ueber-uns/datenschutz-sicherheit/cookies):

Ein Test des Jentis-Scripts, das auf der Sparkassen-Webseite eingebunden wird, zeigt: Dieses Script nutzt tatsächlich Cookies.

In einer Mail an mich am 30.04.2021 von einem Jentis Mitarbeiter wurde mir folgende Aussage gegeben: "JENTIS ist kein Marketing-, Analyse- oder sonstiges Cookie. JENTIS ist eher vergleichbar mit GTM-Serverside. Und der erste shot dient  beim Einsatz von dem Tool AUSSCHLIEßLICH dem berechtigten Interesse des Websitebetreiber zur Anonymisierung des Visitors". Mit „shot“ ist wohl „Cookie“ gemeint.

Wenn Jentis nur mit Hilfe eines Cookies anonymisieren kann, dann schneidet Jentis hier anscheinend schon einmal schlechter ab als alle anderen mir bekannten Analyse-Tools. Diese nutzen entweder kein Cookie oder eines, für das nach einer Einwilligung gefragt wird oder anerkannterweise gefragt werden muss. Bisher war nach meiner Kenntnis kein Anbieter eines Analytics-Tools blöd genug, um eine Datenanonymisierung als Arbeitsgrundlage in Aussicht zu stellen. Wahrscheinlich wurden hier Pseudonymisierung und Anonymisierung verwechselt, entweder absichtlich oder aus Unwissenheit.

Der Analysezweck beginnt bereits beim Betreiber der Webseite und nicht erst bei einem Datenimporteur wie Google Analytics. Dass die eigentliche Analyse womöglich erst bei Google Analytics stattfindet, ändert daran rein gar nichts. Auch die Datenverarbeitung beginnt bereits beim Besuch der Webseite. Die Verarbeitung wird im Beispiel Google Analytics bei Google höchstens fortgeführt, nicht aber alleinig dort vorgenommen.

Anonyme Daten und Zufallswerte

Jentis scheint nicht zu wissen, was anonyme Daten sind. Selbst verschlüsselte personenbezogene Daten sind pseudonyme Daten, und zwar beim Dateninhaber, der auch den Schlüssel kennt. Nur wenn der Schlüssel weggeworfen wird, sind es möglicherweise anonyme Daten. Dann kann man aber auch gleich einfach reine Zufallswerte nutzen, die nicht beim Besuch einer Webseite erhoben werden müssen. Hier ein Beispiel für das Erstellen anonymer Werte in PHP (den möglichen Wertebereich habe ich hier nicht geprüft):

$zufallswert = rand(0,99999999999);

$zufallswert = anomym

Das Ergebnis ist eine Zahl zwischen 0 und 99999999999. Wie man sieht, besteht hier keinerlei Nutzerbezug. Anders sieht es hier aus:

Eingabe = IP-Adresse, besuchte Seite, Zeitpunkt
Ausgabe = Zufallszahl, die mit der Eingabe verknüpft und so weiterverarbeitet wird

Ausgabe = personenbezogener Zufallswert = Online Identifizierer
Begründung: Aus dem Zufallswert könnte objektiv der Personenbezug hergestellt werden, weil der Zufallswert zusammen mit personenbezogenen oder personenbeziehbaren Daten vorlag oder vorliegt (vgl. EuGH-Urteil "Breyer", etwa Rn. 49, oder auch Opinion 4/2007 der Artikel 29 Arbeitsgruppe (erwähnt in Art. 94 DSGVO) oder Ausführungen zum WhatsApp-Fall).

Wer Daten innerhalb einer Sitzung verschlüsselt, so dass ein Vergleich von zu unterschiedlichen Zeitpunkten erhobenen Daten über deren verschlüsselte Werte möglich ist, arbeitet im besten Fall mit pseudonymen Daten. Ganz sicher handelt es sich dabei aber nicht um anonyme Daten. Übrigens sind angebliche Zufallswerte, die zusammen mit personenbezogenen Daten vorliegen, personenbeziehbare und somit ebenfalls personenbezogene Daten. Derartige Werte werden oft als Online Identifier bezeichnet. Sobald ein Wert mit Personenbezug mit einem Wert ohne Personenbezug zusammenkommt, hat auch der Wert ohne Personenbezug einen angenommenen Personenbezug (siehe beispielsweise meine Kommentierung zur Entscheidung der irischen DPA gegen WhatsApp oder auch den Erwägungsgrund 25 zur DSGVO).

Ein Ausflug zum Entscheid des WhatsApp-Bußgelds über 225 Millionen Euro: WhatsApp bildet einen Hash-Wert für einen Kontakt im Telefonbuch eines WhatsApp-Nutzers. Dieser Hash-Wert ist nur sehr kurze Zeit (Millisekunden oder Sekunden) zusammen mit der Telefonnummer des Kontakts zusammen im Speicher. Daraus folgt bereits, dass dieser Hash-Wert personenbezogen ist. Der Entscheid referenziert mehrfach auf das EuGH-Urteil zu IP-Adressen und nennt, neben anderen Gründen, auch Erwägungsgrund 30:

Natürlichen Personen werden unter Umständen Online-Kennungen wie IP-Adressen und Cookie-Kennungen, die sein Gerät oder Software-Anwendungen und -Tools oder Protokolle liefern, oder sonstige Kennungen wie Funkfrequenzkennzeichnungen zugeordnet. Dies kann Spuren hinterlassen, die insbesondere in Kombination mit eindeutigen Kennungen und anderen beim Server eingehenden Informationen dazu benutzt werden können, um Profile der natürlichen Personen zu erstellen und sie zu identifizieren.

Erwägungsgrund 30 DSGVO.

Ein weiterer Beleg dafür, dass Jentis keinerlei Ahnung davon hat, was anonyme Daten sind, wird in den Datenschutzhinweisen von Jentis gegeben. Dort steht (https://www.jentis.com/de/datenschutzerklaerung/, Stand: 17.03.2022):

„Die anonymen Daten der Server-Logfiles werden getrennt von allen personenbezogenen Daten der betroffenen Person gespeichert.“

Auf derselben Seite steht, welche Daten in diesen Server Logs gesammelt werden. Es handelt sich laut deren Abschnitt „Personenbezogene Daten, die wir sammeln und verarbeiten“ um (Zitat)

• Ihren Vor- und Nachnamen;
• Ihre Kontaktinformationen, wie z. B. Telefon und E-Mail-Adresse;
• Ihre geschäftlichen Informationen, wie z. B. Firmenname und Art des Geschäfts;
• Ihre Einwilligungserklärung zum Erhalt unserer Marketingmaterialien, wie z. B. Werbeaktionen und Newsletters;
• Ihre IP-Adresse;
• Betriebssystem; 
• Browser-Typ;
• Browser-Version;
• Browser-Konfiguration;
• sonstige relevante Informationen über Ihren Computer und Ihre Internetverbindung, zur Identifikation des Typs Ihres Geräts, zur Verbindung mit der Website, zum Austausch der Daten mit Ihrem (mobilen) Endgerät oder zur Sicherstellung der ordnungsgemäßen Nutzung der Website;
• die URL und IP-Adresse der Website, von der aus Sie auf die JENTIS Website zugreifen oder von der aus Sie auf unsere Website weitergeleitet werden, einschließlich Datum und Uhrzeit;
• alle Seiten der JENTIS Website, die Sie während Ihres Besuchs anklicken, und alle Links auf unserer Website, die Sie anklicken, einschließlich Datum und Uhrzeit;
• der gesamte Uniform Resource Locator (URL) Clickstream zu, durch und von der Website, einschließlich Datum und Uhrzeit;
• Informationen, die durch Cookies oder ähnliche Technologien gesammelt werden (wie unten erklärt);
• sonstige ähnliche Daten und Informationen, die im Falle von Cyberangriffen auf unsere informationstechnologischen Systeme genutzt werden können.

(Ende des Zitats von https://www.jentis.com/de/datenschutzerklaerung/)

Selbst, wenn man von diesen Daten diejenigen abzieht, die in Formularen eingegeben werden, bleiben noch sehr viele Daten übrig. Welche davon in den Jentis Server Logs landen, wird leider nicht erwähnt. Bitte erklären Sie mir: Handelt es sich bei der schieren Menge der eben genannten Daten um

a) personenbezogene Daten oder

b) personenbeziehbare Daten oder

c) pseudonyme Daten oder

d) anonyme Daten?

Antwort d) ist die richtige, aber womöglich nur, wenn Sie „Jentis“ heißen und Nutzer für dumm verkaufen möchten.

In einer Datenschutzerklärung einer Webseite, die Jentis einsetzt, steht Folgendes:

„Durch JENTIS® gesetzte IDs sind lediglich Zufallsprodukte und dienen der anonymen Wiedererkennung.“

Wer denkt sich so einen groben Unsinn aus, den ich hier als Bullshit bezeichnen möchte? Anonymisierung und Wiedererkennung schließen sich per se aus. Ich verstehe schon, wie Jentis darauf kommt: Wir bilden pro Nutzer einen Zufallswert. Dann ist dieser Zufallswert anonym. Aber so läuft es nicht. Ein Zufallswert ist nicht ohne Personenbezug, wenn der Wert „beim Nutzer“ erhoben wurde. Diese Erhebung findet beispielsweise über die IP-Adresse des Nutzers statt, die Jentis offensichtlich kennt, wenn ein Nutzer eine Webseite aufruft.

Am 17.03.2022 hatte ich folgende Fragen an Jentis über das Kontaktformular der Jentis-Webseite abgeschickt:

Habe ich es richtig verstanden, dass Jentis sagt „Wir anonymisieren Daten beim Webseitenbetreiber. Für diese Daten gilt dann die DSGVO nicht mehr, so dass diese anonymen Daten dann beispielsweise an Google geschickt werden können?“

Sind Sie folgender Meinung: „Jentis verwendet ein Cookie aus dem berechtigten Interesse heraus, um Daten anonymisieren zu können“ ?

Meine Fragen an Jentis

Bisher gab es keine Antwort. Sobald mir diese vorliegt, werde ich sie in diesem Beitrag berücksichtigen.

Fazit

Vielleicht irre ich mich und Jentis anonymisiert Daten tatsächlich. Dann würde ich allerdings jedem raten, von Jentis Abstand zu nehmen, denn anonyme Daten sind Bullshit-Daten, mit denen wirklich niemand etwas anfangen kann. Denn anonyme Daten haben per definitionem keinerlei Personenbezug.

Entweder Jentis anonymisiert also Daten und ist deswegen völlig unbrauchbar, um Nutzeranalysen zu betreiben. Denn Nutzer sind nicht anonym, sondern können höchstens pseudonym erfasst werden. Vergleiche auch den WhatsApp-Fall.

Oder Jentis nutzt ein Cookie, um Daten angeblich zu anonymisieren. Dann ist Jentis einwilligungspflichtig, weiß das aber selber nicht oder stellt es wenigstens öffentlich anders dar.

Oder Jentis nutzt gar keine anonymen Daten, sondern behauptet es nur. Dann ist Jentis Bullshit.

Mein Fazit lautet: Wer Nutzer analysieren will, sollte lieber andere Tools als Jentis nutzen.

Einleitung

Wer Wissensartikel zu Cookies sucht, findet oft fragwürdige Erklärungen. So jedenfalls meine Einschätzung, die ich teilweise auch belegen kann. Hier ein Beleg: Schauen Sie doch mal in die Datenschutzerklärung vieler sogenannter Experten. Dort wird erklärt, Cookies seien Textdateien. Das ist objektiv falsch und war auch schon immer falsch. Den Beweis finden Sie in meinem Bullshit Basics Artikel oder im Fakten-Check zum Google Tag Manager. Es wird auch durch die Begründung, die DSGVO fordere eine einfache Sprache, nicht richtiger.

Erst kürzlich gab es den Plan der Politik, sogenannte Cookie Popups zu eliminieren. Der Plan kann nur unterstützt werden. Der eingeschlagene Weg, dies über Browser Voreinstellungen zu bewerkstelligen, kann allerdings nicht funktionieren. Dies wird auch dadurch nicht richtiger, wenn die von mir sehr geschätzte Datenschutzorganisation noyb mit einem Konzept namens ADPC gleiches fordert.

Spätestens mit dem EuGH-Urteil zu Planet49 ging der Cookie-Hype los. Die ePrivacy Richtlinie sorgte für zusätzlichen Zündstoff, weil sie ebenfalls auf Cookies abzielt. Gemäß BGH-Urteil zu Planet 49 ist das Telemediengesetz in § 15 Abs. 3 TMG konform zur ePrivacy Richtlinie auszulegen.

Wann Cookies eine Einwilligung erfordern, behandelt die Übersicht zu Cookies und Einwilligung auf Websites.

Was sind Cookies?

Cookies sind Datensätze. Sprachlich schöner formuliert, kann man auch von Informationshäppchen sprechen. Ein Cookie wird im Endgerät des Nutzers gespeichert, und zwar von dessen Browser. Jeder Browser kann Cookies auf unterschiedliche Weise abspeichern. Für die Art der Speicherung gibt es keinen Standard. Daher war die Aussage, Cookies seien Textdateien, schon immer falsch. Zwar wurde ein Cookie von vielen Browsern früher in Form einer Textdatei abgespeichert. Aber sicher wird niemand behaupten wollen, alle Browser und deren Speichermechanismen weltweit gekannt zu haben. Zudem gab es schon damals andere Möglichkeiten, als Cookies in Textdateien zu speichern.

Heutzutage werden Cookies von Firefox oder Chrome in Datenbanken gespeichert und nicht in Textdateien. Wer etwas anderes behauptet, sollte den Arzt wechseln oder andere Tabletten nehmen.

Meine folgenden Beschreibungen zu Cookies kratzen nur an der Oberfläche, um erstens allgemein verständlich und zweitens in endlicher Zeit lesbar zu sein.

Wie entstehen Cookies?

Ein Cookie wird bei einem Datenabruf erzeugt. Konkret bedeutet das: Wenn ein Nutzer eine Webseite aufruft und die Webseite Dateien lädt, kann durch das Laden der Datei ein Cookie erzeugt werden.

Dateien sind beispielsweise Schriftarten, Bilder, JavaScript-Bibliotheken, Videos oder sonstige Dienste. Ein Dienst wird oft als Tool bezeichnet. Beispiele für Dienste sind Google Maps, SoundCloud Audio Player, Vimeo Videos oder reCAPTCHAs.

Außerdem kann ein First-Party Cookie durch eine JavaScript-Logik erzeugt werden. Mehr dazu finden Sie weiter unten.

Cookies werden also von geladenen Tools und Dateien erzeugt und verwaltet. Cookies fallen nicht einfach vom Himmel. Auch die gerade besuchte Webseite kann Cookies erzeugen und verwalten.

Gültigkeitsbereich für Cookies

Ein Cookie hat eine Lebensdauer. Im EuGH-Urteil zu Planet49 wurde dies als Funktionsdauer bezeichnet. Das EuGH-Urteil sorgte für Aufsehen, weil es feststellte, dass Art. 13 DSGVO so auszulegen ist, dass zu Cookies die Zwecke und Funktionsdauern zu erklären sind.

Ein Cookie lebt innerhalb einer sogenannten Domäne. Warum manche in Deutschland den Begriff Domain verwenden, bleibt mir für immer ein Rätsel. Die DSGVO fordert eine klare, leicht verständliche Sprache (Art. 12 Abs. 1 DSGVO). Warum der englische Begriff mit genauso vielen Buchstaben, aber weniger Verständlichkeit als der deutsche Begriff verwendet wird, bleibt mir unklar.

Eine Domäne ist, verkürzt gesagte, eine Internet Adresse. Ein Beispiel für eine solche Adresse ist dr-dsgvo.de.

Wird im Browser bei Aufruf einer Webseite eine Datei von der Domäne dr-dsgvo.de abgerufen, kann diese Datei ein Cookie zurückschicken, und zwar nur mit dem Geltungsbereich für die Domäne dr-dsgvo.de.

Das Zurückschicken geschieht folgendermaßen:

1. Auf dem Server, von dem die Datei abgerufen wird, wird ein Cookie erzeugt. Dies geschieht über eine auf dem Server ablaufende Logik, beispielsweise in der Programmiersprache PHP
2. Das Cookie wird beim Zurückschicken der angeforderten Datei aufgrund der Vorgaben des Internet-Protokolls automatisch an den Aufrufer zurückgeschickt
3. Das Cookie wird vom Browser automatisch im Endgerät des Nutzers gespeichert

Ein Endgerät ist ein Smartphone, ein Tablet, ein Desktop PC oder dergleichen. Die Webseite, die eine Datei einbindet, sorgt also mit dieser Einbindung dafür, dass Cookies erzeugt werden können. Auf demselben Weg können auch Cookies gesendet werden.

Senden von Cookies

Angenommen, Sie haben bereits mehrere Webseiten im Internet besucht. Dabei haben sich eine Reihe von Cookies auf Ihrem Endgerät, also auf der Festplatte Ihres Computers, angesammelt. Nun rufen Sie eine der schon besuchten Webseiten erneut ab. Dabei wird eine Datei von der Domäne abcdwxyz.de abgerufen. Aufgrund Ihrer Reise durch das Internet liegt auf Ihrem Endgerät bereits ein Cookie vor, welches als Geltungsbereich die Domäne abcdwxyz.de besitzt. Nun passiert folgendes:

1. Sie rufen eine Webseite X ab
2. Die Webseite bindet eine Datei von der Domäne abcdwxyz.de ein
3. Der Browser schaut in der Cookie-Datenbank auf Ihrem Rechner, die Ihr Browser angelegt hat, nach, ob sich dort Cookies für die Domäne abcdwxyz.de befinden
4. Findet der Browser solche Cookies, schickt er diese Cookies automatisch mit seiner Anfrage mit, die Datei von abcdwxyz.de abzurufen! Die Datei wurde also noch nicht abgerufen, sondern nur angefordert. Diese Anforderung enthält also die bei Ihnen gespeicherten Cookies, welches zur Adresse (Domäne) passen, an die die Dateianforderung gestellt wird

Punkt 4 bedeutet also: Befinden sich bereits Cookies auf Ihrem Computer, werden diese automatisch, aufgrund des Internet Protokoll TCP, beim Abruf von Dateien mitgeschickt! Der Server, der die angeforderte Datei zurückschicken soll, erhält also automatisch das Cookie von Ihrem Endgerät. Beim Zurückschicken der angeforderten Datei kann der Dritt-Server nun den Wert des Cookies ändern, es löschen oder neue Cookies hinzufügen.

Technisch werden First-Party Cookies und Third-Party Cookies unterschieden. First-Party bedeutet Erstanbieter und Third-Party bedeutet Drittanbieter oder einfach nur Dritter.

First-Party Cookies

Wird eine Webseite besucht, werden logischerweise auch beim Besuch der Webseite und um die Webseite überhaupt anzeigen zu können, Dateien übertragen. Damit kann auch eine Webseite selbst Cookies erzeugen. Diese Art von Cookies werden als (technische) First-Party Cookies bezeichnet.

Derartige Cookies können von der gerade besuchten Webseite verwaltet werden. Verwalten bedeutet:

• Erzeugen
• Wert ändern
• Andere Eigenschaften ändern (Lebensdauer etc.)
• Löschen

Third-Party Cookies

Ruft eine Webseite eine Datei von einem Dritt-Server ab und wird dabei ein Cookie erzeugt, handelt es sich um ein Third-Party Cookie.

Ein (technisches) Third-Party Cookie kann nur vom Dritten, der das Cookie erzeugt hat, verwaltet werden. Die besuchte Webseite, die den Third-Party Dienst einbindet, hat vom Cookie, das von diesem Dienst erzeugt wird, keine Kenntnis und kann dieses Cookie somit auch nicht verwalten oder auslesen.

Umwandlung von First-Party zu Third-Party

Wenn Sie die Google Suchmaschine aufrufen, werden Google Cookies erzeugt. Hierbei handelt es sich offensichtlich um First-Party Cookies, weil die gerade besuchte Webseite die Cookies selbst erzeugt und verwaltet. Die Cookies existieren in diesem Beispiel also für die Domäne google.de oder google.com (je nach dem). Hier ein Beispiel, welche Google Cookies das sein können:

Besuchen Sie nun eine Webseite, die Google reCAPTCHA einbindet, passiert in etwa das Folgende:

1. Auf Ihrem Computer befindet sich aufgrund der Nutzung der Google Suchmaschine ein Cookie namens NID in der Domäne google.com
2. Sie besuchen nun eine Webseite X
3. Die besuchte Webseite X bindet Google reCAPTCHA ein
4. Dabei wird eine Datei von der Domäne google.com abgerufen, um Google reCAPTCHA bereitzustellen
5. Beim Abruf dieser Datei sendet Ihr Browser automatisch das auf Ihrem Endgerät schon vorhandene Cookie namens IDE an google.com

Offensichtlich ist das Cookie namens NID nun kein First-Party Cookie mehr, das es beim Besuch der Google Suchmaschine war. Vielmehr ist das ehemalige First-Party Cookie nun zum Third-Party Cookie geworden!

Definitionen aus technischer und datenschutzrechtlicher Sicht

Letztendlich ist für die Beantwortung von Datenschutzfragen eher die datenschutzrechtliche Sicht auf Cookies Ausschlag gebend und die technische Sicht ist untergeordnet zu sehen.

Technische Definition von First-Party und Third-Party Cookies

Ein Cookie heißt aus technischer Sicht First-Party, wenn es als Geltungsbereich eine Domäne besitzt, die der Domäne von der gerade besuchten Webseite entspricht. Beispiel:

• Gerade besuchte Webseite: dr-dsgvo.de
• Wenn in der gleichen Domäne, nämlich dr-dsgvo.de, ein Cookie vorhanden ist, ist es ein First-Party Cookie

Details wie Subdomänen lasse ich hier außen vor, weil sie für die Erklärung des Grundprinzips unerheblich sind.

Ein Cookie, welches kein First-Party Cookie ist, heißt Third-Party Cookie. Ein Third-Party Cookie hat also als Geltungsbereich eine Domäne, die ungleich der Domäne der gerade besuchten Webseite ist. Second Party Cookies werden nicht betrachtet, weil sie aus Datenschutzsicht nicht relevant sind. Dort gibt es nur den Ersten und den Dritten. Auftragsverarbeiter sind dem Ersten zuzurechnen.

So einfach ist es aus technischer Sicht.

Datenschutzrechtliche Definition von First-Party und Third-Party Cookies

Datenschutzrechtlich ist ein First-Party Cookie ein solches, welches nur vom Verantwortlichen selbst verarbeitet wird. Der Verantwortliche kann sich dabei Auftragsverarbeitern o.ä. bedienen.

Ein Third-Party Cookie liegt datenschutzrechtlich vor, wenn ein Cookie von einem Dritten verarbeitet wird. Was ein Dritter ist, erklärt Art. 4 Nr. 10 DSGVO:

Dritter ist eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, außer der betroffenen Person, dem Verantwortlichen, dem Auftragsverarbeiter und den Personen, die unter der unmittelbaren Verantwortung des Verantwortlichen oder des Auftragsverarbeiters befugt sind, die personenbezogenen Daten zu verarbeiten

Artikel 4 Nr. 10 DSGVO

Spezialfall für Cookie-Nutzung: Google Analytics

Als prominentes Beispiel für technische First-Party Cookies, die datenschutzrechtlich Third-Party Cookies sind, sei Google Analytics genannt. Besuchen Sie eine Webseite, die Google (Universal) Analytics (in Standardkonfiguration) nutzt, passiert folgendes:

1. Sie besuchen die Webseite X
2. Die Webseite bindet Google (Universal) Analytics ein, das ist die aktuell gängige Version dieses Tools
3. Dazu wird von der Webseite eine JavaScript-Datei von einem Google-Server geladen
4. Die JavaScript-Datei lebt nun auf der Webseite, so, als wäre der Google JavaScript Code direkt in die Webseite eingebettet
5. Der Google JavaScript Code erzeugt mehrere Google Analytics Cookies
6. Diese Cookies sind technische First-Party Cookies, weil sie in der Domäne gültig sind, die der der gerade besuchten Webseite entspricht
7. Der Google JavaScript Code liest weiterhin diese Cookies aus und sendet deren Werte an einen Google-Server. Damit handelt es sich ab jetzt aus Datenschutzsicht um Third-Party Cookies.

Warum sind Cookies wichtig?

Funktionelle Notwendigkeit

Funktionell sind Cookies wichtig, um Einstellungen von Benutzern auf Webseiten zu speichern, beispielsweise, dass ein Nutzer angemeldet ist. Weiterhin werden Cookies genutzt, um einen Besucher widerzuerkennen, der eine Webseite einige Tage oder Wochen später erneut besucht.

Findet diese Wiedererkennung von Besuchern alleinig durch den Betreiber der Webseite, ohne Hinzuziehen von Dritten statt, kann von Reichweitenmessung gesprochen werden.

Bedient sich der Verantwortliche für die besuchte Webseite eines Dritten, um Besucher nachzuverfolgen, wird von Tracking oder Web Tracking gesprochen. Ein Tracking kann allerdings auch vorliegen, wenn ein Webseitenbetreiber selbst das Verhalten seiner Nutzer tiefer gehend analysiert, als dies über ein berechtigtes Interesse begründbar wäre.

Rechtliche Relevanz

Die ePrivacy Richtlinie fordert in Art. 5 Abs. 3, dass eine Einwilligung einzuholen ist, bevor auf Informationen zugegriffen wird, die im Endgerät des Nutzers gespeichert sind und dieser Vorgang technisch nicht notwendig ist. Aktuell gibt es meiner Untersuchung nach nur Cookies, die beim Besuch von Webseiten (zumindest über einen PC) in diese Kategorie fallen.

Im §15 Abs. 3 TMG ist allerdings etwas anderes geregelt, weil der Gesetzgeber seiner Verpflichtung nicht nachgekommen ist, die ePrivacy Richtlinie in deutsches Recht umzusetzen. Das TMG fordert nämlich für die Datenerhebung von Marketing-Zwecke und für die Bildung von Nutzerprofilen eine Abwahlmöglichkeit (sog. Opt-Out).

Der BGH hat am 28.05.2020 – I ZR 7/16 entschieden, dass das TMG im Sinne der e.g. ePrivacy Richtlinie auszulegen ist. Somit sind auch in Deutschland technisch nicht notwendige Cookies einwilligungspflichtig.

Was ist das Problem mit Cookie Bannern?

Sogenannten Consent Tools oder Cookie Popups oder Cookie Tools, oder wie immer man sie bezeichnen möchte, können in der Praxis nicht zuverlässig funktionieren und tun es auch nicht. Ich habe dies umfangreich untersucht. Nur soviel in Kürze an dieser Stelle:

• Das TMG schreibt auch für andere Vorgänge als Cookies eine Abwahlmöglichkeit vor. Beispiel: Eingebundenes YouTube Video ohne Cookies, das auch DoubleClick nachlädt.
• Beim Datentransfer in unsichere Drittländer wie die USA muss gemäß Art. 44 DSGVO eine Einwilligung nachgewiesen werden. Beispiele: Vimeo Videos, SoundCloud Audio Player sowie wahrscheinlich sämtliche Google Tools.
• Für vermeidbare Datentransfers muss gemäß Art. 5 Abs. 1 c DSGVO eine Einwilligung eingeholt werden. Beispiel: Externe Google Fonts.
• Für viele Tools liegen mehrere dieser Bedingungen für eine Einwilligung gleichzeitig vor.
• Die Zwecke von Cookies kennt zunächst nur der Herausgeber von Diensten, die Cookies erzeugen und nutzen. Verrät der Herausgeber keine Details zu den Zwecken der genutzten Cookies, ist der Zweck Dritten nicht bekannt und somit nicht rechtskonform erklärbar. Beispiel für Intransparenz: Google-Tools wie Google reCAPTCHA.
• Cookie Scanner können unmöglich alle Cookies erkennen, die auf einer Webseite ins Spiel kommen. Cookies werden nämlich im Endgerät des Nutzers gespeichert. Pro Nutzer liegen unterschiedliche Cookies vor, je nach dem, welche anderen Webseiten der Nutzer vor dem Besuch der aktuellen Webseite besucht hat. Besonders anschaulich wird das Problem hieran: Sie selbst können sich mit frei verfügbaren Mitteln Cookies auf Ihrem Computer erzeugen, die dann beim Abruf einer Webseite gezogen werden. Offensichtlich kann niemand außer Ihnen wissen, dass es diese Cookies gibt. Dieses Beispiel ist rein theoretisch und soll nur die Grundproblematik zeigen.
• Die Texte und Erklärungen, die mit Cookie Tools ausgeliefert werden, sind nach meiner Erfahrung und Einschätzung in Gänze als großer Haufen Bullshit zu bezeichnen. Leider scheint das Millionen von Webseitenbetreibern nicht zu stören, denn sie binden unreflektiert diesen Berg an Bullshit, für den sie verantwortlich sind, auf deren Webseiten ein.
• Das Blockieren von ansonsten stattfindenden Datentransfers durch ein sogenanntes Consent Script funktioniert nicht zuverlässig. Wer das versucht, hat den Bullshit Preis des Jahres verdient.
• Anbieter von Cookie Tools verschweigen gerne die Probleme mit deren sogenannten Lösungen.

Weiterführende Informationen zu Consent Tools

• Großer Praxistest von Consent Tools
• Fünf Gründe, warum Cookie Popups nicht funktionieren können
• Checkliste für Einwilligungsabfragen
• Ausflug: Der Google Tag Manager ist keine cookielose Domäne

Was ist die Lösung?

Verwenden Sie keine Cookie Tools von populären Anbietern. Diese sind anscheinend ungeeignet, um rechtssichere Webseiten zu erhalten (siehe meine o.g. Untersuchungen und den Praxistest). Ich halte alle bekannteren Cookie Tools für Versager und kann das auch an konkreten Fällen belegen.

Entfernen Sie alle Dienste, die Sie nicht mehr benötigen und die nur da sind, weil jemand anders Ihnen eingeredet hat, Sie bräuchten diese Dienste. Beispiele: Google Maps, Google Analytics.

Ersetzen Sie datenschutzfeindliche Dienste durch datenschutzfreundliche Versionen. Beispiele: Matomo statt Google Analytics, meine interaktive Karte statt Google Maps.

Nutzen Sie ein eigenes Consent Tool oder die Open Source Variante von Klaro! Nutzen Sie eine Checkliste, um die Anforderungen an eine Einwilligungsabfrage bestmöglich zu gestalten.

Machen Sie einen Schnelltest Ihrer Webseite, um eine erste Idee zu erhalten, wie es um den Datenschutz steht.

Meine Annahme: 90% aller deutschen Webseiten benötigen kein nervices Cookie Popup, weil einwilligungspflichtige Datenverarbeitungen gänzlich vermieden werden können.

Updates

Empfehlungen bei erhaltenen Abmahnungen:

• Erste Schritte ohne Anwalt
• Gefordertes Geld nicht bezahlen

Das wichtigste: Zuallererst alle Google Fonts Einbindungen entfernen. Auch Google Maps und Google reCAPTCHA binden Google Fonts ein. Am besten alle Google Tools entfernen, zumindest kurzfristig. Statt Google Maps mein Karten-Plugin verwenden. Statt Google reCAPTCHA tut es oft eine textuelle Rechenaufgabe mit Eingabefeld („Wie viel sind 17 weniger drei? Bitte als Wort schreiben.“).

Das folgend genannte Urteil des LG München schwappte mittlerweile nach Österreich. Es führte zu so großen Verwerfungen, dass sogar die Datenschutzbehörde der Repubik Österreich ein amtswegiges Prüfverfahren gegen Google wegen Google Fonts eingeleitet hat (laut Bekanntmachung vom 23.08.2022).

Mittlerweile gibt es ein Urteil des LG München, wonach das Einbetten von Google Fonts als rechtswidrig eingestuft wurde. Ich hatte es schon immer so gesehen, wie mein folgender Beitrag zeigt. Dadurch kamn eine Abmahnwelle in Deutschland ins Rollen.

Einleitung

Im Gegensatz zu einigen meiner vorigen Beiträge, u.a. zu Cookies, zur ePrivacy Richtlinie oder zu Consent Tools, sind die folgenden Informationen nicht weltbewegend. Die Kombination aus technischer und rechtlicher Betrachtung sowie die technische Lösungsmöglichkeit sind hoffentlich halbwegs neuartig. Allerdings musste ich bereits feststellen, dass selbst eine selbst ernannte Datenschützerin absichtlich weiter externe Google Schriften nutzt. Ich vermute, sie macht das entweder, weil sie sich (durch die rechtswidrige Einbindung) SEO-Effekte erhofft oder weil sie die weiter unten genannte Lösung nicht kennt.

Andere Schriften als die von Google sind übrigens teilweise noch eindeutiger einwilligungspflichtig. Beispielsweise Fast Fonts (fonts.com), weil diese einen Zählpixel zu Abrechnungszwecken einsetzen.

Google Schriften werden auch als Google Fonts bezeichnet. Sie zeichnen sich dadurch aus, dass nahezu jede Schriftart unterstützt wird und vermeintlich einfach und ohne finanzielle Kosten in Webseiten eingebunden werden kann. Bindet man Google Fonts so ein, wie es Google vorschlägt, werden Verbindungen zu Google Servern aufgebaut.

Hier ein reales Beispiel eines solchen Datentransfers, der durch eingebundene Google Schriftarten verursacht wird:

Wie im Netzwerk-Protokoll zu sehen ist, werden gleich zwei verschiedene Domäne angerufen, nämlich googleapis.com und gstatic.com bzw. die dazu gehörigen Subdomänen.

Diese Art der Einbindung nenne ich externe Google Schriften, weil sie von Google Servern geladen werden. Anders sieht es aus, wenn die Schriften von einem eigenen Server oder einem Server eines Anbieters geladen werden, mit dem vetragliche Garantien abgeschlossen wurden.

Ich habe mich entschieden, diesen Beitrag auch in die Kategorie Bullshit Basics zu packen, weil viele immer noch versuchen, alle möglichen Argumente zu suchen, warum externe Google Schriften auf einmal doch erlaubt sein sollen.

Wie sieht es mit dem Datenschutz aus?

Das Einbinden von externen Google Schriften verstößt gegen Art. 5 Abs. 1 DSGVO. Dort ist das Prinzip der Datenminimierung genannt. Dem entgegen steht ein etwaiges berechtigtes Interesse, welches bestimmte Datenverarbeitungen erlaubt. Das berechtigte Interesse ist in Art. 6 DSGVO definiert. Wer Daten erhebt, muss nach Art. 5 Abs. 2 DSGVO nachweisen, dass er die Grundsätze des Art. 5 Abs. 1 DSGVO (Datenminimierung etc.) einhält.

Der Verstoß liegt vor, weil es ohne Weiteres möglich ist, Google Schriften lokal einzubinden. Dabei werden einfach alle benötigten Schriftendateien heruntergeladen, entsprechend angepasst und dann auf dem eigenen Web Server abgelegt. Nun können lokale Dateien auf der eigenen Webseite eingesetzt werden. Ein Datentransfer zu Google oder anderen Dritten findet damit nicht mehr statt.

Der Art. 25 DSGVO bedingt eine datenschutzfreundlichen Technikgestaltung.

Somit ist gezeigt, dass das berechtigte Interesse eindeutig ausscheidet. Niemand wird vor Gericht damit durchkommen. Sollte jemand etwas anders behaupten, hat er entweder keine Ahnung oder nimmt die falschen Tabletten und leidet an maßloser Selbstüberschätzung.

Was ist mit Cookies?

Für gewöhnlich werden beim Abruf von Google Schriften keine Cookies verarbeitet. Ich gebe allerdings zu bedenken, dass dies auch anders sein kann. Es reicht auch, wenn es weltweit eine einzige öffentlich erreichbare Webseite gibt, die in der Domäne der Google Fonts liegt.

Diese Art von Webseiten gibt es zuhauf, wie eine Suche nach Webseiten mit der Hauptdomäne googleapis.com beweist:

Von diesen zahlreichen vorhandenen Webseiten setzen einige Cookies auf einer Domäne, die Google Fonts betrifft. Ruft nun eine Person eine dieser Webseite auf und danach eine deutsche Webseite, die externe Google Schriften lädt, verstößt diese deutsche Webseite dadurch gegen die ePrivacy Richtlinie. Zumindest müsste der Betreiber der Webseite erst einmal beweisen, dass das Gegenteil der Fall ist. Ich hoffe für ihn, dass er dann die Telefonnnummer eines sehr guten Kontakts bei Google zur Hand hat.

Mir selbst sind solche Webseiten bekannt, die Cookies erzeugen, welche dann für Google Schriften relevant werden. Demnach bedürfen Google Schriften auch einer Einwilligung aufgrund des Art. 5 Abs. 3 der ePrivacy Richtlinie in Verbindung mit dem BGH-Urteil vom 28.05.2020 – I ZR 7/16. Im Zweifel muss der Betreiber der Webseite beweisen, dass Google diese Cookies nicht nutzt, was ziemlich schwierig und unglaubhaft sein dürfte. Schließlich handelt es sich um sogenannte Third-Party Cookies.

Google Fonts sind nur ein Beispiel für Dienste, die auch ohne Cookie eine Einwilligung erfordern. Weitere nennt der Überblick zu Cookies und Einwilligung.

Was ist mit Google?

Meiner Meinung nach sind zahlreiche Google Tools, ohne jegliche Ausnahme, nicht datenschutzkonform nutzbar. Ob Google Tools mit oder ohne Einwilligung geladen werden, ist eine andere Frage. Hier geht es um die transparente, konkrete Benennung der Pflichtangaben gemäß Art. 13 DSGVO.

Außerdem gibt Google selbst zu, Daten aus Ihrem Google Konto, wenn Sie dort angemeldet sind, mit erhobenen Daten beim Abruf von Google Fonts abzumischen. In der Datenschutzerklärung, die für Google Fonts gilt, steht:

Demgemäß müssen u.a. folgende Informationen zu genutzten Google Tools angegeben werden:

• Zwecke der Datenverarbeitung beim Dienstanbieter
• Datenempfänger
• Risiken, etwa Transfers ins bestimmte Drittländer oder bestimmte Arten von Empfängern, wie etwa Behörden oder Geheimdienste
• Zwecke von Cookies (diese sind allgemein nur dem Dienstanbieter bekannt, der im Falle von Google die Zwecke meist nicht ausreichend verrät

Wie man leicht feststellen kann, können diese Angaben für Google Tools nicht konkret, transparent und korrekt gemacht werden.

Zusätzlich kann man für den Google Konzern immer den Art. 44 DSGVO anführen, den Datentransfer in unsichere Drittländer. Ich habe mir allerdings angewöhnt, dieses Problem nur untergeordnet zu nennen, weil die o.g. Datenschutzbetrachtungen bereits als Begründung gegen externe Google Schriften ausreichen.

Wer alle genannten Argumente für lokale und gegen externe Google Schriften als hinfällig ansieht , der kann sicher einen Vertrag vorlegen, den er mit Google geschlossen hat, um geeignete Garantien von Google für eine DSGVO-konforme Datenverarbeitung zu erhalten. Am besten sollte dann auch noch eine Abwahlmöglichkeit (Opt-Out) für erhobene Daten angeboten werden. Viel Vergnügen!

Auf der Webseite eines Anbieters eines Consent Tools wird letzteres übrigens mitgeteilt sowie ebenso die Problematik des Einsatzes von externen Google Schriften. Dass die genannte Webseite dann selbst externe Google Schriften verwendet, verwundert umso mehr. Da die Schriften nicht auf jeder Untrseite, und auch nicht auf der Seite mit dem Artikel zu Google Fonts zu finden sind, zeigt, dass der Anbieter des Consent Tools dies womöglich nicht absichtlich gemacht hat und mit der Einhaltung von Datenschutzvorgaben überfordert ist.

Was ist mit Content Delivery Networks?

Sogenannte CDNs bieten einen schnellen, hoffentlich jederzeit verfügbaren Speicher. Die Begründung für den Einsatz solcher Systeme ist oft eine vermeintlich schnellere Ladezeit der Webseite. Bisher konnte mir das allerdings niemand wirklich belegen (ich will nicht ausschließen, dass dies so ist, möchte aber einen Beweis zumindest für den ersten Ladevorgang haben!). Wie ein Kommentarschreiber zu diesem Beitrag erwähnt, sind Folgeaufrufe derselben Ressource, die von verschiedenen Webseiten gleichzeitig verwendet wird, optimiert. Folgeaufrufe innerhalb einer Webseite selbst sind allerdings durch den lokalen Cache des Nutzers sowieso schon schneller. Es geht hier also nur um einen Erstaufruf einer Webseite, die selbe Ressourcen genauso rechtswidrig einsetzt wie andere Webseiten einsetzt. Wenn ein lokaler Cache beim Nutzer langlebig ist, agiert er besser als jedes CDN. Da Google Fonts weiter verbreitet sind, ist die Chance, einen lokalen Cache-Treffer zu haben, groß. Wer seine Browser Caches aus Datenschutzgründen regelmäßig leert, möchte im Gegenzug wohl nicht von einem datenschutzfeindlichen CDN getrackt werden. Aus Sicherheits- und Datenschutzgründen nutzen moderne Browser mitunter ein Cache Partitioning. Dadurch existiert pro Webseite jeweils ein eigenständiger Cache. Somit ist das Argument des globalen Cache beim Nutzer, der sich über mehrere Webseiten hinweg aufbauen könnte, quasi hinfällig.

Es ist fraglich, ob das Laden einer kleinen, statischen Datei von einem CDN schneller vonstatten geht als von einem lokalen Speicher. Browser puffern Anfragen dieser Art, so dass bei Folgeaufrufen durch den gleichen Nutzer oft die lokale Kopie gezogen wird, was am allerschnellsten ist.

Lädt man Ressourcen von CDNs, kann der Browser Ladevorgänge möglicherweise parallelisieren, indem die Ladevorgänge von mehreren verschiedenenen Servern nahezu gleichzeitig angestoßen werden. Damit können Dateien vom lokalen Server nahezu gleichzeitig geladen werden wie Dateien von anderen Servern.

Wer meint, Google Fonts müssen von einem CDN geladen werden, damit der Erstaufruf der Webseite schneller ist, sollte erst einmal prüfen, ob nicht alle anderen Geschwindigkeitsoptimierungen auf der Webseite ausgeschöpft wurden. Wer unnötige, weil nicht verwendete Schriftarten lädt, braucht nicht mit dem Argument der schnelleren CDN-Ladezeit beim Erstaufruf zu kommen.

Wer unbedingt ein CDN einsetzen möchte, kann dies tun. Es muss aber sichergestellt sein, dass der Betreiber des CDN an die DSGVO gebunden ist und sich selbstverständlich auch daran hält. Amerikanische Unternehmen scheiden demnach als Anbieter von CDN aus, außer, man möchte mit Einwilligungen arbeiten und eine gewisse rechtliche Unsicherheit in Kauf nehmen.

Übrigens kann man auch selber ein CDN aufsetzen. Anscheinend ist der Betreiber der Webseite derart wichtig, dass er ein CDN benötigt. Dann sollte es möglich sein, dies zu tun. Es handelt sich schließlich nur um einen Datei-Server mit schneller Internet-Anbindung. Solche Server gibt es überall in Deutschland zu mieten. Gerne kann ein deutsches Unternehmen ein datenschutzkonformes CDN auf breiter Basis anbieten. Ich denke, hierfür gibt es einen Markt.

Auf keinen Fall sollte man meiner Meinung nach auf Cloudflare zurückgreifen, da dieser Anbieter nach meiner Recherche keinen guten Datenschutz bieten kann. Akamai kann ebenso nicht als datenschutzfreundlich angesehen werden.

Was ist die Lösung?

Google Fonts können lokal eingebunden werden. Dies kann man manuell bewerkstelligen oder mit Hilfe eines Hilfsprogramms. Das Hilfsprogramm lautet Google Webfonts Helper. Nach Aufruf der Webseite des Tools können Sie im linken Bereich (zumindest bei Desktok PC-Darstellung) eine Schriftart auswählen. Im Hauptbereich können dann die fertigen Dateien für eine lokale Einbindung der Schriften heruntergeladen werden.

Den manuellen Weg möchte ich hier zusätzlich beschreiben, auch um das Grundprinzip zu verdeutlichen.

Für den manuellen Weg lädt man sich die Schriftdateien herunter. Das geschieht wie folgt:

Externe Schriften werden über eine Datei wie die folgende geladen: https://fonts.googleapis.com/css?family=Roboto. Dies kann man im Quellcode der Webseite sehen. Eine andere Möglichkeit ist die Entwicklerkonsole von Firefox und anderen Browsern, die man mit der Taste F12 öffnen kann. Nachdem die Konsole geöffnet ist, die Webseite aufrufen. Der Karteireiter Netzwerkanalyse zeigt die Datentransfers. Dort findet man dann Ladevorgänge von der Domäne fonts.googleapis.com und weitere.

Öffnen Sie die Schriftdatei im Browser und kopieren Sie den Inhalt in eine Datei namens roboto.css (Name für andere Schrifttypen sinnvollerweise anders wählen).

Sie sehen Zeilen, in denen auf externe Dateien verwiesen wird. Diese sehen beispielsweise so aus:

src: url(https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu72xKOzY.woff2) format('woff2');

Normalerweise sind nur die Abschnitte relevant, die mit dem Kommentar /* latin */ versehen sind, ggfs. auch die mit erweitertem lateinischem Zeichensatz /* latin-ext */.

Laden Sie alle Dateien dieser Art herunter. Ändern Sie in roboto.css die Angabe so, dass sie auf ihre lokale Datei zeigt. In den Nutzungsbedingungen von Google sehe ich keinen Hinweis, warum dies nicht erlaubt sein soll.

Ab sofort können Sie sich potentiell falsche Datenschutztexte zu Google Fonts sparen. Niemand kann Ihnen ab jetzt vorwerfen, Sie hätten den Datenschutztext vergessen oder würden mit externen Google Schriften gegen Datenschutzregeln verstoßen.

Wie man sieht, ist die Lösung relativ einfach und keine Raketenwissenschaft. Es spielt für den Datenschutz hier keine Rolle, dass diese Vorgehensweise am besten von einer technikaffinen Person erledigt wird. Fragen Sie bei Bedarf jemanden, der sich damit auskennt. Wenn er gut ist, wird er es in sehr kurzer Zeit hinbekommen.

Für WordPress-Webseiten empfehle ich den Einsatz von Design Themes, die entweder Google Schriften lokal einbinden oder eine Option dafür bereitstellen.

Mit meinem online Webseiten-Check kann schnell geprüft werden, ob eine Webseite Google Fonts einsetzt. Der Check prüft nur die ersten paar Unterseiten. Das reicht meist für eine gute Einschätzung aus.

Mögliche Gegenargumente und Entgegnungen

Das Gegenargument der angeblich längeren Ladezeiten kann bei kleinen Schriftartdateien, auch aufgrund meiner eigenen jahrelangen Erfahrung mit lokalen Schriften, ausgeräumt werden. Wer möchte, kann ja ein datenschutzkonformes CDN verwenden, aber nicht das von Google! Auch der Aufbau eines eigenen CDN ist möglich und lohnt sicher für Webseiten, die auf eine Ladezeit angewiesen ist, die fünf Millisekunden kürzer ist als das lokale Einbinden.

Weiter unten habe ich einen Geschwindigkeitstest beschrieben, der beweist, dass externe Google Schriften keine höhere Geschwindigkeit bringen.

Das Argument, dass die Schriften dann nicht mehr automatisch (von Google) gewartet werden, ist keines. Schließlich sollten Schriften dauerhaft genau so aussehen, wie sie installiert wurden. Dass Browser sich einmal erheblich ändern und ein Font Update erfordern würden, kommt sehr selten vor. Bei neu ausgelieferten Schriften wird es selten vorkommen, dass beim Design der Schrift der Punkt auf dem i vergessen wurde. Bei schon länger vorhandenen Schriften stellt sich die Frage, was sich noch ändern soll. Es geht um eine Schriftart und nicht um einen Atomreaktor.

Aus eigener Erfahrung weiß ich, dass es kein Wartungsproblem gibt. Zudem gibt es in anderen Fällen Urteile, wonach ein Unternehmer mit einem online Angebot verpflichtet ist, sich regelmäßig sein Angebot anzusehen und neu zu bewerten. Der Unternehmer gerät sogar dann in Haftung, wenn eine Plattform, auf der er seine Produkte anpreist, eigenständig und vollautomatisiert das Angebot des Unternehmers rechtswidrig werden lässt. Genau gleiches Engagement kann zu Schriften erwartet werden (vgl. etwa OLG Frankfurt, Beschluss vom 18.03.2021, Az. 6 W 8/18).

Lizenzrechtlich konnte mir bisher niemand zeigen, wo steht, dass die lokale Einbindung, wie ich sie oben beschreibe, unerlaubt sei. Im Gegenteil, die Schriften laufen unter der SIL Open Font License. Google kennzeichnet alle Schriften auf Google Fonts als Open Source und frei:

Dies wird von Google an anderer Stelle bestätigt: "All fonts are released under open source licenses. You can use them in any non-commercial or commercial project."

Manche meinen, durch Einbinden von Google Tools wird deren Webseite höher gewichtet und erscheint dann prominenter in Suchergebnissen der Google Suchmaschine. Alleine schon, weil viele Webseiten Google Tools einbinden, verfängt dieses Argument nicht. Zusätzlich kann ich aus Erfahrung behaupten, dass höherwertige Onpage SEO-Maßnahmen wesentlich weniger Effekt bringen als eine gute Content-Strategie. Zu dieser gehört auch das Verbreiten von Inhalten in geeigneten Medien. Hierzu bedarf es Google in keinster Weise (außer, man möchte auf YouTube ein Video veröffentlichen, aber auch hierzu gibt es bessere Alternativen, weil YouTube als überlaufen bezeichnet werden darf).

Übersicht der Entgegnungen

Manche sind recht kreativ, wenn es darum geht, den rechtswidrigen Einsatz von externen Google Schriften doch irgendwie zu rechtfertigen. Die folgende Tabelle zeigt eine kurze Darstellung der angeblichen Argumente und ihre Entgegnung.

Wenn Sie ruhig schlafen möchten oder etwas für den Datenschutz tun wollen oder einfach nur Gesetze einhalten möchten, dann binden Sie Google Schriften lokal ein.

Die Haltung von Aufsichtsbehörden

In Deutschland gibt es pro Bundesland eine Datenschutzaufsichtsbehörde und zusätzlich den Bundesdatenschutzbeauftragten, der etwa für öffentliche Stellen zuständig ist.

Die Äußerungen von Aufsichtsbehörden sind Meinungen, nämlich Behördenmeinungen. Sie können herangezogen werden, um eine Risikoabwägung vorzunehmen. Damit kann abgeschätzt werden, wie wahrscheinlich ein Bußgeld durch eine Aufsichtsbehörde ist. Die juristische Frage lässt sich so nicht klären. Gerichte können Behördenmeinungen als Anhaltspunkt ansehen, sind aber daran in keinster Weise gebunden. Datenschutzbehörden sind grundsätzlich kulanter als Gerichte, so ist meine Erfahrung. Das hilft wenig, wenn eine Abmahnung durch eine Privatperson oder einen Wettbewerber ansteht.

Jeder Landes-Datenschutzbeauftragte hat möglicherweise eine andere Meinung und Empfehlung. Hier zwei Beispiele:

• Bayern: Nach dem Urteil des LG München vom 20.01.2022 hat der BayLDA den Einsatz von Google Fonts für öffentliche Stellen quasi untersagt. Erlaubte zuvor externe Google Fonts. Warum, ist mir nicht klar (eine Begründung fehlt in den FAQ). Dankenswerterweise hat die bayerische Behörde mir geantwortet, und zwar sehr schnell und umfassend. Die Antwort macht.e deutlich, dass ein Datentransfer in unsichere Drittländer als kritisch angesehen wird und externe Schriften an sich, aber nicht in jedem Fall erlaubt sind. Bayern weist darauf hin, dass der Datentransfer in die USA ohne Einwilligung nur unter der strengen Vorgabe des Schrems-II-Urteils möglich ist.
• Baden-Württemberg: Keine explizite Position, sondern ein Hinweis auf Datenschutzprobleme und die Empfehlung, Schriften lokal einzubinden.

Geschwindigkeitstest: lokale versus externe Google Schriften

Für den Vergleich wurde die ansonsten gleiche HTML Seite einmal mit externen Google Schriften und einmal mit lokalen Google Schriften getestet. Die externen Google Fonts wurden, wie von Google empfohlen, mit preconnect eingebunden, so dass eine schnellere Ladezeit möglich ist.

Zum Test wurde der online Webpagetest verwendet. Der Test wurde von einem Server in Frankfurt mit dem Chrome Browser durchgeführt.

Testlauf mit externen Google Schriften

Das Ergebnis zeigt in einer Übersicht den Anteil der externen Schriften an der Gesamtladezeit und den Datentransfer:

Wie man sehen kann, haben die externen Google Schriften einen Anteil von 15% an der Gesamtzeit aller Anfragen, die zum Abruf der Webseite erforderlich sind. Der Anteil der übertragenen Daten beträgt 20,1% vom Gesamtumfang.

In einer Wasserfall-Diagramm Darstellung stellt sich die Ladezeit für externe Google Schriften wie folgt dar:

Die relevante Ladezeit ist aber die blockierende Zeit, also die Zeit, die der Abruf mit externen Google Schriften länger dauert als es ohne diese Schriften der Fall wäre:

Hier sind die relevanten Ladezeiten genauer zu sehen:

Die erste Anfrage startete bei Zeitpunkt 0,696 Sekunden. Die letzte Anfrage endete bei Zeitpunkt 0,699 Sekunden + 88 Millisekunden (Time to first byte) +26 Millisekunden (Content Download) = 0,813 Sekunden.

Die relevante Gesamtladezeit für den Erstabruf betrug bei externen Google Schriftarten also insgesamt 0,813 – 0,699 Sekunden = 114 Millisekunden.

Analog wurde der Folgeabruf ausgewertet. Er betrug 91 Millisekunden.

Testlauf mit lokalen Google Schriften

Das Ergebnis zeigt in einer Übersicht den Anteil der lokalen Schriften an der Gesamtladezeit und den Datentransfer:

Der Anteil an der Ladezeit bezüglich aller Requests ist bei lokalen Google Schriften so gering, dass ich mit dem Cursor über das rote Kuchenstück fahren musste. Er beträgt 12,8 %. Der Anteil der übertragenen Daten beträgt 18,3 % vom Gesamtumfang. Allerdings ist hier anscheinend die Verbindungszeit nicht mit eingerechnet.

Beim Erstabruf erzeugen lokale Google Schriften folgende Ladezeiten:

Die relevante Ladezeit ist aber die blockierende Zeit, also die Zeit, die der Abruf mit lokalen Google Schriften länger dauert, als es ohne diese Schriften der Fall wäre. Ein Diagramm nach Servern wie bei externen Google Schriften bringt hier nicht weiter, weil auch andere Dateien als Schriften vom Server der Webseite geladen werden.

Hier sind die relevanten Ladezeiten genauer zu sehen:

Die erste Anfrage startete bei Zeitpunkt 0,772 Sekunden. Die letzte Anfrage endete bei Zeitpunkt 0,775 Sekunden + 270 Millisekunden (Time to first byte) +1 Millisekunden (Content Download) = 1,046 Sekunden.

Die relevante Gesamtladezeit für den Erstabruf betrug bei lokale Google Schriftarten also insgesamt 1,046 – 0,772 Sekunden = 274 Millisekunden.

Analog wurde der Folgeabruf ausgewertet. Er war ungefähr gleich schnell wie der Erstabruf.

Ergebnis des Geschwindigkeitstests

Am besten sieht man das Ergebnis bei einer Gegenüberstellung.

Externe Google Schriften sind etwas schneller als die lokale Einbindung. Betrachtet man die gesamte Ladezeit der Webseite, dann entsteht folgende Statistik (die Gesamtladezeiten sind als Nenner der Brüche angegeben, alle Angaben in Millisekunden):

Die Gesamtladezeit war mit externe Google Schriften gegenüber lokal eingebundenen Schriften beim Erstabruf der Webseite um 3,8 % schneller und beim Folgeabruf um 5,2 %.

Die Optimierungsmaßnahmen für meine Webseite haben gezeigt, dass eine Verbesserung der Ladezeit durch ganz andere Maßnahmen wesentlich effektiver stattfinden kann. Beispiele: Caching auf Ebene der Datei htaccess aktivieren, Bilder weiter komprimieren, unnötige Plugins deaktivieren.

Der Test fand übrigens mit dieser Webseite statt. Sicher ist er nicht akademisch verwertbar, weil die Anzahl der Tests zu gering ist und die Schwankung der Ladezeiten bei mehreren Tests einige Prozent beträgt. Anhand der Ergebnisse und der genannten Argumente und Fakten kann sich jeder sein eigenes Bild machen.

Wer sich immer noch auf das Geschwindigkeitsargument für externe Google Schriften beruft, der muss nachweisen, dass

1. wenige Millisekunden beim Erstaufruf der Webseite geschäftskritisch sind,
2. kein DSGVO-konformes CDN bereitsteht (das ist allerdings immer noch kein Argument),
3. ein eigenes CDN, im einfachsten Fall auch File Server genannt, nicht möglich ist (das wird schwierig zu zeigen),
4. wirklich alle anderen Maßnahmen bereits voll ausgeschöpft sind (viel Erfolg!)
5. beim Abruf externer Schriften kein Datentransfer in unsichere Drittländer stattfindet
6. Google die erhaltenen Verkehrsdaten nicht für eigene Zwecke nutzt und nicht an Dritte weitergibt (Dritte sind alle, die ungleich Google Ireland Ltd. sind).

Lokale Schriften schneller laden

Wer mehr als eine Schriftartdatei einbindet (typische Dateiendung: woff oder woff2), der sollte jede Schriftdatei separat einbinden und ein nichtblockierendes Laden verwenden. Letzteres lässt sich wie folgt erreichen:

<link rel="stylesheet" href="font1.css" type='text/css' media="none" onload="if(media!='all')media='all'"><link rel="stylesheet" href="font1.css">

Diese Zeile Code lädt eine Schriftdatei in asynchroner Weise. Dafür sorgt die Kennzeichnung media="none". Nachdem die Schriftdatei geladen wurde, wird der Mediendatei über die JavaScript-Anweisung im onload-Ereignis auf media="all" gesetzt, so dass die Schrift für die aktuelle Darstellung angewandt wird.

Die noscript-Anweisung sorgt dafür, dass die Schriftart auch für Browser, in denen JavaScript deaktiviert wurde, korrekt geladen wird.

Eigenen schnellen File Server aufsetzen

Für die eigenen Webseiten benötigt man kein Content Delivery Network (CDN). Ein CDN ist in erster Linie notwendig, weil ganz viele Webseiten daran angebunden sind.

Ein eigenes CDN, welches für nur wenige eigene Webseiten verwendet wird, kann man auch als schnellen File Server bezeichnen. Wer mehr möchte, baut sich eine Server-Infrastruktur mit Lastverteilung. Beim Abruf mehrerer Schriftartdateien werden mehrere CDN-Server eingeschaltet.

Ein solcher File Server ist ein Server mit schneller Internetanbindung und möglichst ohne Restriktionen bezüglich des Datentransfervolumens. Hierfür gibt es einige Angebote deutscher Anbieter, die sehr günstig sind. Auch CDNs mit Lastverteilung gibt es von rein europäischen Anbietern. Wer eine superschnelle Webseite braucht (und sich auch darauf beruft), dem wird es zuzumuten sein, wenige Euro pro Monat für ein Web Hosting Angebot auszugeben, um die heiß geliebten Google Schriften schneller laden zu können.