Real Cookie Banner: Wie das Opt-in Cookie Banner für WordPress entstand
Anfang 2020 gründeten mein Geschäftspartner Matze ich die devowl.io GmbH. In dieser wollten wir nicht nur sein bisheriges WordPress-Plugin Portfolio weiter entwickeln, sondern auch neue hochwertige WordPress-Plugins umsetzen. Der Plan war 2020 eine Vielzahl kleiner Plugins zu entwickeln, doch bereits im Januar sollte etwas geschehen, das unser Jahr prägte.
Zu jedem (digitalen) Unternehmen gehört heutzutage eine Website. Wenn dieses Unternehmen auch noch Software zum Bau von Websites vertreibt, ist eine gute Präsentation im Internet unabdingbar. Und da wir das wilder Western des Internets zunehmend hinter uns gelassen haben, gehört dazu auch Datenschutzbestimmungen einzuhalten. Ich höre schon dein Gähnen vor deinem Monitor, aber das gehört mittlerweile zu unser aller Alltag dazu.
Schau dir Real Cookie Banner an und erfahre, wie einfach es sein kann DSGVO (GDPR) und ePrivacy Richtlinie (EU Cookie Law) konforme Opt-in Cookie-Einwilligungen einzuholen. Finde Cookies und trage alle rechtlichen Informationen in deinen Cookie Banner ein. Mehr als nur ein Cookie-Hinweis!
Die Suche nach dem perfekten Cookie Banner
Konkret gehört dazu auch eine Entscheidung des EuGH vom 01.10.2019 (Rechtssache C-673/17). In diesem stellte er fest, dass auch in Deutschland diese nervigen Opt-in Cookie Banner oder Cookie Dialoge verpflichten sind, wenn man sogenannte nicht essenzielle Cookies einsetzen möchte. Das bestätigte im Mai 2020 der BGH (Az. I ZR 7/16 – Cookie-Einwilligung II) endgültig. Ausreden gälten seither nicht mehr. Auch, wenn der Deutsche Gesetzgeber die ePrivacy-Richtlinie (Richtlinie 2002/58/EG) Art. 5 von der EU weiterhin nicht vollständig in deutsches Recht umgesetzt hat.
Viel Rechtsblala, für eine einfache Aussage: Ein Cookie Banner musste her! Für WordPress, da wir als Hersteller von WordPress-Plugins natürlich auch unsere eigene Website mit WordPress bauen. Unter den ca. 55.000 Plugins für WordPress gibt es auch 17 Cookie Banner Plugins, die infrage kamen. Wir testeten alle und stellten recht schnell fest, dass nur sieben WordPress-Plugins – aus unserem Laien Rechtsverständnis heraus betrachtet – die Vorgaben eines Opt-in Cookie Banners aus der ePrivacy-Richtlinie erfüllten. Zwei dieser Plugins kamen für uns nicht infrage, da sie eigentlich nur ein Script aus einer Cloud-Lösung in die Website einbanden und wir solche Abhängigkeiten auf unserer Website vermeiden wollen – und weil das ironischerweise weitere Datenschutzfragen aufwirft. Von den fünf verbleibenden Cookie Bannern war aber nur ein einziges so flexibel anpassbar, dass es wir es vollständig in dem Design unserer Website gestalten konnten: Borlabs Cookie.
Die Geschichte könnte an dieser Stelle zu Ende sein. Könnte sie, hätte ich nicht mit Borlabs Cookie über rund einen ganzen Arbeitstag damit verbracht das Plugin korrekt einzurichten. Dabei klickte ich nicht nur gefühlt 500-mal die F5 Taste meiner armen Tastatur. Sie hatte einen harten Tag, da mir Borlabs Cookie keine Live-Vorschau der Designänderung bot. Außerdem fand ich es frustrierend nur zwei Handvoll Cookie-Vorlagen für Dienste wie Google Analytics von dem Plugin zu erhalten – wobei diese Cookie-Vorlagen für tausende Websites benötigt werden würde. Nicht besser wurde es, als ich feststellen musste, dass z.B. in der Google Tag Manager Vorlage nicht die Cookies dieses Services angegeben waren, sondern die von Google Analytics. Und ein Feature namens Script-Blocker verstand ich als Softwareentwickler, der behaupten möchte sich in dem WordPress Ökosystem etwas auszukennen, erst nach einem ca. acht minütigen Video. Die Benutzererfahrung war einfach frustrierend, obwohl es auch laut befreundenden Bloggern die beste Lösung am Markt gewesen sei.
Das ist normalerweise der Zeitpunkt an dem ich meinen Gmail Client öffne, und eine mehrseitige E-Mail mit konstruktivem Feedback inklusive Lösungsvorschläge versende. So eine E-Mail, wie ich sie gerne in meinem Postfach finden wollen würde und woraus sich eine potenzielle Kooperation ergeben könnte. Nicht aber in diesem Fall. Die Analyse des Plugin-Codes zeigte, dass unsere Arbeitsweise und die Arbeitsweise des Plugin-Entwicklers sich stark unterscheiden. Vermutlich kommen wir schlicht aus einem anderen Teil der Softwareentwicklung mit viel mehr Automatisierung. Zudem fand ich zufällig Aussagen wie folgende von dem Entwickler im Internet, welche mir wenig Hoffnung auf einen konstruktiven Dialog machen, wenn ich eine Latte Kritik an seinem Produkt äußern würde (auch wenn wir später eine Vielzahl freundlicher Posts fanden):
Frage eines Borlabs Cookie Nutzers auf in einer Facebook-Gruppe zu WordPress:
„[…] ich hab mir gerade Borlabs geholt…. [wie] finde ich am besten heraus, welche Cookies eingesetzt werden? 🧐“
Antwort von Benjamin (Entwickler und Inhaber von Borlabs Cookie):
„Ist ja nicht so, dass wir das unter Top-Artikel auf unserer Website verlinken […]“
Quelle: „WordPress & SEO“ Facebook-Gruppe vom 07.11.2019
Keine Lösung ist keine Lösung
So standen wir nun mit einer WordPress Website und einer rechtlichen Vorgabe da, die wir selbst mit dem besten Cookie Banner Plugin für das WordPress Ökosystem nur mit Einschränkungen und Bedingungen umsetzen konnten. Eine Google Suche nach WordPress Websites, die das benannte Cookie Banner Plugin nutzen, zeigt erschrecken oft, dass das Plugin nicht oder nur unzureichend von den Website-Betreibern eingerichtet werden konnte. In einer Stichprobe von 100 Websites, die Borlabs Cookie verwendeten, konnten wir in einer Kurzanalyse feststellen, dass rund die Hälfte der Websites das Plugin nicht, unzureichend oder im Übereifer schlicht falsch eingerichtet haben. Sie begehen damit täglich potenziell Datenschutzverstöße.
Es ging scheinbar also nicht nur mir so, dass ich die beste Lösung als zu komplex, nicht benutzerfreundlich oder schlicht für die Anforderungen unvollständig empfunden wurde. Gleichzeitig gibt es mehrere Millionen Websites in der EU, die sich heute (oder je nach Land in wenigen Jahren) damit auseinandersetzen müssen, wie sie Cookies noch rechtskonform setzen. Und rund ein Drittel dieser Websites ist mit WordPress gebaut.
Was macht ein Softwareentwickler also, wenn er keine zufriedenstellende Lösung findet? Genau, er nimmt die Sache selbst in die Hand (insbesondere, wenn es ein Marktpotenzial zu geben scheint)!
Wir entwickelten unser eigenes Cookie Banner Plugin
Anfang Mai schrieb ich ein erstes grobes Konzept für ein Cookie Banner Plugin, dass alle von mir bekannten und in der Zwischenzeit recherchierten Anforderungen beinhaltete. Auf der Basis des Konzeptes formulierten wir Annahmen, wo Probleme für eine Vielzahl von Nutzer liegen könnten. Um diese Annahmen zu validieren, setzte ich eine Umfrage auf, welche ich dankenswerterweise eine Vielzahl von deutschsprachigen Facebook-Gruppen zum Thema WordPress posten durfte. Insgesamt 66 Teilnehmer gaben uns interessante Einblicke, wie sie aktuelle Cookie Banner für WordPress wahrnehmen. Besonders interessant war, dass die gefühlte Sicherheit und das gefühlt Wissen über die Rechtslage hoch war. Zugleich zeigte die Auswertung von Fragen, die das Wissen der Teilnehmer testete und einen Blick, soweit bekannt, auf deren Websites, dass die Konfiguration bestehender Opt-in Cookie Banner häufig nicht den rechtlichen Vorgaben entsprachen. Diese und weitere Erkenntnisse halfen uns dabei den Fokus für das Produktkonzept zu schärfen. Zudem beschäftigte ich mich intensive mit den Rechtsgrundlagen und durchstöberte nicht nur eine Vielzahl an Rechtsanwalt Blogs, sondern Gesetzestexte wurden zu dieser Zeit zu meiner Abendlektüre.
Was uns zu diesem Zeitpunkt noch nicht bekannt war: Das eigentliche Abenteuer sollte erst während der Entwicklung der Software kommen. Matze fing bereits an Real Cookie Banner zu entwickeln. Wir versuchten die besten Ansätze bestehender Plugins zu vereinen und eigene Konzepte für eine einfachere Handhabung umzusetzen. Dabei liefern wir oft – sehr oft – gegen Wände. Wir lernten nämlich nicht nur aufseiten der rechtlichen Anforderungen, dass alle bisher vorhandenen Cookie Banner Plugins für WordPress viele rechtliche Vorgaben nicht bedacht oder nicht vollständig umgesetzt haben. Teils konzipierten und bauten wir in eine Richtung, um wenige Tage später zu lernen, dass dies kein Ansatz sei, mit dem alle Anforderungen des Gesetzgebers erfüllt werden konnten. Genauso erging es uns auf der technischen Seite. Ein Cookie ist nämlich nicht nur eine einfache Textdatei, wie es häufig dargestellt wird. Viel mehr gibt diverse Wege, wie ein HTTP-Cookie gesetzt werden kann. Und mindestens genauso viele, wie er gelöscht oder eben nicht wieder gelöscht werden kann. Zudem gibt es Cookie ähnliche Datenstrukturen, welche der Gesetzgeber in seinen Vorschriften auch erfasst werden, wobei deren technische Handhabung teils deutlich anders als bei HTTP-Cookies sind. Und wie verhindert man eigentlich am besten, dass ein Cookie vor einer Einwilligung gesetzt wird? Setzt jeder Browser Cookies gleich oder gibt es ein anderes Verhalten pro Browser? Und wie lässt sich das Cookie Banner perfekt vorladen, ohne die Website unnötig zu verlangsamen? Diese und weitere Fragen beschäftigten uns nicht nur im Mai, Juni und Juli. Auch im August und September sollten diese Fragen einen Großteil unserer Zeit beanspruchen.
Mitte September, ca. sechs Wochen später als ursprünglich erhofft, starteten wir in die nächste Phase des Projektes. Im Rahmen eines User-Tests testeten 10 Personen je ca. 1,5 Stunden alle gängigen Features des Plugins. Wer noch nie User-Tests durchgeführt hat, kennt nicht die Magie, die hier stattfindet. Bei der Konzeption und Umsetzung einer Software zerbricht man sich Stunden lang den Kopf, was die einfachste Lösung für einen Nutzer sei. In User-Tests ist es aber häufig so, dass Nutzer egal welchen Alters, Geschlechts und manchmal auch unabhängig von deren Vorerfahrungen auf dieselben Verständnisprobleme stoßen. Egal, wie sehr man sich zuvor bemüht hat. So war es auch bei Real Cookie Banner. Das Plugin sah vor den User-Tests nur unmerklich anders als danach aus, aber die umgesetzten Learnings führten zu einem spürbare einfacheren Nutzung der Software. Zusammen mit einer anschließenden Early-Access-Phase mit weiteren ca. 25 weiteren Testern, setzen wir mehr als 100 Änderungen aus dem Feedback der Nutzer um.
Tada, hier ist Real Cookie Banner!
Heute, als dieser Artikel erschienen, ist es sechs Monate nachdem wir die ersten Zeilen zu Real Cookie Banner schrieben. Und der Tag, an dem Real Cookie Banner auf devowl.io erhältlich ist. Herausgekommen ist ein WordPress-Plugin, dass versucht eine Vielzahl von Probleme bestehender Cookie Banner für WordPress zu attackieren. Im direkten Vergleich mit Alternativen zu Real Cookie Banner erscheint es uns, als hätten wir fast eine eierlegende Wollmilchsau für Cookies erschaffen. So viele Features wie das Plugin bereits in seiner ersten Version mitbringt und diese zugleich so einfach wie nur möglich seinen Nutzern zugänglich zu machen, ist es das Plugin, was wir Anfang 2020 gesucht hätten. Und das ist erst der Beginn, denn unsere Liste mit Ideen, wie das nervige Thema Cookies für Website-Betreiber noch einfacher gestalten kann, ist bereits prall gefüllt 😉
„Real Cookie Banner ist ein Opt-in Cookie und Consent Management Plugin. Hole Einwilligung zum Laden von Diensten und zum Setzen von Cookies für deine Besucher in Einklang mit der DSGVO und der ePrivacy Richtlinie ein. Darüber hinaus helfen dir Content Blocker dabei konform zu sein, selbst wenn dein Theme, ein Plugin oder Content CSS, JavaScript oder Iframes lädt, die personenbezogene Daten übertragen würden. Starte jetzt mit unserer geführten Konfiguration und vermeide rechtliche Risiken!“ – Auszug aus der Produktbeschreibung von Real Cookie Banner
Abseits von der Hoffnung auf einen wirtschaftlichen Erfolg, der bei einem solchen Projekt natürlich immer eine Rolle spielen muss, stellt sich zum Abschluss eines Projektes immer wieder dieselbe Frage: Habe ich hier sechs Monate meines Lebens in etwas gesteckt, worauf ich stolz sein kann?
Das ist bei Real Cookie Banner eine wirklich nicht einfach zu beantwortende Frage. Einerseits bin ich wirlich stolz darauf, was Matze und ich in dem letzten halben Jahr auf die Beine gestellt haben. Zusammen haben wir eine Lösung gebaut, bei der wir von Testern in User-Tests und der Early-Access-Phase bereits das Feedback erhalten haben, dass wir Leben von Bloggern, ehrenamtlichen Betreibern von Vereinswebsites und Agenturmitarbeitern ein gutes Stück vereinfachen. Das ist toll, denn nicht mehr und nicht weniger sollte das Ziel einer solchen Lösung sein. Auf der anderen Seite haben Matze und ich in den vergangenen Monaten viel über Cookies und die Wünsche des europäischen Gesetzgebers bezogen auf Datenschutz gelernt. Als diejenigen, die eine möglichst einfache Lösung für komplexe Anforderungen umgesetzt haben, erscheinen uns viele der Vorgaben recht weltfremd. Die Anforderungen mögen gut gemeint zu sein, aber aus der Feder Personen zu kommen, welche Dynamiken des Internets nicht durchdrungen haben. Lösungen für die anzugreifenden Probleme müssten aus meiner Perspektive auf anderer Ebene gefunden weden. Sei es bei den Browser Herstellern oder der „Datensammelindustrie“ selbst. Eine Verpflichtung jedes einzelnen (Hobby)-Websitebetreibers eine Vorgabe umzusetzen, mit der wir als gelernte Informatiker uns sechs Monate auseinandersetzen mussten, um sie zu umfänglich verstehen, scheint mir nicht zielführend zu sein. So wäre es mir eigentlich lieber, wenn es Real Cookie Banner gar nicht geben müsste, da ich denke es gäbe cleverere Ansätze den Markt der Datensammler zu regulieren. Wir dahin versuchen wir mit Real Cookie Banner aber unser bestes, dass menschengemachte Probleme, anderen Menschen abzunehmen.
5 Kommentare. Hinterlasse eine Antwort
Spannend, eure Lösung ist aber wenn ich es richtig verstanden habe nur für WordPress ausgelegt, oder? Ich bin vor kurzem bei CookiePro von OneTrust gelandet, da ich z. B. auch ein Xenforo-Forum mit meinem WordPress verbunden habe, das natürlich mit dem gleichen Cookiesystem arbeiten sollte.
Korrekt, Real Cookie Banner ist ein WordPress-Plugin und speziell für das WordPress Ökosystem gebaut. Dabei verstehen wir das Plugin als Consent Management Lösung, die mehr als „nur“ Einwilligungen zum Setzen von Cookies verwalten kann. Laut Art. 6 DSGVO brauchst für die Verarbeitung jedes personenbezogenen Datums eine Verarbeitungsgrundlage. In vielen Fällen kommt nur die Einwilligung infrage.
Lösungen wie die von OneTrust erlauben es dir deren Software von deren Cloud-Service zu in deiner Website einzubinden und haben ein „Cookie Blocking“ System. Das ist bei solchen Lösungen immer ein JavaScript, dass zuerst geladen wird (und solang wird das Rendering der weiteren Website) blockiert. Dieses JavaScriot verhindert, dass weitere JavaScript Dateien Cookies setzen. Soweit eine gute Idee, die unabhängig vom Ökosystem, in dem das Cookie Banner läuft, funktioniert. Daraus ergeben sich jedoch mehrere Probleme:
1. Cookie Blocking JavaScript wird nicht geraden: Wenn das JavaScript nicht geladen werden kann – sei es, weil der in dem Beispiel der OneTrust Server nicht erreichbar ist, die Internetverbindung bei dieser Datei Probleme macht oder eine Browser-Erweiterung die Datei blockt – setzt deine Website weiterhin Cookies. Ohne, dass du ein Einwilligung deiner Besucher hast.
2. Verarbeitung personenbezogener Daten ohne Cookies: Es gibt Systeme, die mittlerweile Lösungen zum Tracking gefunden haben in eingeschränkter Form ohne Cookies zu tracken. Das ist toll, da keine Cookies gesetzt werden, aber es werden ggf. weiterhin personenbezogene Daten wie die IP-Adresse verarbeitet (und gespeichert). Dies kann, wie oben bereits angedeutet, in viele Fällen nur mit einer Einwilligung geschehen. Lösungen wie OneTrust blocken Cookies. Es werden bei diesen Lösungen aber auch ohne Einwilligungen bereits Daten von z.B. Google Maps, YouTube, Google Analytics im Browser geladen (technisch ohne tiefe Einbindung in ein Ökosystem nicht anders möglich). Diese z.B. Scripts können (ohne Cookies) bereits vor der Einwilligung Daten „nach Hause schicken“, die nur mit einer Einwilligung verarbeitet werden dürften.
3. Nicht alle Cookies blockbar: Cookie ist nicht gleich Cookie. Das mussten wir während der Entwicklung auch erstmal lernen. Es gibt Cookies, die aus Security Gründen so gesetzt werden, dass diese nur von bestimmten Domains, nur server-side, etc. diese wieder ordentlich entfernt werden können. Da Lösungen wie OneTrust das Laden der externen Dateien (siehe Punk 2) nicht verhindern können, kann es auch nur verhindern, das bestimmte Cookie Arten gesetzt werden. Auf bestimmte Cookies hat das OneTrust JavaScript schlicht keinen Zugriff. Du als Website-Betreiber musst hier somit Dienste auswählen, die nur „leicht manipulierbare“ Cookies setzen. Das schließt nicht nur bestimmt Services aus, sondern wir weit über das technische Wissen vieler Website-Betreiber hinausgehen.
Dieses Kernproblem (und ein paar weitere Probleme) kannst du nur lösen, indem du bereits beim server-side Rendering z.B. deiner WordPress Scripts, die vor der Einwilligung geladen werden würden, entfernst, und nach der Einwilligung nachlädst. Technisch ist das unseres Kenntnisstandes nach leider mit einer „Unviersal-Cloud-Lösung“ wie sie OneTrust anbietet nicht umsetzbar. Daher haben wir uns für ein Ökosystem entschieden – aber weitere können ja noch folgen 😉
Danke für deine ausführliche Antwort. Ja, bei mehreren Systemen ist das wohl nicht so einfach übergreifend zu realisieren, wenn man nicht selber richtig Hand anlegt – was bei kleinen Seiten einfach nicht machbar ist. Ich möchte daher auch möglichst bald auf eine Art Paywall wechseln – entweder Cookies für Marketing etc, oder bezahlen. Mal sehen wie das dann läuft.
Bei OneTrust ist es übrigens so, dass man die Javascript-Datei auch herunterladen und lokal hosten kann. Das einzige Problem bei uns ist aktuell, dass aus einem bisher unbekannten Grund die funktionellen Cookies aktiv sein müssen, um im Forum auf Beiträge antworten zu können. Und wenn man „I don’t care about cookies“ als Browserplugin nutzt, werden die wohl nicht richtig akzeptiert.
Korrekt, bei mehreren Systemen das nicht mehr einfach umsetzbar. Bei der ganzen Idee hat der Gesetzgeber, wie zum Ende des Artikels bereits beschrieben, eine prinzipiell gute Intension gehabt, die Umsetzbarkeit ist halt nur sehr aufwändig bzw. unrealistisch.
Das OneTrust JavaScript selbst zu hosten ist auf jeden Fall eine bessere Lösung, da es eine Schwachstelle eliminiert. Es ändert aber nichts am Kernproblem. Analog könnte man sagen mit einer solchen Lösung baut man keine Sicherheitsgurte in das Auto ein, dass den Schaden bei dem Unfall (Cookie setzen) aktiv zurückhält. Stattdessen baut man einen großen Front-Airbag ein, der den Schaden abfangen soll. Wenn jedoch ein anderes Auto von der Seite einfährt, dann tritt der Schaden trotzdem ein, da man in der Mittelkonsole kein Airbag haben kann, und man nimmt dies bewusst in Kauf.
[…] Real Cookie Banner entstand aus dem eignen Bedarf der beiden Gründer Jan und Matze heraus, denn aufgrund der rechtlichen Gegebenheiten suchte Jan […]