Bereits die Bezeichnung „Cookie Banner“ stört mich aufgrund ihrer Unvollständigkeit. Cookies machen eigentlich nur einen Teil dessen aus, was den Schutz der Privatsphäre tangiert. Eine umfassende Lösung zum Schutz der Privatshäre macht folglich weit mehr, als auf Cookies hinzuweisen und diese zu blocken, bis der Besucher zugestimmt hat (und sie dauerhaft zu blocken, wenn er ablehnt). Die Betonung liegt auf „umfassend“.

Es geht längst nicht nur um Cookies

Letztes Wochenende stieß ich auf einen neuen Player im deutsprachigen Cookie-Banner-Markt. Voll automatisch sollte es funktionieren, anmelden, Website scannen lassen, einrichten, zurücklehnen. Ein paar Referenzprojekte waren angeführt. Was bei der Untersuchung allerdings herauskam: Keines der von mir untersuchten Referenz-Projekte, nichtmal die Website des Anbieters war datenschutzkonform. Google Fonts (zum Beispiel) kamen ungebremst durch. – Der Inhalt eines iFrames schaute ungehemmt aus seinem Container, als gehörte er zur Website. Man könnte ja nun sagen, das Tool hält was er verspricht, nämlich Cookies zu bannen, denen nicht zugestimmt wurde. – Aber datenschutzkonform ist eine Website damit noch lange nicht.

Möge man mir widersprechen, doch wer installiert sich bitte ein Cookie Banner, von dem er dann NICHT erwartet, dass es sich um alles kümmert, was seine Website ansonsten davon abhielte, datenschutzkonform zu sein? – Natürlich tun das die meisten…

Nicht alle Cookies sind zustimmungspflichtig

Fangen wir doch damit an, dass man erstmal unterscheiden muss zwischen Cookies die der Zustimmung bedürfen, und solchen, die es nicht tun.

Es gibt so genannte essentielle Cookies, solche, ohne die eine Website ihren Zweck nicht erfüllen kann. Ein Cookie-Banner erfüllt seinen Zweck auch nur, wenn es ein essentielles (und nicht zustimmungspflichtiges) Cookie setzt, das sich die Auswahl des Nutzers merkt. Dieses Cookie bleibt meist mehrere Monate bis zu einem Jahr auf dem Rechner, sodass die Website beim nächsten Besuch immer noch die getroffene Auswahl des Besucher (an)erkennt.

Wer in einem Webshop seinen Warenkorb füllt, geht davon aus, dass der sich seinen Inhalt merkt. Auch das wird (häufig) über Cookies gelöst, und ist damit mit einer essentiellen Funktionalität verbunden. Die Lebensdauer ist begrenzt, d.h. wer seinen Warenkorb füllt, und ein paar Tage später weiter einkaufen will, nachdem der Browser geschlossen war, darf wieder von vorne anfangen.

Wer selbst eine WordPress-Website betreibt, muss sich im Dashboard anmelden. Auch dafür, den Zugang zum Dashboard für einen User offen zu halten, sind Cookies erforderlich und legitim. Üblicherweise „merkt“ sich WordPress die Anmeldung bis zu zwei Wochen lang. Besucher hingegen müssen sich nicht anmelden, brauchen und bekommen daher von einer einfachen WordPress-Installation keine Cookies.

Auf einer einfachen WordPress-Website ohne Shop und ohne die Loginseite zu betreten sind keine Cookies erforderlich. Folglich braucht es auch kein Cookie-Banner, jedenfalls nicht wegen der Cookies…

Funktions-Cookies von Plugins

Nach der Installation eines Plugins sollte geprüft werden, ob dieses Cookies verwendet. Was mit Marketing zu tun hat, könnte betroffen sein (z.B. Popup-Plugins, die Besucher gleich beim Eintritt mit Newsletterangeboten nerven). Ein solches Plugin hatte mich nach irgendeinem Update mit einem Cookie überrascht, das – zumindest für den angewandten Zweck – vollkommen überflüssig war.

Auch Firewall-Plugins könnten Cookies setzen (Achtung auch bei den Einstellungen, wenn es darum geht, Userdaten zu teilen, um böse IP-Adressen zu identifizieren). Über die Notwendigkeit des Einsatzes solcher Plugins mag man geteilter Meinung sein, und auch ob es nötig / möglich ist, die Cookies zu blocken (ein Popup, das ein Cookie braucht, um stillzuhalten wäre bei fehlender Zustimmung eine Lesehürde). – Nicht jede Firewall setzt Cookies. Seit Shield Security damit angefangen hat, Rechner von Usern mit „NoBot-Cookies“ zu markieren, verwende ich eine andere Lösung.

Plugins zur Statistik-Erfassung sind naturgemäß auch gerne Cookie-Setzer, und erfassen womöglich IP-Adressen der Besucher gleich mit. IP-Adressen gehören allerdings zu den „persönlichen Daten“, und diese dürfen nicht einfach so gespeichert, noch weitergegeben werden. Beim Divi Builder stieß ich hingegen bereits vor ein paar Jahren auf hinterlegte Daten im Local Storage, was dazu führte, dass eine programmierte Erweiterung nicht wie erwartet funktionierte. Denn gegen das, was dort hinterlegt ist, kann auch das Löschen des Caches nichts ausrichten.

