Update: Die Anmeldung ist geschlossen. Bei Interesse an Seminaren und Webinaren mit mir als Referent empfehle ich meinen Newsletter. Sie erhalten dann Informationen über zukünftige Veranstaltungen. Schreiben Sie mir gerne, wenn Sie Wünsche zum Inhalt haben.

Für den BvD halte ich am 20.09. ein Webinar. Aktuelle Themen, wie die Einwilligungsverwaltung-Verordnung (PIMS, § 26 TTDSG/TDDDG) werden ebenfalls aufgegriffen. Darüber hatte ich zuletzt vorigen Freitag auf der Herbstakademie der DSRI (Deutsche Gesellschaft für Recht und Informatik) in Hannover vorgetragen.

Die weiteren Themen beinhalten:

• Rechtliche Aspekte
• Technische Aspekte
• Welche Vorgänge sind einwilligungspflichtig und einwilligungsfrei?
• Datenschutzfreundliche Alternativen
• Web Tracking
• Online Marketing
• Conversion Tracking
• Cookies, Cookie Tools
• Zentrale Einwilligungsverwaltung (PIMS)
• Beste Praktiken und Empfehlungen
  
  Die Möglichkeit zur Diskussion ist gegeben. Auch werden Ihre Fragen spezifisch beantwortet (und falls nicht zeitlich möglich, dann im Nachgang per Mail).
  Eine Anmeldung ist noch bis Dienstag, 20.09., 9:00 Uhr beim BvD möglich.
  
  Über Ihre Teilnahme freuen sich der BvD als Veranstalter und ich als Referent. Die Kosten betragen 495 Euro für Nichtmitglieder des BvD und 295 Euro für Mitglieder.
  
  Anmeldung über den BvD:

Einleitung

Google Fonts sind Schriftarten, die Google auf eigenen Servern bereitstellt. Die Fonts können von Webseiten derart integriert werden, dass sie die Schriftartdateien von einer Google-Adresse abrufen. Dies hält das LG München im Urteil vom 20.01.2022 – 3 O 17493/20 für rechtswidrig und sprach dem Kläger, eine Privatperson, zusätzlich zum Unterlassungsanspruch auch noch 100 Euro Schadenersatz aus Art. 82 Abs. 1 DSGVO zu. Der vom Kläger geforderte Schadenersatz wurde vom Gericht vollumfänglich anerkannt. Für Schriften eine Einwilligung abzufragen, ist zwar an sich möglich, erscheint aber praxisfern. Google betreibt übrigens weltweit Server, natürlich auch und vor allem in den USA. Ein Abruf aus den USA kann also nicht ausgeschlossen werden und ist sogar wahrscheinlich. Vergleiche die Datenverarbeitung von Google Analytics immer in den USA, wie Google selbst zugibt.

Das Urteil wurde nach meiner Kenntnis am 10.03.2022 rechtskräftig. Welche Auswirkungen hat das Urteil für Webseiten? Auf den Auskunftsanspruch nach Art. 15 DSGVO, den das Gericht feststellte, gehe ich hier gar nicht weiter ein, auch wenn das ebenfalls interessant ist.

Wer Datenschutz schon immer ernst genommen hat, für den hat das Urteil kaum Auswirkungen. Mich persönlich interessieren Google Fonts nicht, denn ich weiß im Gegensatz zu mancher Internet-Agentur, wie man Schriftarten herunterlädt und lokal einbindet. Auch brauche ich Google Maps nicht, denn dieses Karten-Plugin von Google lädt Google Fonts nach, und es gibt mildere Mittel (siehe meine Lösung für eine interaktive Karte).

Schadenersatzansprüche werden von deutschen Gerichten immer wieder beschieden. Das zeigt auch das Urteil des Landesarbeitsgericht (LAG) Berlin-Brandenburg vom 18.11.2021 (Az. 10 Sa 443/21). Einem Arbeitnehmer wurden wegen einer inhaltlich ungenügenden Datenauskunft, die auf zwei Auskunftsbegehren hin teils verspätet erteilt wurde, 2000 Euro Schmerzensgeld zugesprochen.

Auswirkungen

Offensichtlich sollten Google Schriften nicht mehr vom Google Server geladen werden. Das hielt ich schon immer für falsch. Eine lokale Einbettung (siehe oben) ist einfach möglich. Daran ändert auch die Tatsache nichts, dass dafür womöglich ein Fachkundiger eingesetzt werden muss. Es scheint manchen völlig fremd zu sein, jemandem Geld zu geben, der etwas kann, was man selber nicht kann. Allerdings ist es leider so, dass selbst bezahlte selbst ernannte Experten keine Experten sind. Gestern erzählte mir jemand, dass eine Werbe-Agentur für das Einbinden von Matomo auf einer Kunden-Webseite ganze 8 Personentage in Rechnung stellen wollte.

In meinem Beitrag zum Google Fonts Urteil beschreibe ich, was Google Fonts eigentlich sind und warum sie selbstverständlich lokal eingebettet werden dürfen. Google Fonts sind nämlich keine Schriften, die Google selber erstellt hat, sondern Werke von beliebigen Designern. Google stellt lediglich eine Infrastruktur zum Upload und Download der Fonts bereit. Das stimmt womöglich nicht ganz. Denn Google möchte vielleicht auch noch Signale erhalten, welcher Nutzer welche Webseite aufrief.

Ich kann jeden beruhigen, der Angst hat, dass der Traffic auf seiner Webseite weniger wird, wenn Google Fonts ab sofort lokal statt vom Google Server geladen werden. Webseiten können erfolgreich ganz ohne Google betrieben werden. Die Google Suchmaschine funktioniert dann immer noch. Ihre Webseite wird dann immer noch sehr gut oder sehr schlecht gefunden, genau wie zuvor.

Zweitverwendung von Google Fonts

Google Maps und Google reCAPTCHA sind zwei weit verbreitete Plugins für Webseiten. Beide Tools sind überwiegend nicht DSGVO-konform nutzbar. Das liegt unter anderem an den geladenen Cookies in unglaublicher Anzahl. Kennen Sie die Zwecke dieser Cookies? Schade, denn dann scheinen Sie die Pflichtinformationen nach Art. 13 DSGVO nicht erfüllen zu können. Diese gelten auch für Cookies, wie der EuGH im Planet49-Urteil feststellte. ich behaupte sogar, dass Sie nicht einmal die Namen der Cookies kennen, die von reCAPTCHA geladen werden.

Google Maps lädt Google Fonts nach. Das LG München Urteil hat Fonts für rechtswidrig erklärt, weil es für Google Fonts eine datenschutzfreundliche Variante gibt. Das mildere Mittel existiert also unbestritten. Eine weitere Bedingung für das Urteil ist der Fakt, dass personenbezogene Daten in die USA fließen. Hierbei wurde übrigens das EuGH-Urteil „Breyer“ berücksichtigt, seit dem auch dynamische IP-Adressen als personenbezogen gelten.

