1. Cookie-Banner
Consent- oder auch Cookie-Banner sind Werkzeuge, mit denen beim Besucher einer Webseite eine datenschutzrechtliche Einwilligung in die Erhebung und Verarbeitung von Nutzerdaten eingeholt werden kann, bevor diese erfasst werden. Diese Einwilligung muss vor dem Beginn der Datenverarbeitung und auf der Grundlage einer ausreichenden Information der betroffenen Person erfolgen.
Datenschutzrechtlich betrachtet sind diese Cookie-Banner durchaus sinnvoll, allerdings ist ihre Umsetzung in der Praxis oftmals fragwürdig. Entweder sie werden vergessen, sind unvollständig, betreiben Nudging oder erheben Nutzerdaten auch dann, wenn der Betroffene lediglich »technisch notwendige Cookies« erlaubt hat. Nicht zuletzt bestärkt durch das BGH-Urteil zu Planet49 dürften die Cookie-Banner demnächst in verstärkter Form auftreten.
Wer auf seiner Internetseite also Cookies setzen möchte, mit denen er das Verhalten des Nutzers erfasst und ein Nutzerprofil von ihm erstellt, der braucht eine aktive Zustimmung des Nutzers bzw. Betroffenen. Es stellt sich nun die Frage, ob man seine Nutzer auch ohne die Einholung einer Einwilligung tracken darf – bspw. dann, wenn man eine cookiefreie-Trackinglösung einsetzt. Im vorliegenden Beitrag soll eben jene Variante vorgestellt werden, die ein einwilligungsfreies Tracking via Matomo ermöglicht. Gerade kleine bis mittelgroße Webseiten können davon profitieren, da sie sich dann je nach Aufbau der Webseite den Cookie-Banner einfach »sparen« können.
2. Matomo
Matomo (ehemals Piwik genannt) ist eine Open-Source-Webanalytikplattform. Webseitenbetreiber können Matomo entweder selbst oder beim Anbieter in der Cloud hosten. Sofern Matomo auf dem eigenen Server betrieben wird, ist die Einhaltung des Datenschutzes (nachprüfbar) möglich. Die erhobenen Daten werden dabei nicht automatisch mit einem Dritten geteilt, wie es bspw. bei Google Analytics der Fall ist.
Zum Funktionsumfang von Matomo zählt unter anderem:
- Statistiken über Seitenaufrufe (anpassbar an Tageszeiten)
- Unique Visits bzw. das Zählen von Besuchern via IP-Adresse
- Referreranalyse
- Besucheranalyse (Land, Browser, Betriebssystem)
- Mandatenfähigkeit
- Diverse Optionen zur Verbesserung und Einhaltung des Datenschutzes
- Clients für Android und iOS
- […]
Technisch basiert Matomo auf PHP und nutzt eine MySQL-Datenbank (Alternativ MariaDB). Serverseitig kommt das Zend Framework, PEAR und Twig zum Einsatz. Mit den nachfolgenden Voraussetzungen kann Matomo (Stand Artikelveröffentlichung) auf einem Server gehostet werden:
- Webserver mit Apache, nginx, IIS etc.
- PHP-Version 5.5.9 oder aktueller
- MySQL Version 5.5 oder aktueller – Alternativ MariaDB ab Version 10
- Die PHP-Erweiterungen pdo und pdo_mysql
3. Verschiedene Tracking-Varianten
Die Besucherzählung bzw. das Tracking erfolgt bei Matomo via Cookies, JavaScript (via Tracking-API), Zählpixel oder Logfile-Analyse. Standardmäßig erfasst Matomo den Besucher mittels JavaScript und legt zusätzlich ein Cookie im Kontext des Browsers ab. Sowohl das Tracking via Cookies und/oder JavaScript wird zukünftig vermutlich die Einwilligung des Betroffenen erforderlich machen – so jedenfalls meine Einschätzung, wenn man aktuelle Gerichtsurteile, Empfehlungen von Datenschutzbehörden und Juristenblogs verfolgt. Grund genug um einen alternativen Weg zu wählen, der:
- keine Einwilligung mittels Consent- bzw. Cookie-Banner erforderlich macht
- sich dadurch von Google Analytics abhebt
- 100% aller Daten beim Seitenbetreiber zusammenfasst
- korrekt konfiguriert DSGVO- und TTDSG-konform ist
- und insgesamt höhere Anforderungen an Datenschutz und Sicherheit erfüllt
Die Variante, die diese Kriterien erfüllt, nennt sich Logfile-Analyse und wird von Matomo unterstützt. Diese ist im Gegensatz zum Tracking via JavaScript und Cookies, wie es bspw. bei Tools wie Google Analytics, Webtrekk, eTracker etc. erfolgt, kaum verbreitet.
Nachfolgend möchte ich die Vor- und Nachteile von zwei Matomo-Tracking-Varianten beleuchten, die eine Besuchererfassung ohne Cookies ermöglichen.
3.1 Variante 1: Ohne Cookies mit JavaScript-Fingerprinting
Sobald der Besucher eine Webseite besucht, die JavaScript-Code von Matomo einbindet, wird dieser Code nachgeladen und im Kontext der Webseite ausgeführt. Mittels (Canvas-)Fingerprinting ermittelt das JavaScript anschließend verschiedene Merkmale (bspw. Fensterauflösung, installierte Schriftarten, Betriebssystem, Sprache etc.) des Browsers und übermittelt diese an Matomo. Aus diesem Fingerprint errechnet Matomo anschließend eine Besucher-ID, die anschließend in einem Cookie hinterlegt wird und eine eindeutige Identifikation des Nutzers über die Laufzeit des Cookies zulässt.
Beim Tracking ohne Cookies entfällt diese Speichermöglichkeit und Matomo muss einen wiederkehrenden Besucher aufwendiger identifizieren. Dazu vergleicht Matomo den Fingerprint des Besuchers mit den zuvor erfassten Fingerprints – standardmäßig erfolgt dieser Abgleich allerdings nur 30 Minuten in die Vergangenheit. Angenommen ein bereits erfasster Besucher ruft die Webseite nach 31 Minuten erneut auf, bekommt er eine neue Besucher-ID und wird auch als neuer Besucher gewertet. Der Standardwert von 30 Minuten lässt sich innerhalb von Matomo anpassen – maximal ist ein Blick über 24 Stunden in die Vergangenheit möglich, dann wird der Fingerprint eines Besuchers neu berechnet (ab Matomo-Version 3.13.6). Dies hat natürlich Einfluss auf das Messergebnis, da das Fingerprinting im Gegensatz zur Variante mit Cookies eine Wiedererkennung nur über einen kurzen Zeitraum erlaubt.
Davon abgesehen haben beide Varianten (JavaScript + Cookies | nur JavaScript) grundsätzlich verstärkt Probleme bei der Erfassung und damit der Genauigkeit von Messergebnissen. Das ist erfreulich, da dies ein Indiz dafür ist, dass Nutzer immer häufiger auf Werbe- und Trackingblocker zurückgreifen, die eine (Besucher-)Erfassung verhindern. Keine Erfassung. Kein Messwert. Keine Prognose.
Nachfolgend eine Grafik, die den Ablauf eines Besuchs darstellt:
Nach dem Aufruf einer Webseite [1] wird der Besuch im (Access-)Logfile [2] des Webservers erfasst. Während des Aufrufs wird ebenfalls JavaScript von Matomo nachgeladen und ein Matomo-Cookie im Kontext des Browsers gesetzt – sofern dies nicht durch Add-Ons etc. unterbunden wird. Diverse Schutzvorkehrungen, die ein Nutzer nun getroffen hat, entscheiden nämlich darüber, wie genau bzw. ob ein Besuch von Matomo überhaupt erfasst wird. Nutzt ein Besucher bspw. einen JavaScript- bzw. Ad-Blocker [3] wie uBlock Origin, wird das Matomo-Skript unter Umständen erst gar nicht geladen und zur Ausführung gebracht. Der Besuch wird dann gar nicht erfasst. Verwendet der Besucher (zusätzlich) einen Cookie-Manager [3], der Cookies nach dem Schließen des Browsers wieder löscht, bekommt er beim nächsten Besuch eine neue Besucher-ID zugewiesen. Das hat zur Auswirkung, dass die Anzahl der eindeutigen Besucher steigt, während die Anzahl der wiederkehrenden Besucher sinkt. Ist Matomo datenschutzfreundlich konfiguriert, wird der Besuch bei gesetztem Do-Not-Track-Header [4] im Browser ebenfalls nicht erfasst. Das bedeutet: Je nachdem, welche Schutzvorkehrungen ein Besucher getroffen hat, werden Messergebnisse verfälscht oder der Besuch gar nicht erfasst. Zu den Maßnahmen zählen bspw.:
- Verwendung unterschiedlicher Geräte bzw. Browser (Drei-Browser-Konzept)
- Verweigern oder das regelmäßige Löschen von Cookies via Add-Ons und/oder Browser-Einstellungen
- Verwendung des privaten Surf-Modus
- Einsatz von Werbe- und Trackingblockern (auf DNS-Ebene oder via Browser-Add-On)
Mein Fazit zu dieser cookiefreien-Variante:
- Die Ungenauigkeit der Messergebnisse steigt weiter an. Insbesondere durch die zunehmende Verbreitung von Werbe- und Trackingblockern bzw. Cookie-Add-Ons dürften die Messergebnisse allerdings auch schon dann (stark) verfälscht sein, wenn Matomo zusätzlich Cookies setzen darf. Dazu ebenfalls interessant: When cookies are disabled by a visitor, how does it impact Matomo reports accuracy?
- Auch bei dieser Variante sehe ich eine Opt-In-Pflicht bzw. der Betroffene (Besucher) muss vor der Erfassung seine ausdrückliche, informierte, freiwillige und aktive Einwilligung abgeben.
3.2 Variante 2: Ohne Cookies mit Server-Logfiles (Logfile-Analyse)
Bei der Logfile-Analyse erfasst Matomo seine Daten nicht selbst, sondern greift auf die Datenbasis des Webservers zurück. Standardmäßig schreibt jeder Webserver (Apache, nginx, lighttpd, IIS) nämlich ein Logfile, in dem diverse Informationen zu einem Besuch abgelegt werden:
- Die Domain, die aufgerufen wird: www.kuketz-blog.de
- Die IP-Adresse des anfragenden Rechners: 37.49.18.157
- Datum und Uhrzeit des Zugriffs: Tag/Monat/Jahr:Uhrzeit
- Um welche Art von HTTP-Request es sich handelt: GET
- Die URL, die aufgerufen wird: /datenschutzhinweis/
- Den HTTP-Statuscode: 200
- Webseite, von der aus der Zugriff erfolgt (Referrer-URL): https://www.kuketz-security.de/
- Verwendeter Browser und ggf. das Betriebssystem Ihres Rechners (User-Agent):Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/X Firefox/X
Im Logfile eines nginx-Webservers wird ein Besuch bspw. wie folgt protokolliert:
www.kuketz-blog.de 37.49.18.157 - - [07/Jul/2020:09:43:06 +0200] "GET /kommentar-datenschutz-bei-microsoft-teams/ HTTP/2.0" 200 18036 "https://rufposten.de/blog/2020/05/17/datenschutz-bei-microsoft-teams/" "Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
Standardmäßig enthält ein solches Logfile alle Aufrufe der Webseite – dazu zählen auch Dokumente, Bilder, CSS- und JavaScript-Dateien etc. Das Verhalten lässt sich allerdings an die jeweiligen Bedürfnisse des Seitenbetreibers anpassen. So ist es bspw. möglich, das Webserver-Logging allein auf die Seitenaufrufe zu reduzieren und Meta- oder technische Daten wie Bilder, CSS-Dateien etc. nicht zu erfassen. Unbedingt notwendig ist ein solcher Eingriff in die Konfiguration des Webservers allerdings nicht, da Matomo im Auslieferungszustand sowieso nur Seiten bzw. Dokumente berücksichtigt und Bilder, CSS- und JavaScript-Dateien etc. anhand ihrer Dateiendung ausfiltert bzw. ignoriert.
Nachfolgend eine Grafik, die den Ablauf eines Besuchs darstellt:
Nachdem Aufruf einer Webseite [1] wird der Besuch im (Access-)Logfile [2] des Webservers erfasst. An dieser Stelle spielt es nun keine Rolle, ob ein Besucher Schutzmaßnahmen getroffen hat oder nicht, denn Matomo generiert die Ergebnisse aufgrund des Logfiles, das der Webserver schreibt. Dazu setzt Matomo ein Python-Skript ein, das direkt auf Dateisystemebene die Logdatei des Webservers ausliest [3] und die Ergebnisse anschließend in der Matomo-Datenbank [4] hinterlegt. Über das Matomo-Dashboard sind die Ergebnisse anschließend wie gewohnt abrufbar.
Da Matomo bei dieser Variante auf das Logfile des Webservers zugreift, ist ein Opt-Out (aber auch Opt-In) vom Tracking nicht möglich. Allerdings kann bereits der Webserver so konfiguriert werden, dass dieser Besuche nicht aufzeichnet bzw. protokolliert, wenn der Do-Not-Track-Header vom Browser des Betroffenen übermittelt wird. Der EFF bietet eine entsprechende Anleitung für Apache und nginx.
Hinweis
Weitere Informationen zur Logfile-Analyse sind auf der Matomo-Webseite zusammengefasst:Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
3.3 Vor- und Nachteile beider Varianten
Keine Frage, in der Praxis haben beide Varianten natürlich ihre Vor- und Nachteile. Die Verwendung von JavaScript-Tracking (+Cookies) hat gegenüber der Logfile-Analyse unter anderem folgende Vorteile:
- Das Tracking via JavaScript ist grundsätzlich sehr anpassbar und wird nur einmal pro Seite ausgeführt
- Die Erkennung von wiederkehrenden Besuchern funktioniert (deutlich) besser
- JavaScript-Tracking via Matomo ist vergleichsweise einfach einzurichten
- Ermöglicht auch fortgeschrittenere Anwendungsfälle wie die Verwendung genauerer Metriken für eindeutige Besucher und/oder die Aufzeichnung von Heatmaps, E-Commerce-Tracking und Formularanalysen
- Ausgehende Links können erfasst werden – also wohin Nutzer womöglich »abspringen«
Aber auch die Logfile-Analyse kann punkten:
- Die Protokolldateien bzw. das Logfile des Webservers ist bereits verfügbar bzw. Matomo kann einfach auf den vorhandenen Datensatz zurückgreifen und muss nicht via JavaScript in den Kontext einer Webseite eingebunden werden
- Suchmaschinen- und Spam-Bots lassen sich über das Logfile einfacher erkennen bzw. ausfiltern
- Das Logfile enthält auch Besucher-Informationen (bspw. zu Seitenabrufen etc.), wenn Nutzer Werbe- und Trackingblocker einsetzen – ein klarer Vorteil zu den anderen Varianten, da die Verbreitung dieser Add-Ons bzw. Anti-Tracking-Maßnahmen (auch in den Browsern) weiter ansteigen wird
Letztendlich muss man abwägen, mit welcher Variante die eigenen Ziele am besten erreicht werden können. Bei der Entscheidung sollte man Folgendes allerdings unbedingt bedenken: Vor dem Hintergrund, dass das EuGH-Urteil vom Oktober 2019 auch so interpretiert werden kann, dass der Besucher auch bei der Variante mit JavaScript-Fingerprinting (ohne Cookies) seine Einwilligung in das Tracking abgeben muss, liegt der Vorteil hier klar bei der Logfile-Analyse.
4. Konfiguration Logfile-Analyse
Aufgrund verschiedener Szenarien, Konfigurationen und individuellen Bedürfnissen kann ich im Nachfolgenden lediglich Rahmenbedingungen nennen, die den datenschutzfreundlichen Einsatz einer Logfile-Analyse mit Matomo ermöglichen. Folgende Anforderungen sollten erfüllt sein, bevor eine Konfiguration erfolgt:
- Installation von Matomo auf einem Server. Entweder parallel zum Webserver oder aufgrund von Sicherheitsgründen bzw. einer Trennung der Daten / Informationen auf einem eigenständigen Server.
- Damit das Python-Skript auf dem Server ausgeführt werden kann benötigt ihr Zugriff via SSH (oder einer Alternative) auf den Server
- Python ab der Version 2.6, damit das Skript zum Auslesen des Logfiles ausgeführt werden kann
- Ein oder mehrere Logfiles, die vom Matomo Python-Skript ausgelesen werden können
- Optional: Für die Erkennung von Ländern und Städten muss bei Matomo Geo-Location nachgerüstet werden
Hinweis
Die Matomo-Seite »How to use Log Analytics tool« erläutert den Installations- und Konfigurationsprozess ausführlich.Aufbauend auf diese Anforderungen sollten folgende Punkte umgesetzt werden:
- Beachtung des Do-Not-Track-Headers bereits auf Ebene des Webservers. Der EFF bietet eine entsprechende Anleitung für Apache und nginx
- Umsetzung einer IP-Anonymisierung (Apache und nginx), damit nicht die volle IP-Adresse des Besuchers erfasst wird
- Ausführliche Erläuterung des Trackings bzw. der Webanalyse in der Datenschutzerklärung
- Vollständiger Verbleib der Logfiles bzw. Matomo-Datenbank beim Webseitenbetreiber (keine Übermittlung bzw. Weitergabe an Dritte)
- Regelmäßige Löschung von historischen Datensätzen
Sofern die Logfile-Analyse in der beschriebenen Form umgesetzt wird, ist nach meinem Wissen keine Einwilligung in die Webanalyse notwendig und man kann sich den Cookie-Banner einfach »sparen«. Begründen lässt sich dies wie folgt:
- Der Webserver kürzt/verfremdet jede anfragende IP-Adresse vor der Speicherung in das Logfile. Damit ist die Datenbasis ausreichend anonymisiert und es sind keine Rückschlüsse auf einzelne Personen möglich.
- Matomo kann aus den Daten, die aus dem Logfile ausgelesen werden, keine Nutzerprofile erstellen. Dazu fehlt es schlichtweg an Identifikationsmerkmalen, die eine eindeutige Zuordnung möglich machen.
- Strittig bei der Logfile-Analyse dürfte die IP-Adresse und der User-Agent sein. Beide Informationen liegen implizit vor bzw. es ist kein Zugriff auf die Endeinrichtung notwendig. Im Sinne des § 25 TTDSG bedürfen die implizit erhaltenen Daten keines Zugriffs im technischen Sinne. Sie sind durch das TTDSG daher nicht besonders geschützt.
Insgesamt bedeutet das: Es ist kein Cookie- bzw. Consent-Banner erforderlich, der eine Einwilligung vom Nutzer einholt.
5. Alternativen zu Matomo
Matomo ist eine datenschutzfreundliche Alternative zu Google Analytics. Doch die Open-Source-Welt bietet noch weitere Alternativen, die je nach Anforderungen vielleicht eher zur eigenen Webseite / Projekt passen. Anbei eine kleine Auswahl:
- GoAccess: Erhebt die Daten ebenfalls aus dem Logfile des Webservers und gibt diese textbasiert direkt auf dem Terminal aus oder generiert eine HTML-Datei, die anschließend im Browser betrachtet werden kann. Bietet auch eine Real-Time-Analyse.
- AWStats: AWStats aggregiert die Daten ebenfalls aus dem Logfile des Webservers und generiert anschließend HTML-Berichte bzw. Statistiken.
- Open Web Analytics: Die dritte Alternative ist vom Funktionsumfang vergleichbar mit Matomo. Es basiert ebenfalls auf PHP und speichert die Datensätze in einer MySQL-Datenbank.
Grundsätzlich ist es empfehlenswert, Webanalyse-Tools auf eigenen Servern zu betreiben, die die Einhaltung des Datenschutzes (nachprüfbar) ermöglichen. Matomo und auch alle drei genannten Alternativen ermöglichen genau das und heben sich damit deutlich von Lösungen wie Google Analytics ab, bei dem die Analyse-Daten (zwangsweise) mit einem Dritten geteilt werden.
6. Fazit
Gemessen am Funktionsumfang konkurriert Matomo mit Google Analytics – im Gegensatz zu diesem ist es allerdings auch ohne aktive Einwilligung der Nutzer einsetzbar, sofern man als Betreiber die Logfile-Analyse verwendet. Wird das Tracking bei Matomo hingegen mit Cookies und/oder JavaScript-Fingerprinting betrieben, wird es notwendig sein, beim Betroffenen (dem Besucher einer Webseite) wiederum eine Einwilligung einzuholen. So jedenfalls meine Einschätzung, wenn man aktuelle Gerichtsurteile verfolgt.
Im Vergleich mit der JavaScript-Variante (+Cookies) bietet die Logfile-Analyse keine tiefergehenden Analysen. Punktet dafür mit einwilligungsfreiem Tracking – ein großer Pluspunkt, der gerade auch vor dem Hintergrund der steigenden Verbreitung von Werbe- und Trackingblockern die Entscheidung zugunsten dieser Variante beeinflussen könnte. Eines sollte aber klar sein: Aufwendige Kampagnen bzw. die Auswertung von Zielerreichungen etc. sind mit der Logfile-Analyse nicht realisierbar – dazu ist die Datenbasis einfach zu gering, die Matomo über das Logfile erfassen und auswerten kann.
Für Betreiber, die eine einwilligungsfreie, datenschutzfreundliche Variante suchen und nur einfache statistische Auswertungen vornehmen, könnte die Logfile-Analyse aber genau die passende Lösung sein.
In Deutschland liegt der Marktanteil von Matomo bei etwa 14,6 Prozent. Im Hinblick auf aktuelle Gerichtsurteile und die Möglichkeit des einwilligungsfreien Trackings via Logfile-Analyse hoffe ich auf eine (deutliche) Steigerung der Verbreitung. *fingers crossed*
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Das kranke WWW: Stop using Google Web-Services
Wer erlaubt Analysetracking in Deutschland und Europa – das TTDSG Teil2
DB Navigator: Datenschutz fällt heute aus – App-Check Teil1
Firefox: First Party Isolation – Firefox-Kompendium Teil4
Rechtswidrige Einwilligungs-Abfragen erkennen und dagegen vorgehen
16 Ergänzungen zu “Matomo: Einwilligungsfreies Tracking mit der Logfile-Analyse”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Hinweis an jene, die einen beliebigen Ad-Blocker in Verbindung mit der „EasyPrivacy“Liste verwenden;
Einige Bilder des Beitrags werden nicht angezeigt, da sie von einer anderen WWW-Domäne (techn. Bez. „Drittpartei“), nämlich kuketz.de eingebunden werden, und die besagte Filterliste unglücklicherweise alle sog. „3rd-Party Ressourcen“ in Verzeichnissen mit dem Namen ../matomo/.. pauschal herausfiltert.
Man kann ruhigen Gewissens die Domäne kuketz-blog.de ganz einfach zu den Ausnahmeregeln hinzufügen, da hier ohnehin keine Werbung eingeblendet wird.
Bei den gefilterten Bildern handelt es sich um:
https://media.kuketz.de/blog/artikel/2020/matomo/matomo-logfile.png
https://media.kuketz.de/blog/artikel/2020/matomo/matomo-cookies-javascript.png
https://media.kuketz.de/blog/artikel/2020/matomo/matomo.png
Die besagte Filterregel der EasyPrivacy Liste ist folgendermaßen aufgebaut:
https://i.postimg.cc/VkfXL8Cs/screenshot.png
Ein Kollege wies mich auf diesen Umstand hin, als er die Bilder im Beitrag nicht sehen konnte, auf die ich im Gespräch verwiesen habe, ein kurzer Selbsttest mit aktiviertem Blocker brachte dann die Gewissheit.
Ansonsten wie immer ein sehr interessanter und aufschlussreicher Artikel.
Vielen Dank!
Hallo Herr Kuketz, schöner Artikel.
Die Einwilligungspflicht gilt nach Art. 5.3 der ePrivacyRL für den Zugriff auf und die Verarbeitung von Endgeräteinformationen, gleich welche das sind. Also Fingerprinting, Cookies, aber auch IP Adressen, sofern nicht die Ausnahmen greifen.
Ausnahmen nach Art. 5.3 der ePrivacyRL sind nur
1) „Durchführung der Übertragung von Nachrichten alleiniger Zweck“ und
2) „unbedingt erforderlich für den vom Nutzer aktiv angeforderten Dienst“.
Details zur rechtlichen Seite gern mal am Telefon.
Viele Grüße
Peter Hense
Das sehe ich anders. Siehe dazu auch Ausführungen unter Ziffer 4.
Für die Anwendbarkeit von Art. 5.3 ePrivacyRL spielt der Personenbezug gar keine Rolle. Der Schutz der Richtlinie erstreckt sich auf alle Endgeräteinformationen, gleich ob diese personenbezogen sind oder nicht. Selbst dann wäre eine um das letzte Oktett gekürzte IP wohl nur eine Pseudonymisierung, es blieben also personenbezogene Daten (so LG Frankfurt/Main, 3-10 O 86/12 – Piwik).
Unter Art. 5.3 der ePrivacyRL ist jeder Identifikator des Endgeräts geschützt, ab dem Moment, in dem er erhoben wird. Das betrifft auch IP-Adressen, ganz egal, ob diese später gekürzt werden. Die IP kann ohne informierte Einwilligung verarbeitet werden, wenn ihre Verarbeitung unter die Ausnahmen in Art. 5.3 S. 2 der ePrivacyRL fällt: 1) Durchführung der Übertragung einer Nachricht oder 2) unbedingt erforderlich für einen vom Nutzer aktiv angefordertern Dienst. Webanalyse fällt jedenfalls im Regelfall nicht darunter.
Natürlich gibt es im Themenfeld ePrivacyRL, das jahrelang brach lag und plötzlich neu entdeckt wird, noch Details, über die Juristen streiten. Das betrifft insbesondere die Frage, unter welchen Regelungen die nachgelagerte Verarbeitung von (personenbezogenen) Endgeräteinformationen unterliegt. Das EDPB ist hier mit guten Arguementen der Auffassung, dass jede nachgelagerte Verarbeitung jedenfalls nicht den Schutz der Richtlinie und damit das Einwilligungserfordernis aushebeln darf. Wenn vorhandene (Logfiles etc.) personenbezogene Daten zu anderen Zwecken genutzt werden sollen, wäre auch immer Art. 6.4 DSGVO zu beachten.
Viele Grüße, Peter Hense
Nach meiner Auffassung ist das Auslegungssache. Gewissheit werden wir erst durch Urteile erlangen. Ich persönlich bleibe jedenfalls bei meiner Einschätzung, dass bei der von mir beschriebenen Variante keine Einwilligung notwendig ist.
Begründen kann ich das wie folgt: Strittig bei der Logfile-Analyse dürfte die IP-Adresse und der User-Agent sein. Beide Informationen liegen implizit vor bzw. es ist kein Zugriff auf das Endgerät notwendig. Im Sinne des § 25 TTDSG bedürfen die implizit erhaltenen Daten keines Zugriffs im technischen Sinne. Sie sind durch das TTDSG daher nicht besonders geschützt.
Auf Daten, die implizit vorliegen, wie etwa die IP-Adresse oder der User-Agent, muss kein Zugriff erfolgen. Sie werden also nicht vom § 25 TTDSG erfasst und sind somit höchstwahrscheinlich unkritisch. Deren Weiterverarbeitung obliegt den Regeln der DSGVO, nicht des § 25 TTDSG.
Ich finde es schade, dass anstelle den datenschutzfreundlicheren Cookies (selbst zu löschen) nun Fingerprinting eingesetzt werden soll.
Dann lieber konsequent art 5 abs 3 privacyrl anwenden und auch fingerprinting als nicht unbedingt erforderliche „Informationen, die bereits im Endgerät eines Teilnehmers oder Nutzers gespeichert sind„> sehen die nur mit Einwilligung gehen.
Es soll kein Fingerprinting eingesetzt werden. Vielleicht ist es sinnvoll, wenn du den Beitrag nochmal in aller Ruhe liest.
Ist es nicht schon grundsätzlich sehr fragwürdig weshalb ein Browser heutzutage standardmässig und freiwillig Daten wie, Name des Browser und OS, Version des Browsers und OS, die Bildschirmauflösung, die Farbtiefe und mit Hilfe von JS dann eben auch noch solche Dinge wie installierte Fonts, die Zeitzone, die lokalen Spracheinstellungen und sogar installierte Plugins einfach mal so herausgibt, ohne irgendeinen Hinweis dazu oder eine vorherige Einwilligung des Benutzers zu haben?
Man stelle sich ein Telefon vor und bei jeder Benutzung, jedem Anruf würden Daten wie, Modell und Farbe des Telefons, Hersteller, Gerätealter, Größe der Wohnung, Adresse und die Wohnungsausstattung übermittelt.
Im Grunde existiert diese Art der „freiwilligen“ Datenübermittlung doch nur, weil man das damals, in den Anfangszeiten des Webs, als Debug-Infos gebraucht hat und es einfach machbar war. Heutzutage könnte man sicherlich auf eine Vielzahl dieser „datenschutzrechtlichen Altlasten“ verzichten. Aber es scheint dahingehend keinerlei Diskussion stattzufinden und/oder nirgendwo ist ein Wille zur Änderung dieses Browserverhaltens zu sehen. Ganz im Gegenteil!.
Gebe ich dir recht. Es würde anders gehen.
Meinst Du es wäre klug bzw. probehalber machbar bei den Browser-Herstellern (Google, Mozilla, Microsoft, Apple, Opera etc.) dazu einige Bug-Reports aufzumachen. Begründung: Völlig unnötige Privacy-Leaks, Erhöhung der Angriffsfläche durch Identifizierbarkeit, Keine technische Notwendigkeit. Alternativ: Die schon vorhandenen Funktionalitäten auf „Optional“ stellen und den Default-Wert natürlich auf „aus“).
Glaubst Du sie könnten mit irgendeinem, von irgendeinem Konsortium verabschiedeten, technischen Dokument / Spezifikation dagegenhalten, wo diese Datenübermittlung als „must-have“ festgeschrieben steht? Mir ist da in dieser Hinsicht jedenfalls nichts bekannt. Kennst Du vielleicht etwas passendes? Wäre doch ganz nett, wenn man die großen Firmen da mal mit einigen Bug-Reports triggern könnte, oder?
Dazu müsste man sich direkt mit dem W3C in eine offene Diskussion begeben. Leider ist diese Institution mittlerweile durch den Lobbyismus unterwandert worden. Es sitzten nun auch große Verbände mit eigenen Wirtschaftsinteressen am runden Tisch, die den Verlauf solcher Entwicklungen maßgeblich mitgestalten.
Da wird man nicht kurzerhand solche von dir genannten Aspekte im Namen der Privatsphäre bzw. der Informationellen Selbstbestimmung abschaffen. Höchstens hysterisches Gelächter aus dem besagten Publikum und die eine oder andere Europalette geschenkter Aluhütte. Hast du es nicht mitbekommen? Man ist ein paranoider Spinner wenn man nicht in Asozialen Medien á la Facebook, Instagram etc. wohnt.
Ich erinnere mich noch gut als 2017 das W3C den DRM Standard „Encrypted Media Extensions“ eingeführt hatte, woraufhin die Electronic Frontier Foundation noch am selben Tag aus Protest gegen den stetigen Kontrollverlust bzw. die Korrumpierung freier Standards durch Wirtschaftsinteressen Dritter aus dem W3C austrat.
Solche Entwicklungen in eine positive Richtung im Interesse des Verbrauchers sind sehr langwierig und beschwerlich. Und solange sich die breite Masse der Nutzerschaft nicht aktiv für Privatsphäre und einen vernünftigen Umgang mit den eigenen Daten entscheidet, sieht es für die Zukunft eher düster aus. Da bleibt nur die Aufklärungsarbeit, während man sich selbst weiterhin mit unzähligen Browsererweiterungen geißelt, die diese Probleme versuchen anzusprechen.
In den Anfangsjahren des Web waren die Header-Informationen ein Tipp an den Server, um Seiten zu bekommen, die der Browser auch halbwegs sinnvoll bzw. fehlerfrei anzeigen kann. Außerdem Eigenwerbung (Marktanteil) in Sachen Browser-War und Web-Statistik, für welche Browser und Auflösungen das HTML optimiert werden sollte. Das Layout wurde ja oft mit Tabellen und Frames gestaltet, , und CSS gab es noch nicht, dafür HTML-Browser auf Handhelds mit z. B. 320×320 px Auflösung. An Datenschutz und Usertracking dachte damals niemand, und die NSA kannte auch niemand.
Dann kamen Dotcom, DSL und 9/11, und das Web verlor seine Unschuld. Immer mehr Unternehmen und Hacker überschritten aus Eigennutz immer mehr Grenzen und zwangen die Anwender immer mehr, JavaScript zuzulassen, und machten es immer unmöglicher, den Schalter zum Deaktivieren von JavaScript zu finden … Inzwischen sind sogar die Seiten des Bundestags nicht mehr ohne JavaScript nutzbar, was ich für klar rechtswidrig halte.
Ich warte schon lange darauf, dass die Verunmöglichung für den normalen Anwender, die genannten Header-Daten abzustellen oder per J/S unbemerkt Zusatzinformationen zu „erheben“ (vulgo: stehlen) und an den Server zu senden, nach DSGVO untersucht und für rechtswidrig erklärt wird. Dazu braucht es nicht das Placet des W3C. Einem Urteil des EuGH müssen sich auch die Browserhersteller beugen. Also: wer klagt?
Nehmen wir mal folgendes an: Der Webserver beachtet den Do-Not-Track-Header des Benutzer-Browsers. Das Tracking (Cookie & Javascript) wird je nach Einstellung des Benutzer-Browsers (automatisch) entweder komplett ein- oder ausgeschaltet. Frage: Reicht ein Banner mit Link auf die Datenschutzerklärung aus oder muss zusätzlich ein Opt-In Button für die Cookies & Javascript auf der Webseite platziert werden?
Besten Dank für die Antwort.
Ich gehe von einem Opt-In aus.
Hallo!
Danke für die guten Artikel!
Soweit ich es richtig verstanden habe, gäbe es auch noch die Option, Matomo „im Hintergrund“ z.B. über ein CMS mit Daten zu füttern. D.h. das CMS würde beim Aufruf von Seiten Daten an Matomo senden (vgl. https://developer.matomo.org/guides/tracking-api-clients#client-libraries-for-apps-or-server-side-tracking bwz. https://developer.matomo.org/api-reference/PHP-Matomo-Tracker).
Wäre ggf. noch eine Erwähnung im Artikel wert.
Trackingfreie Analyse gibt es seit 1997 und nennt sich Webalizer … ist bei zahlreichen Servern noch vorinstalliert … Aber dann kam Google und machte dasselbe (und noch viel mehr) klickibunti und betörte die Welt … Bezeichnend und lehrhaft, wie Google Analytics auch hierzulande strohfeuerartig Verbreitung fand, obwohl von Anfang an rechtswidrig (BDSG). Bei genug Bequemlichkeit und eigenen Vorteilen ist auch vielen deutschen Webadmins das Gesetz s…egal.
Ungenehmigtes Tracking muss vor allem auf (straf-)rechtlichem Weg verhindert und bekämpft werden, technisch geht es nicht, da alles umgangen wird, aktuell z. B. durch parametrisierte Elemente (img, css usw.) Das ist dasselbe wie bei Spam, Hacking und Datendiebstahl.