Cookies / Local- oder Session Storage

Nicht alles, was einem Websites auf den Rechner pflantschen, ist technisch gesehen also tatsächlich ein Cookie. Im Zusammenhang mit Javascript werden Benutzerdaten gerne auch als Local-Storage (ohne definiertes Ende) oder Session Storage (für die Dauer einer Sitzung) abgelegt. Dabei kann ein Browser bis zu mehreren MB-Daten in einem Datensatz speichern.

Die User-Daten werden nicht mehr wie Cookies mit jedem Seitenaufruf auf den Server übertragen, sondern vom Browser des Benutzers gespeichert. Local Storage kann, genauso wie Cookies, den Kontext über mehrere Fenster und mithin unbegrenzt lange Zeit aufrecht erhalten.

DSGVO-technisch besteht kein Unterschied zwischen Cookies und Local Storage, d.h. was für Cookies gilt, betrifft auch den Local Storage. Man darf hier nicht einfach bei jedem ungefragt Daten hinterlegen.

Die Website macht weder das eine oder das andere, also könnte dann doch auf ein Cookie-Banner verzichtet werden? – Die Prüfung geht weiter…

Nur lokale Speichereinheiten zu blockieren genügt nicht

Sich zum Schutz der Privatshäre rein auf die Beachtung von Cookies und Local Storage zu beschränken ist in vielen Fällen allerdings unzureichend. Offenbar ist das nicht mal allen Anbietern von Cookie-Bannern bewusst. Dass nicht alle Entwickler von GDPR-Tools eine Zusammenarbeit mit Anwälten oder Datenschutzexperten pflegen, finde ich sowieso gewagt. Schließlich sind Entwickler keine Rechtsexperten (genauso wenig wie ich).

Wer auf seiner Website Fremdinhalte einbindet (dazu gehört alles, was nicht auf dem eigenen Webserver liegt, angefangen bei – wenn auch selbst hochgeladenen – YouTube-Videos über Google, aber auch OpenStreetMap, irgendwelche Inhalte fremder Websites in iFrames bis hin zu Google Fonts), gibt damit automatisch die IP-Adresse seines Besuchers an den fremden Server weiter. Die IP-Adresse ist jedoch ein persönliches Datum. Wer das ohne Zustimmung weitergibt, verletzt folgerichtig also bereits die Privatsphäre seines Besuchers. Und es hat erstmal nichts mit Cookies zu tun (je nach Anbieter dann schon, z.B. hinterlässt ein eingebundene YouTube eine ganze Liste davon auf dem Rechner des Besuchers, selbst wenn er nie direkt bei YouTube war).

Fremdinhalte erst nach Zustimmung laden

Klingt einfach, kann sich allerdings zu einer (oder mehreren) enormen technischen Herausforderung auswachsen.

Selbst wenn eine Website keine zustimmungspflichtigen Datensätze auf den Besucherrechnern speichert, ist sie also nicht automatisch datenschutzkonform. Auch wer auf Google Analytics verzichtet, und stattdessen auf (fremd gehostetes) Matomo setzt, braucht dafür eine Einwilligung. Die Google Map Alternative OpenStreetMap ruft zumindest Landkartenbilder von fremden Servern auf, was (meines Wissens) ebenfalls nicht mehr datenschutzkonform ist, wenn man das ohne Einwilligung macht.

Und dann gibt es auch noch, was Themes und Plugins möglicherweise für die Darstellung des gewählten Layouts laden. Jede Website ist ein wenig anders, und nicht alle Entwickler halten sich strikt an die Normen, sodass es keine Universallösung geben kann, die einem alles, mal so auf Mausklick, einfach abnimmt.

Wer sich also den Aufwand sparen will, hinterher auf seiner Website Maßnahmen ergreifen zu müssen, die blockieren was zustimmungspflichtig ist, so lange, bis die Zustimmung (nachweislich) gegeben ist, sollte bereits bei der Konzeption seiner Website genau abwägen, welche Komponenten er verwendet.

Wenn Revolution Slider unbedingt Material Icons von Google Servern laden will, was selbst einem Google Font Blocker gerne mal durch die Lappen geht, sollte über eine Alternative wie Smartslider 3 nachdenken. Dem kann man von Vornherein sagen, dass er keine Google Fonts laden soll. Das ist nur ein Beispiel dafür, dass es (fast) immer Alternativen gibt, die einem dabei unterstützen, die Privatsphäre seiner Besucher zu wahren.

Wenn alles ausgeschlossen werden kann, weder unnötige Cookies, Local Storage noch Fremdinhalte (Schriften, iFrames, YouTube oder Videos anderer Plattformen etc.) auf einer Website vorkommen, dann, ja nur dann, kann man ruhigen Gewissens auf den Einsatz eines Cookie- und Inhaltsblocker-Banners verzichten (ein Hinweis im Footer wäre vielleicht trotzdem gut, nur um Verunsicherungen auszuschließen). Da Websites allerdings regelmäßig upgedated werden, sollte dennoch immer mal wieder überprüft werden, ob die Privatsphäre der Nutzer (weiterhin) unberührt geblieben ist.