ePrivacy Richtlinie: Informationen, die im Endgerät des Nutzers gespeichert sind

Kategorien: Datenschutz, Cookies und Recht

Welche Informationen sind im Endgerät eines Nutzers gespeichert und welche nicht? Diese Frage ist wichtig, wenn es um die Prüfung einer Einwilligungspflicht für Dienste wie Google (Universal) Analytics, Google Maps oder Google reCAPTCHA geht. Die ePrivacy-Richtlinie wurde in Deutschland durch das Datenschutzgesetz TTDSG realisiert.

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.

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.