Beide Kriterien können zumindest in der am häufigsten verwendeten Variante auch auf Google Maps übertragen werden. Da Google Fonts nachgeladen werden, muss über den USA-Transfer nicht weiter diskutiert werden.

Google Maps kann offensichtlich einfach (oder auch nicht einfach, das spielt keine wesentliche Rolle) durch eine andere interaktive Karte ersetzt werden. Nehmen Sie OpenStreetMap (OSM). Die Originalversion des OSM-Plugins hat aus meiner Sicht Datenschutzmängel, die allerdings wesentlich kleiner sind als die von Google Maps. Daher sollten Sie ein modifiziertes OSM-Plugin nutzen. Ich habe da mal eins vorbereitet.

Dieses Plugin schickt keinerlei personenbezogene Daten zu irgendjemandem, außer zu ihrem eigenen Server. Dieser Transfer zu Ihrem eigenen Server findet in ausschließlich technisch notwendiger und somit in legitimer Weise statt.

Mein Fazit lautet also, dass das Google Maps Plugin gemäß des LG München Urteils ebenso rechtswidrig ist. Sofern es Ihnen gelingt, eine rechtskonforme Einwilligung abzufragen, dürfen Sie Google Maps weiterhin einbetten. Ich bezweifle, dass Ihnen das gelingt.

Für Google Maps müssen mehrere Einwilligungen eingeholt werden:

1. Datentransfer in die USA: Einwilligung gemäß Art. 49 Abs. 1 DSGVO
2. Kein berechtigtes Interesse oder sonstige direkt vorliegende Rechtsgrundlage: Einwilligung gemäß Art. 6 Abs. 1 DSGVO
3. Cookies (sofern vorhanden, was von der Art der Einbindung abhängt) gemäß § 25 TTDSG.

Für Google reCAPTCHA gilt ähnliches. Dieses Plugin gibt es allerdings in mehreren Ausprägungen. Ich beziehe mich hier nur auf die sichtbare Variante, die zum Schutz vor Formular-Spam eingesetzt wird. Sicher kennen Sie die Abfrage „Ich bin kein Roboter“.

Der USA-Datentransfer ist wie bei Google Maps aufgrund des Nachladens von Google Fonts durchargumentiert. Die vielen Cookies müssen hier gar nicht erwähnt werden. Auch für reCAPTCHA gibt es Alternativen, die datenschutzkonform sind.

Leider fehlte mir die Zeit, ein simples reCAPTCHA Plugin zu programmieren. Ich darf verraten, dass dies jedem Entwickler mit PHP- und Web-Kenntnissen möglich ist. An dieser Stelle könnte die Argumentation, dass es mildere Mittel für reCAPTCHA gibt, bereits enden.

Konstruktiv kann ich mitteilen, dass es bereits Lösungen existieren. Beispielsweise kann in einem Formular eine einfache Rechenaufgabe gestellt werden, deren Ergebnis nur ein Mensch eingeben kann. Eine solche Aufgabe könnte etwa lauten: "Wie viel ist 27 weniger 8?". Wenn Sie testen wollen, ob jemand Mathematik-affin ist, fragen Sie stattdessen "Wie viel ist 27 weniger -1,521?".

Honeypots und für den Menschen unsichtbare Formularfelder werden auch des öfteren verwendet. Für WordPress gibt es ein bekanntes Plugin für Formulare namens Contact Form 7. Dieses bietet bereits Basismittel für den Bot-Schutz. Mit dem Zusatzplugin Contact Form 7 Image Captcha kann eine weitere Absicherung erreicht werden.

Fast jeder für wenig Geld mietbare Server ist in der Lage, die Programmiersprache PHP zu interpretieren. Wer etwas programmieren kann, findet für PHP Captcha-Lösungen.

Auch für Google reCAPTCHA komme ich also zu dem Schluss, dass das Plugin aus den gleichen Gründen, die für Google Maps gelten, ohne gültige Einwilligung rechtswidrig ist.

Fazit

Der Einsatz von Google Plugins ist generell keine gute Idee, wenn der Anschein von Datenschutz auch nur im entferntesten bewirkt werden soll. Das Urteil des LG München zu Google Fonts macht es leicht, andere Google Tools in denselben Eimer zu werfen.

Andere Tools, die ebenfalls Google Fonts nachladen, können auch den eben genannten Tests unterzogen werden. Wahrscheinlich gibt es so gut wie kein ansonsten einwilligungsfreies Plugin gibt, welches alternativlos wäre. Demnach würde man sehr oft ein Plugin finden, dass ohne Einwilligung auskommt oder man müsste zugeben, dass das eingesetzte Plugin nur nach Einwilligung rechtskonform ist.

Wer mit dem Gedanken spielt, ein sogenanntes Cookie Popup einzusetzen: Cookie Popups sind eine schlechte Idee, außer, Sie wissen ganz genau, was Sie tun. Das wissen Sie aber nicht. Ich beleidige hiermit höchstens 0,1% der Leser und freue mich, diese kennenzulernen.

Wer eine Einwilligung abfragen möchte, sollte die Vorschriften beachten.

Sparen Sie sich doch den ganzen Ärger und verzichten Sie einfach auf Google Plugins. Eine Webseite, die Besucher nicht mit einem Cookie Popup nervt, ist doch was Feines. Wenn Sie unbedingt Google Analytics einsetzen wollen, dann wünsche ich Ihnen viel Spaß bei der Arbeit, eine serverseitige Infrastruktur aufzubauen. Ihr Geschäft muss dann wirklich sehr profitabel sein. Ansonsten würde es sich nicht lohnen. Hoffentlich werden Sie von Google nicht so abhängig, wie Deutschland vom russischen Gas.

Der Begriff GDPRmageddon ist von GDPR (dem englischen Wort für DSGVO) und Armageddon abgeleitet.

Die ePrivacy Richtlinie fokussiert insbesondere Informationen, die im Endgerät des Nutzers gespeichert sind. Siehe Art. 5 der Direktive, die zuerst unter der Nummer 2002/58/E erschien und später unter der Nummer 2009/136/EG aktualisiert wurde.

Artikel 5 Abs. 3 der Richtlinie besagt:

Die Mitgliedstaaten stellen sicher, dass die Speicherung von Informationen oder der Zugriff auf Informationen, die bereits im Endgerät eines Teilnehmers oder Nutzers gespeichert sind, nur gestattet ist, wenn der betreffende Teilnehmer oder Nutzer auf der Grundlage von klaren und umfassenden Informationen, die er gemäß der Richtlinie 95/46/EG u. a. über die Zwecke der Verarbeitung erhält, seine Einwilligung gegeben hat. Dies steht einer technischen Speicherung oder dem Zugang nicht entgegen, wenn der alleinige Zweck die Durchführung der Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz ist oder wenn dies unbedingt erforderlich ist, damit der Anbieter eines Dienstes der Informationsgesellschaft, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wurde, diesen Dienst zur Verfügung stellen kann.

Quelle: Art. 5 Abs. 3 Richtiline 2009/136/EG

Die dort benannte Richtlinie 95/46/EG ist am 25.05.2018 durch die DSGVO ersetzt worden. Dass Art. 5 Abs. 3 der Richtlinie für Deutschland gilt, hat der BGH festgestellt und gefordert, dass §15 Abs. 3 TMG richtlinienkonform auszulegen ist. Der § 25 TTDSG führt die Vorschrift in Deutschland explizit im Dezember 2021 ein. Das TTDSG wurde im Jahr 2024 in TDDDG umbenannt.

Oft wird die ePrivacy Richtlinie als Cookie-Richtlinie bezeichnet. Dies ist zumindest irreführend.

In der ursprünglichen Version der ePrivacy Richtlinie, 2002/58/EG, taucht der Begriff Cookie fünfmal auf, und zwar nur innerhalb der Rn. 25. Dies gilt sowohl für den Englischen als auch den Deutschen Text der Richtlinie.

In der aktualisierten Fassung der Richtlinie, 2009/136/EG, erscheint der Begriff Cookie nur ein einziges Mal, und zwar in einem Einschub. Wiederum gilt dies für den Englischen und den Deutschen Text der Richtlinie.

Wie später gezeigt wird, gilt die Richtlinie in wesentlichen Teilen für beliebige Daten, unabhängig davon, ob es sich um personenbezogene Daten handelt oder nicht.

Grundlagen zu Cookies

Cookies sind eine Art Datencontainer. Wer es genauer wissen will, findet Hintergrundinformationen zu Cookies in meinem Bullshit Basics-Beitrag. Insbesondere ist wichtig zu wissen: Cookies sind keine Textdateien, sondern Datensätze.

Cookies sind an eine Domäne gebunden. Eine Domäne ist etwa meine-webseite-abc.de.

Cookies können in der Domäne der aktuell besuchten Webseite erzeugt werden, und zwar entweder von der Webseite selbst oder jeder von der Webseiten geladenen JavaScript Datei (oft nur als Script bezeichnet)! Diese Art von Cookies werden First Party Cookies genannt.

Dateien – dies können beliebige Daten sein, es muss sich hier nicht um JavaScript Dateien handeln –, die von einem Dritt-Server geladen werden, können zusätzlich (!) Cookies in der Dritt-Domäne erzeugen. Diese Art von Cookies werden Third Party Cookies genannt.

In der Lage zu sein, ein Cookie zu erzeugen, heißt automatisch auch, in der Lage zu sein, das Cookie auszulesen, dessen Wert zu verändern oder es zu löschen.

Die folgende Abbildung illustriert Datentransfers, die zwangsläufig stattfinden, wenn ein Nutzer eine Webseite besucht, die ein Tool wie Google Maps oder Google Analytics oder ein Bild von Wikipedia einbindet:

Der hier gezeigte Datenaustausch ist durch das Internet Protokoll (IP-Protocol) als Teil des TCP/IP vorgegeben. Folgendes passiert also:

1. Die IP-Adresse und der Browser Fingerprint des Nutzers werden zur besuchten Webseite übertragen.
2. Die IP-Adresse und der Browser Fingerprint des Nutzers werden zum Server übertragen, von dem Google Maps durch die besuchte Website geladen wird.
3. Alle Cookies, die (bereits vor dem Ladevorgang!) in der Domäne (etwa google.com), von der die Karte geladen wird, existieren, werden an den Server übertragen, von dem die Karte geladen wird.
4. Die Cookies werden zurück an den Browser des Nutzers geschickt. Änderungen an den Cookies, die durch die eingebundene Karte vorgenommen wurden, werden angewandt.

Cookies können aus Sicht des Verantwortlichen für eine Webseite außer Kontrolle geraten. Hier ist ein prominentes Beispiel mit zwei Szenarien. Es bezieht such auf das Cookie namens NID, welches von einigen Google Diensten verwendet wird, um einen Nutzer zu identifizieren und nachzuverfolgen. Das folgende Beispiel bezieht sich auf Google reCAPTCHA – es gilt genauso für Google Maps!

Szenario 1: Das NID Cookie existiert noch nicht

1. Eine Website lädt Google reCAPTCHA von der Domäne google.com (neben anderen Domänen).
2. Das NID Cookie existiert nicht und wird nicht an Google reCAPTCHA übertragen und auch nicht von Google reCAPTCHA erzeugt.
3. Es gibt kein Problem mit dem NID Cookie, weil es nicht existiert.

Szenario 2: Das NID Cookie existiert, weil der Nutzer, der eine Webseite besucht, sich zuvor auf google.com (oder google.de) in sein Google Konto angemeldet hat:

1. Die Website lädt Google reCAPTCHA von der Domäne google.com
2. Das NID Cookie existiert bereits (vor dem Ladevorgang von Google reCAPTCHA) und wird deswegen zwangsweise aufgrund des Internet-Protokolls an Google reCAPTCHA übertragen
3. Hieraus entsteht ein Datenschutzproblem aufgrund des Third Party Cookies namens NID

Interessant ist hier:

Natürlich weiß der Verantwortliche für eine Webseite nicht, ob ein Besucher seiner Seite vor dem Besuch in seinen Google Account eingeloggt ist. Weil es aber möglich ist (und übrigens oft vorkommt), muss der Webseiten-Verantwortliche davon ausgehen, dass das NID Cookie relevant ist. Szenario 2 muss zwangsläufig als gegeben hingenommen werden.

Wenn zwei verschiedene Webseiten dasselbe Tool, wie beispielsweise Google Analytics, nutzen und wenn dieses Tool Third Party Cookies nutzt, dann können Daten zwischen diesen beiden verschiedenen Webseiten ausgetauscht werden. Hier hat allerdings nur das eingebundene Tool Zugriff auf diese Cookie-Daten, nicht die beiden Webseiten selbst. Dies war nur ein rein illustratives Beispiel.

Google (Universal) Analytics verwendet nämlich seit dem Jahr 2020 First Party Cookies. First Party ist ein Begriff der hier nur im technischen Sinn gemeint sein kann. Aus Datenschutzsicht erzeugt Google Analytics beim Erstaufruf das First Party Cookie und liest es bei Folgeaufrufen aus, um anschließend den ausgelesenen Cookie-Wert an einen Google Server zu schicken. Dies kann leicht bewiesen werden.

Konfigurationen von Google Analytics ohne Cookies sind anders zu beurteilen. Egal wie konfiguriert, rechtssicher ist das Tool nur nach Einwilligung nutzbar.

Wie werden Cookies vom Browser verwaltet?

In fast jeder Datenschutzerklärung liest man, dass ein Cookie eine Textdatei sei. Dies ist Bullshit.

Hier der Beweis, indem gezeigt wird, wie der populäre Mozilla Firefox Browser Cookies verwaltet.

Firefox speichert Cookies in einer Datenbank. Den Speicherort für die Cookie-Datenbank findet man so:

1. Firefox starten
2. Folgenden Text in die Adresszeile von Firefox eingeben:
   about:support
3. Das Profil-Verzeichnis öffnen, welches auf dem Bildschirm gezeigt wird
4. Im Verzeichnis befindet sich eine Datei namens cookies.sqlite, welche alle Cookies enthält, die auf dem Endgerät des Nutzers für den Browser gespeichert sind. Diese Datei heißt Cookie Datenbank. Die Dateiendung sqlite zeigt, dass die Datenbank SQLite verwendet wird. Es handelt sich um eine leichtgewichtige Datei-basierte Datenbank.

Die Inhalte dieser Cookie-Datenbank können mit dem kostenfreien Tool DB Browser for SQLite angesehen werden (Beschreibung für die englische Version):

Tool starten und die oben beschriebene Datei cookies.sqlite öffnen, indem „Open database“ angeklickt und dann die Datei ausgewählt wird. Vorher sollte man eine Kopie von der Datei machen. Auf den Karteireiter „Browse Data“ klicken, um alle Cookies und deren Werte zu sehen, die vom Browser verwaltet werden.

Wie man sieht, besteht ein Cookie nicht aus einer Textdatei. Vielmehr gibt es eine einzige Datei, in der alle Cookies zusammen abgespeichert sind. Genauer habe ich es in einem Bullshit Basics Artikel untersucht.

Web Storage

Web Storage wird auch als Super Cookie bezeichnet, denn damit können pro Datensatz viel mehr Daten gespeichert werden als mit gewöhnlichen Cookies. Verglichen mit Cookies, agiert Web Storage ausschließlich wie ein First Party Cookie.

Firefox speichert Informationen hierzu im Datenbank-File webappsstore.sqlite. Siehe auch https://en.wikipedia.org/wiki/Web_storage für Details.

Hier ist ein einzelner von insgesamt 24 Datensätzen, die aktuell auf meinem Endgerät in dieser Datenbank gespeichert sind:

Lediglich die Value-Angaben habe ich für den Screenshot aus Datenschutzgründen abgeändert. Die Spalte Value enthält meine eigene IP-Adresse. Sie lautet 22.33.44.55.

Die IP-Adresse wurde in diesem Fall abgespeichert. In anderen Datensätzen wurde keine IP-Adresse abgespeichert, sondern andere Daten. Lustig übrigens, dass die Spalten originalKey und scope die tatsächlichen Werte in Rückwärtsschreibung enthalten. Demnach steht moc.sysofni.www.:https für https:.www.infosys.com.

In Firefox kann man diese Web Storage-Werte wie folgt sehen:

• Eine Webseite öffnen, die die IP-Adresse zum Nutzer in der Web Storage ablegt (wie etwa https://www.infosys.com)
• Evtl. ein paar Sekunden warten
• F12 drücken, um die Entwicklerkonsole in Firefox zu öffnen
• Auf den Karteireiter Web-Speicher klicken
• Dort auf den Knoten Local Storage klicken. Dort sieht man dann:

Wie zuvor, habe ich hier den echten Wert mit einem Dummy-Wert ersetzt. Der Wert 22.33.44.55 repräsentiert meine IP-Adresse!

Der Wow-Effekt

Die ePrivacy Richtlinie bezieht sich insbesondere auf Daten, die im Endgerät des Nutzers gespeichert sind. Vgl. hierzu Artikel 5 Abs. 3 der Richtlinie.

Der Passus besagt, dass eine Einwilligung erforderlich ist, wenn alle folgenden Punkte zusammen zutreffen:

1. Daten sind im Endgerät des Nutzers gespeichert
2. Es wird auf diese Daten zugegriffen
3. Die Daten werden für Zwecke verwendet, die im strengen Sinne nicht erforderlich sind, um die Webseite bereitzustellen

Nehmen wir das Beispiel Google (Universal) Analytics in seiner aktuellen Standardkonfiguration. Google Analytics setzt First Party Cookies ein. Daraus kann man folgendes feststellen – und beweisen (was ich hier nicht tue, aber jederzeit tun kann):

1. Google Analytics erzeugt beim Erstaufruf Cookies: Daten sind im Endgerät des Nutzers gespeichert. Es wäre auch ausreichend, wenn ein anderer Dienst diese Cookies erzeugte.
2. Bei Folgeaufrufen liest Google Analytics diese Cookies aus: Es wird auf diese Daten zugegriffen.
3. Google Analytics kann auch konfiguriert werden, dass es ohne Cookies betrieben werden kann: Die Cookie-Daten sind also nicht zwingend erforderlich.

Juristische Ableitung:

Offensichtlich spielt es keine Rolle, ob First oder Third Party Cookies verwendet werden. Siehe hierzu die Ausführungen in Art. 5 der ePrivacy Richtlinie.

Auch spielt es keine Rolle, ob personenbezogene oder andere Daten erhoben werden. Siehe hierzu das EuGH-Urteil vom 01.10.2019 (Az. C-673/17, "Planet49"), etwa Rn. 82.

Offensichtlich gilt die ePrivacy Richtlinie für Deutschland. Siehe hierzu beispielsweise Buchstabe b auf der ersten Seite des BGH-Urteils vom 28.05.2020 – I ZR 7/16. Ab Dezember 2021 greift § 25 TTDSG.

Fazit: Für Google Analytics ist eine Einwilligung erforderlich, wenn Cookies verwendet werden.

Aus den gleichen Gründen gilt eine Einwilligungspflicht für

• Google Maps
• Google reCAPTCHA
• Eingebundene YouTube Videos mit Cookies (ohne Cookies auch, aber aus anderen Gründen)

Für Google Analytics ohne Cookies ist eine Einwilligung aus anderen Gründen ebenfalls vorgeschrieben. Bitte beachten Sie, dass Google selbst zugegeben hat, dass sämtliche Analytics-Daten immer in den USA verarbeitet werden.

Was ist mit Fingerprints?

Ein Fingerprint ist ein digitaler Fingerabdruck des Endgeräts eines Nutzers. Mit einem solchen Fingerabdruck können Nutzer auch ohne Cookies und ohne Verwendung der IP-Adresse des Nutzers wiedererkannt werden. Oft wird von Device Fingerprint oder Browser Fingerprint gesprochen.

Beim Fingerprinting werden Kennzahlen des verwendeten Browsers und Endgeräts des Nutzers ausgelesen. Dazu gehören Charakteristiken des Bildschirms, etwa die Auflösung oder Farbtiefe, aber auch die Zeitzone, das Betriebssystem oder der verwendete Browser.

Um einen digitalen Fingerabdruck zu erzeugen, werden die erwähnten Kennzahlen aus dem Endgerät des Nutzers ausgelesen. Diese Kennzahlen sind allerdings nicht (im Sinne der ePrivacy-Richtlinie) im Endgerät des Nutzers gespeichert. Vielmehr handelt es sich um jederzeit abfragbare Daten, die in der Hardware oder Software verankert sind, je nach Attribut. Ein Zugriff auf einen festen Speicher im Endgerät erfolgt hierbei nicht.

Analog verhält es sich mit der IP-Adresse, die nicht im Endgerät des Nutzers gespeichert ist, sondern vielmehr vom Zugangspunkt zum Internet (meist einem Router, einer FRITZ!Box o. ä.) verwaltet wird. Auch ein Monitor hat keine feste Farbanzahl, weil diese auf Ebene des Betriebssystems eingestellt werden kann.

Insofern fällt das Fingerprinting auch nicht unter den Schutz der ePrivacy-Richtlinie, womöglich aber unter den von § 15 Abs. 3 TMG.

Mit Fingerprinting können Nutzer gemäß einiger vorliegender Studien mit einer Wahrscheinlichkeit von über 90 % eindeutig identifiziert werden.

Update vom 27.07.2023: Das Data Privacy Framework (DPF) zwischen der EU und den USA ist in Kraft. Es erlaubt Datentransfers in die USA, wenn alle Datenempfänger über das DPF zertifiziert sind. Es ist fragwürdig, ob das Abkommen Bestand haben wird, da es auf einer wackligen Executive Order basiert. Unabhängig davon, sprechen weitere Gründe gegen den Einsatz von Google reCAPTCHA (siehe Beitrag).

Update vom 16.05.2023: Die Verbraucherzentrale hat ein Urteil gegen die Telekom erstritten. Das Gericht sagt, dass die Datenübermittlung an Google in die USA nur unter sehr engen Grenzen erlaubt ist.

Update vom 12.04.2022: Die französische Datenschutzaufsicht CNIL hat aufgrund einer Beschwerde bestätigt, was schon lange bekannt hätte sein müssen: Dass nämlich Google reCAPTCHA erst nach Einwilligung genutzt werden darf. Begründung von CNIL, soweit ich es verstanden habe: Das Tool sei nicht nur zur Gefahrenabwehr gedacht, sondern sammle auch (unnötigerweise) fleißig Daten zu anderen Zwecken.

Mit Google reCAPTCHA werden Nutzer und deren Verhalten auf der Webseite, wo reCAPTCHA eingebunden ist, ausgesprochen tiefgehend analysiert. Und zwar (vordergründig), um einen Menschen besser von einem Roboterprogramm unterscheiden zu können. Da der reCAPTCHA Code u. a. von der Domäne google.com geladen wird, erhält das Tool automatisch Zugang zu Cookies, die für angemeldete Google Nutzer gesetzt werden. Eines der Cookies heißt NID und enthält eine eindeutige Nutzerkennung, die auch für Google Signals verwendet wird, um sogar geräteübergreifend Nutzer wiedererkennen zu können. Insofern ist es datenschutzrechtlich fast unerheblich, ob reCAPTCHA (situativ) weitere Cookies setzt oder nicht.

Zusätzlich greift reCAPTCHA auch auf die Domäne gstatic.com zu. Wie auf Google Webseiten nachzulesen, wird diese Domäne auch von anderen Tools verwendet. Somit können über diese Domäne potentiell Cookies ausgetauscht werden.

Am Abruf eines einzigen Scripts von reCAPTCHA zeige ich auszugsweise, wie viele Cookies von reCAPTCHA genutzt werden:

Aufgrund der Anzahl an übertragenen Cookies wird das Datenschutzproblem mit Google reCAPTCHA ganz gut deutlich. Wie Google selbst zugibt, sind nicht alle Cookies technisch notwendig: „In addition to certain standard Google cookies, reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.“ (Quelle: https://developers.google.com/recaptcha/docs/faq. Update: Der Satz hat sich sprachlich mittlerweile leicht geändert; die Bedeutung ist gleich geblieben). Die Standard-Cookies von Google sind solche wie NID. NID ist dazu geeignet, den Nutzer nachzuverfolgen, und zwar sowohl für Marketing-Zwecke als auch für die Bildung von Nutzerprofilen. Dies gibt Google selbst zu ("Manche Cookies dienen dazu, die Einstellungen eines Nutzers zu speichern. In den Browsern der meisten Nutzer, die Google-Dienste verwenden, gibt es beispielsweise ein Cookie namens „NID“. Dieses Cookie enthält eine eindeutige ID, über die Ihre bevorzugten Einstellungen und andere Informationen gespeichert werden…", Quelle: https://policies.google.com/technologies/cookies?hl=de=).

Hieraus bereits ergibt sich eine Einwilligungspflicht:

• Gemäß BGH-Urteils zu Planet 49 ist § 15 Abs. 3 TMG konform zu Art. 5 Abs. 3 ePrivacy Richtlinie auszulegen. Das TMG ging im Mai 2024 in das DDG über.
• Art. 5 (3) der ePrivacy-Richtlinie fordert eine Einwilligung, wenn auf Informationen, die im Endgerät des Nutzers gespeichert sind, zugegriffen wird und dies technisch nicht notwendig ist. Der Zugriff auf Cookies ist bewiesen. Technisch sind diese nicht notwendig, alleine die schiere Anzahl an Cookies kann dies beweisen. Die Cookies werden aufgrund Ihrer Anzahl und Wertausprägungen auch für Marketing-Zwecke verwendet. Das Gegenteil zu beweisen dürfte schwierig werden.
• Der EuGH hatte im Planet49-Urteil festgestellt, dass es unerheblich ist, ob die durch Cookies erhobenen Daten personenbezogen sind oder nicht.
• Ab Dezember 2021 gilt § 25 TTDSG in Deutschland für Cookies

Wenn Google reCAPTCHA verwendet wird, um Formulare abzusichern, dann scheidet ein berechtigtes Interesse schon alleine deshalb aus, weil es zahlreiche wirkungsvolle Alternativen gibt, die deutlich datenschutzfreundlicher sind. Das berechtigte Interesse ist nur der Notnagel unter den Rechtsgrundlagen, die die DSGVO in Art. 6 Abs. 1 DSGVO benennt. Zumindest sollte bei mit datenschutzfeindlichen Captchas abgesicherten Formularen auch direkt am Formular eine Möglichkeit geboten werden, direkt eine Mail zu schreiben.

Varianten

Laut https://developers.google.com/recaptcha/docs/versions gibt es mehrere Varianten von reCAPTCHA:

Die bisherige Version 2 steht in einer visuellen und einer unsichtbaren Ausprägung zur Verfügung.

reCAPTCHA Version 3 ist immer unsichtbar bzw. erstellt für den aktuellen Nutzer einen Score-Wert. Mit diesem Score kann die aufgerufene Webseite feststellen, ob es sich um einen menschlichen Besucher oder um einen Roboter handeln könnte.

Nutzungsbedingungen

Zur Nutzung von Google reCAPTCHA müssen die Nutzungsbedingungen akzeptiert werden, die u. a. folgendes besagen1: „Sie bestätigen und nehmen zur Kenntnis, dass die Funktionsweise der reCAPTCHA API darauf beruht, dass Hardware- und Softwareinformationen, z. B. Geräte- und Anwendungsdaten, erhoben und zu Analysezwecken an Google gesendet werden.“ sowie „Für Nutzer in der Europäischen Union müssen Sie die Richtlinie zur EU-Nutzereinwilligung einhalten und Ihre API-Clients müssen dieser Richtlinie entsprechen.“ (Fettdruck hinzugefügt, Link aus der Quelle entfernt).

Ein Einsatz von Google reCAPTCHA ohne Einwilligung erscheint demnach kaum haltbar und ist gemäß Google Nutzungsbedingungen³¹ sogar untersagt. Die Nutzungsbedingungen sind dort wie folgt in mehreren Teilen angegeben:

• Nutzungsbedingungen für Google APIs
• Nutzungsbedingungen von Google
• Nutzungsbedingungen für reCAPTCHA:

Sie bestätigen und nehmen zur Kenntnis, dass die Funktionsweise der reCAPTCHA API darauf beruht, dass Hardware- und Softwareinformationen, z. B. Geräte- und Anwendungsdaten, erhoben und zu Analysezwecken an Google gesendet werden. Die bei der Verwendung des Dienstes erhobenen Informationen werden zur Verbesserung von reCAPTCHA und für die allgemeine Sicherheit verwendet. Sie werden von Google nicht für personalisierte Werbung genutzt. Gemäß Abschnitt 3(d) der Nutzungsbedingungen für Google APIs erklären Sie sich damit einverstanden, dass Sie bei Verwendung der APIs dafür verantwortlich sind, die erforderlichen Hinweise oder Einwilligungen zur Erhebung und Weitergabe dieser Daten für Google bereitzustellen bzw. einzuholen. Für Nutzer in der Europäischen Union müssen Sie die Richtlinie zur EU-Nutzereinwilligung einhalten und Ihre API-Clients müssen dieser Richtlinie entsprechen. Ihre Verwendung von reCAPTCHA unterliegt bestimmten Beschränkungen bei Aufrufen. Google behält sich das Recht vor, diese Beschränkungen nach alleinigem Ermessen durch sämtliche unter Beschränkungen bei Aufrufen oder in diesen Nutzungsbedingungen beschriebenen Maßnahmen zu erzwingen.

Quelle: https://www.google.com/recaptcha/admin/create

Viel Erfolg beim Lesen, Verstehen und Einhalten dieser komplexen Bedingungen. Lesenswert ist die Richtlinie zur EU-Nutzereinwilligung von Google. Sollte ein Dritter Auskunft begehren, dann könnte dies einen komplexen Vorgang auslösen.

Ich kann daher nur vom Einsatz von Google reCAPTCHA abraten, da eine Einwilligung erforderlich ist und rechtssicher kaum eingeholt werden kann.

Alternativen

Für WordPress und das beliebte Contact Form 7 Kontaktformular gibt es mit Contact Form 7 Image Captcha eine nutzerfreundliche und datenschutzfreundliche Variante.

Nahezu jeder Server unterstützt PHP. Mit PHP kann auf recht einfache Weise ein Captcha erstellt werden. Hier ist ein Beispiel in PHP, das einen Text als Bild ausgibt.

 <?php
$img = imagecreatetruecolor(300, 80);
$text_color = imagecolorallocate($img, 233, 200, 200);
imagestring($img, 2, 1, 1,  'Datenschutz hilft', $text_color);

$x=imagejpeg($img,"test1.jpg");

imagedestroy($img);

Ein anderes PHP Beispiel zeigt, wie man einfache Rechenaufgaben als Abfrage nutzen kann.

Ganz einfach geht es, wenn eine Rechenaufgabe als gewöhnliches Eingabefeld ausgeprägt ist. Beispielsweise könnte die Frage lauten: „Wie viel ist siebzehn weniger drei“. Als Antwort wäre zugelassen: „vierzehn“ oder „14“. Die Antwort könnte mit einer einfachen JavaScript Funktion geprüft werden. reCAPTCHA erfordert immerhin auch einiges an Entwicklerkenntnissen und auch an rechtlichen Kenntnissen.

Ein weiterer Beitrag beschreibt Alternativen für häufig verwendete Google Tools.

Sollte eine Agentur auf dem Einsatz von reCAPTCHA bestehen, bitte Sie die Agentur doch um eine Haftungsübernahme und sehen Sie, was passiert. Sollte die Agentur meinen, eine andere Lösung wäre nicht möglich, schlagen Sie doch vor, jemanden zu kennen, der kostenpflichtig die Agentur bei dieser unlösbaren Aufgabe unterstützen kann. Wenn jemand reCAPTCHA vorschlägt, sollte derjenige die grundlegenden rechtlichen Bedingungen kennen.

DSGVO WEBSITE-CHECK

Ist Ihre Website DSGVO-konform?

Website in wenigen Sekunden auf DSGVO-Compliance prüfen

Jetzt Website prüfen

✓ kostenfrei ✓ Sofort-Ergebnisse ✓ Keine Anmeldung

Wie so oft bei Webseiten gibt es für die offensichtlich bekannten Möglichkeiten oft bessere Alternativen, die funktionell mit den Platzhirschen mithalten können. Im Unterschied zu Google-Diensten oder anderen bekannten Verdächtigen bieten datenschutzfreundliche Möglichkeiten aber eine hohe Rechtssicherheit und oft eine maximale Autarkie. Wer will schon abhängig von einzelnen Konzernen sein? Ich jedenfalls nicht. Deshalb empfehle ich auch, Google-Anwendungen so wenig wie möglich zu verwenden. Das beginnt beim mobilen Endgerät, für das auch ent-Google-te Geräte wie das Fairphone auf Android-Basis zur Verfügung stehen. Es geht weiter bei Suchmaschinen, die weder von Microsoft noch von Google stammen. Als Beispiele seien Ecosia, DuckDuckGo und Startpage genannt. Die Ergebnisse sind sehr gut und der Datenhunger gar nicht oder deutlich weniger vorhanden als bei amerikanischen Internetkonzernen. Wenn Sie allerdings lieber amerikanischen Geheimdiensten Ihre Daten anvertrauen möchten, dann nutzen Sie weiter Google & Co. (welche es selber zugeben, dass sie von amerikanischen Behörden, wie dem FBI, ausgehorcht werden).

Nutzen von Google Maps

Die möglichen Anwendungsfälle von Google Maps bzw. einer interaktiven Karte an sich, denn darum geht es vor allem, sind weiter unten beschrieben.

Dass die meisten Webseiten-Betreiber sich nicht wirklich Gedanken über den Nutzen von Google Maps gemacht haben, zeigt alleine schon die Tatsache, dass die meisten eingebetteten Karten ein beliebiges Verkleinern (rauszoomen) erlauben. Auch kann der Kartenausschnitt beliebig verschoben werden. Wenn man eine Metzgerei in Büttelborn besuchen möchte, frage ich mich, warum eine Karte dann auch Brasilien anzeigen können muss oder warum man so weit rauszoomen kann, dass die Karte alle Kontinente auf einmal anzeigt.

Datenschutzprobleme mit Google Maps

Durch das Einbinden von Google Maps werden Dateien von mehrere Domänen abgerufen, nämlich von:

• google.com
• fonts.gstatic.com (Google Fonts, spätestens seit dem Urteil des LG München vom 20.01.2022 hochkritisch)
• maps.googleapis.com
• maps.gstatic.com
• khmsx.googleapis.com mit x = 0,1 …

Dabei wird u.a. die Google ID eines Nutzers, sofern dieser mit seinem Google Konto angemeldet ist, übertragen. Vgl. die Ausführungen zu Google reCAPTCHA hierzu.

Die Lösung von Dr. DSGVO ist absolut datenschutzfreundlich und kostenfrei erhältlich.

Weiter unten sehen Sie, wie Sie an die Lösung kommen.

Weiterhin werden beim Laden des Google Maps Scripts und seiner Teile zahlreiche Cookies transferiert, u. a. diese:

Gemäß § 15 Abs. 3 TMG in konformer Auslegung zur ePrivacy Richtlinie (Art. 5 Abs. 3) ist dies ohne Einwilligung unzulässig. Das TMG ging im Mai 2024 in das wortgleiche DDG über. Die konforme Auslegung ist zwingend, wie das BGH feststellte (Planet49-Urteil). Diese Cookies kommen möglicherweise nicht bei jedem Nutzer ins Spiel. Es hängt anscheinend von der Konfiguration des Browsers ab, ganz sicher aber auch von der bisherigen Browser-Historie des Nutzers.

Update: Bei Nutzung der Google Maps JavaScript API werden anscheinend keine Cookies gesetzt. Diese Nutzungsart ist nicht überall anzutreffen, wie man feststellen muss. Weitere Aspekte außer den Cookies lassen Google Maps selbst in der datenschonenderen Variante allerdings ebenfalls fragwürdig erscheinen.

Ein direktes Laden von Google Maps mit Cookies verstößt somit gegen Datenschutzgesetze. Es gibt darüber hinaus weitere Gründe, die mit transparenter Information (Art. 12 DSGVO), Zweckbindung und Datenminimierung (Art. 5 DSGVO) zu tun haben.

Mögliche Voreinstellungen, die mit der Google ID verknüpft sind, sind für eine benutzerfreundliche Darstellung der Google Karte nicht erforderlich: Nach dem Löschen aller Cookies und dem Neuladen einer Webseite mit einer Google Karte wurde die Karte genauso dargestellt wie zuvor. Insbesondere war die Spracheinstellung dieselbe.

Vielmehr setzt Google Maps sogar das NID Cookie neu, wenn es – nach einem Abmelden vom Google Nutzerkonto oder dem manuellen Löschen aller Cookies – nicht vorhanden ist.

Google Maps lädt Google Schriften nach, was die Komplexität der Datenaustauschvorgänge jedenfalls nicht verringert. Ein Einsatz von Google Maps ohne Einwilligung erscheint demnach kaum bis gar nicht haltbar. Das Kartentool von Google ist als Tracker einzustufen.

Wer es richtig machen will, fragt auf der Karte nach der Einwilligung. Das hat mehrere Vorteile:

• Dort, wo die Karte stehen würde, ist genügend Platz zur Abfrage einer halbwegs rechtssicheren Einwilligung
• Populäre Consent Management Plattformen sind an sich einfach nur schlecht (dies ist meine Meinung nach einem umfangreichen Test).
• Die Entzerrung der Einwilligungsabfrage kann bedeuten, dass man auf eine globale Einwilligung verzichten kann und den Nutzer nur auf den Seiten um Einwilligung bitten muss, wo die Karte zu sehen wäre. Außerdem wird eine globale Consent Abfrage, sofern vorhanden, dann leichter beherrschbar, weil sie nicht mehr so unsäglich viele Einwilligungen abfragen muss.

Alternativen für Google Maps

Ich schlage die Ablösung der meisten Google Maps Einbindungen auf Webseiten vor, und zwar je nach Anwendungsfall wie folgt:

Interative Karte – Lösung von Dr. DSGVO

Auf Ihrer Webseite wird wie bisher eine interaktive Karte analog zu Google Maps angezeigt. Der Unterschied: Die Karte ist absolut datenschutzkonform und kann auf verschiedene Arten dargestellt werden. Die erste Ansicht zeigt eine topologische Karte:

Die zweite Ansicht ist die Normalansicht analog zu OpenStreetMap:

Der Unterschied zur Einbindung von OpenStreetMap ist, dass kein Datentransfer zur OpenStreetMap Foundation mit Sitz im außereuropäischen Ausland stattfindet. Sie müssen nun auch nicht mehr vergeblich das Impressum oder die Datenschutzerklärung auf der OSM-Webseite suchen, um den Verantwortlichen für die Datenverarbeitung zu ermitteln. Außerdem ist der Kartenausschnitt begrenzt auf Ihren Unternehmensstandort plus einem relevanten Umkreis. Zusätzlich bietet die Karte praktische Funktionen, wie einen eingebauten Button zum Aufruf einer Routenplanung oder ein Zurückspringen der Karte zu Ihrem Standort.

Anfahrtsbeschreibung

Karte komplett entfernen, Button zum Aufruf eines Routenplaners einbauen, Aufruf von Google Maps auf maps.google.com in neuem Fenster. Beispielaufruf des Routenplaners mit vorgegebener Zieladresse:

https://www.google.de/maps/?daddr=Hauptstrasse+23,11111+Musterstadt

Lage anzeigen

Das Anzeigen der Lage ergibt bei regionalen Geschäften möglicherweise Sinn.

Ich empfehle, ein stilisiertes Bild einer Karte zu nehmen. Dieses kann entweder selbst erstellt werden (ja, es macht Arbeit, ist aber viel aussagekräftiger als eine generische Karte ohne Liebe) oder es gibt sie womöglich vom Stadtmarketing. Wo ein Wille ist … Ein Open-Source-Projekt, welches Karten wie die folgenden zeichnen kann, ist prettymaps.

Hier ein (nicht wirklich stilisiertes) Bild der Innenstadt von Idstein, welches als eines von mehreren Bildern genommen werden könnte, um die Lage eines Ladens geschäftsfördernd darzustellen. Weitere Bilder könnten die Lage aus der Vogelperspektive zeigen.

Ein Klick auf das Bild zeigt sogar, was sonst so alles möglich ist, wenn man akzeptiert, dass es auch andere Lösungen als die von Google gibt.

Wer unbedingt eine Karte verwenden möchte, sollte eine OpenStreetMap Variante verwenden, die ich in einem eigenen Artikel beschreiben werden. Die Variante wird selbst oder von einem Dienstleister in Deutschland betrieben. Außerdem kann die Karte nicht beliebig verschoben oder gezoomt werden. Für einen Laden in Darmstadt muss doch nicht auch noch Frankfurt oder gar ganz Deutschland angezeigt werden können.

Herdentrieb

Herdentrieb heißt: Jeder verwendet Google Maps, also muss die dreimillionste Webseite auch Google Maps einsetzen. Warum, ist nicht so ganz klar, aber wahrscheinlich, weil es jeder macht, und das, was viele machen, muss richtig sein.

Lösung: Karte entfernen. Niemand muss auf einer Karte sehen, wo eine Firma sitzt, wenn er nicht hinfahren soll oder will. Wenig zielführend ist eine Karte, die einen Standort aus der maximalen Vogelperspektive anzeigt, womöglich in Form einer Weltkarte.

Anzeige mehrerer Standorte

OpenStreetMap verwenden, am besten als Hosting auf eigenem Server. In Kürze liefere ich eine Lösung, wie OpenStreetMap komfortabel auf der eigenen Webseite betrieben werden kann, ohne dass Datentransfers an Dritte stattfinden. Das Problem beim Einbinden von OpenStreetMap etwa über einen Server der OpenStreetMap Foundation ist, dass die Adresse dieser Organisation nicht genau benannt ist bzw. keine Garantien vorliegen, dass diese Organisation die erhaltenen Daten (Verbindungsdaten Ihrer Besucher) sorgsam behandelt.

Update: Hier gibt es einen Konfigurator für mehrere Standorte, die gleichzeitig auf ein und derselben Karte angezeigt werden sollen. Pro Standort kann jeweils eine eigene Beschriftung (Label) angezeigt werden, die unter dem Standortsymbol auf der Karte angezeigt wird.

In einem extra Beitrag sind Alternativen für verschiedene andere Google Tools beschrieben.

Wer einfach nur eine Karte ansehen oder auf diese von seiner Webseite verlinken will, sollte sich die Metager Karte ansehen. Die Karte basiert auf OpenStreetMap, wird aber von einem deutschen Anbieter betrieben, der laut Impressum sogar gemeinnützig ist.

Die Konfiguratoren für Karten der unterschiedlichen Art (ein Standort pro Karte, mehrere Standorte auf derselbe Karten) sind mit diversen Features ausgestattet. So gibt es beispielsweise die Möglichkeit, ein Plugin für WordPress zu generieren. Nach dem Download des WordPress-Plugins einfach im Admin-Bereich im WordPress das Plugin hochladen und aktivieren. Danach kann an gewünschter Stelle auf einer Seite (Page) oder in einem Beitrag (Post) die interaktive Karte mit einem sogenannten Shortcode eingebunden werde. Der Shortcode für die Dr. DSGVO Karte lautet [iak]. Danach nur noch den Datenschutzhinweistext auf der Seite mit der Datenschutzerklärung mit dem nötigen Hinweis auf den Urheber versehen und fertig ist die datenschutzkonforme Lösung. Die interaktive Karte behält alle Nutzerdaten lokal für sich und gibt sie nicht an Dritte weiter. So einfach kann die Welt sein, wenn man nicht Google heißt und Daten ohne Ende sammeln möchte.

Als Tool wird hier ein elektronischer Dienst verstanden, der in eine Webseite integriert werden kann. Die Einbindung findet üblicherweise über ein HTML-Tag wie script statt. Es handelt sich bei Tools üblicherweise um Javascript-Anwendungen. Hierzu gibt es allerdings zahlreiche Ausnahmen.

Technisch können u. a. folgenden Arten von Diensten unterschieden werden:

• JavaScript-Funktionen
• Zählpixel
• Backend-Funktionen

JavaScript-Funktionen können direkt (inline) in eine Webseite eingebunden oder über eine HTML-Anweisung von einem eigenen Server oder einem Server Dritter nachgeladen werden. Eine derart geladene JavaScript-Funktion kann „für“ die Webseite agieren, also auch Cookies setzen. Weil die JavaScript-Funktion anstelle der Webseite agieren kann, können mit dieser Funktion auch First-Party Cookies gesetzt werden. Diese Cookies sind nur aus technischer Sicht einer Erstpartei zugeordnet. Aus Datenschutzsicht handelt es sich um Drittpartei-Cookies (Third-Party Cookies).

Zählpixel sind (meist) unsichtbare Bilddateien, die als Hauptzweck das Identifizieren und Nachverfolgen von Nutzern haben (auch als Tracking bezeichnet). Wenn eine solche Bilddatei von einem Dritt-Server geladen wird, dann werden dabei auch Cookies übertragen.

Backend-Funktionen laufen direkt auf dem Server, der die Webseite betreibt. Sie haben datenschutzrechtlich eine geringere Relevanz als JavaScript-Funktionen und Zählpixel, weil üblicherweise (aber nicht immer) bei Backend-Logiken keine kritische Datenverarbeitung stattfindet oder diese zumindest von außen nicht nachweisbar ist.

Alle diese Arten von Diensten können Cookies setzen, auslesen und ändern.

Populäre Tools für Webseiten

Auf Webseiten werden einige Tools besonders häufig eingesetzt. Diese sind nach meinem Eindruck:

• Google Maps
• Google Schriften
• Fonts.com (die Nutzungsbedingungen fordern den Einbau eines Zählpixels)
• Google reCAPTCHA
• Google Analytics
• Google Tag Manager
• YouTube Videos (als Einbettung)
• Vimeo Videos (als Einbindung)
• SoundCloud Audio Player
• Social Media Plugins von Facebook, Twitter und anderen
• JavaScript-Bibliotheken wie jQuery
• Externe Dateien von einem Content Delivery Network

Die meisten populären Tools sind datenschutzrechtlich als hochkritisch zu bezeichnen. Sie bedürfen oft einer Einwilligung, die allerdings kaum rechtssicher eingeholt werden kann. Beispielsweise muss für die kostenpflichtigen Schriften von Fonts.com eine Einwilligung vom Nutzer vor deren Einsatz eingeholt werden, weil der Schriftanbieter fordert, dass ein Zählpixel für Abrechnungsmodalitäten eingebaut wird. Zusätzlich sitzt der Anbieter noch in einem unsicheren Drittland. Damit verstößt ein Datentransfer gegen die DSGVO. Auch die USA gelten als unsicheres Drittland und werden es immer bleiben, solange Gesetze wie FISA Sektion 702 oder Cloud Act existieren. Daran ändern auch Datenschutzabkommen, die als Nachfolge zum Privacy Shield entstehen könnten, kaum etwas.

Für zahlreiche Website Tools besteht eine Einwilligungspflicht aus verschiedenen Rechtsgrundlagen. Für die populärsten Tools habe ich die Grundlagen in einem eigenen Artikel aufbereiten.