Spätestens die jüngste Entscheidung des Europäischen Gerichtshofs hat alle wachgerüttelt: Die meisten Cookies dürfen erst gesetzt werden, nachdem die Einwilligung des Nutzers eingeholt wurden.
Einige Homepage-Baukasten und Plattformen wie Wix bieten jedoch keine geeignete Lösung an und setzen weiter munter Cookies – Cookie-Banner hin oder her. In diesem Beitrag zeige ich euch, wie ihr dieses Problem angehen könnt.
1. Die Einstellungen
„Das habe ich bereits probiert?“ – Das glaube ich dir. Bei einigen Homepage-Baukästen lässt sich noch so lange herumprobieren, einige Cookies lassen sich einfach nicht aktivieren.
Andere hingegen bieten zumindest die Möglichkeit Funktionen wie „Statistiken“ einzuschränken oder Werbe-Anzeigen entsprechend anzupassen. Der Blick in die Einstellungen sollte also der erste Schritt sein – womöglich hat dein Baukasten-Betreiber sich doch schon Gedanken zu dem Thema gemacht.
2. Cookies manuell verhindern
Die vielversprechendste Lösung präsentiere ich dir bereits an 2. Stelle: Wann immer, du selbst eigenen HTML-/JavaScript-Code einbinden kannst (z.B. Analysewerkzeuge bei Wix), kannst du manuell die Cookies löschen.
Wenn wir bei dem Beispiel Wix bleiben, ist besonders der Cookie „svSession“, der über 2 Jahre gesetzt wird aus datenschutzrechtlicher Sicht problematisch. Er soll über einen langen Zeitraum Besucher individuell erkennen. Wenige Minuten oder Tage wären da noch weniger störend, 2 Jahre aber sind eine lange Zeit.
Cookies sind letztlich kleine Dateien, die an (fast) jede Anfrage an einen Server angehängt werden. Wird der Cookie einmal gespeichert, sendet der Browser ihn für die nächsten 2 Jahre stets mit, wenn die gleiche Website oder eine Unterseite erneut aufgerufen wird.
Wir können den Cookie jedoch „wertlos“ machen und seine Cookie-Lifetime auf wenige Sekunden begrenzen, indem wir automatisiert mit jedem Aufruf löschen:
<script type="text/javascript">setTimeout(function(){ document.cookie = "svSession=;path=/;domain=.www.meine-wix-website.de;expires=Thu, 01 Jan 1970 00:00:01 GMT"; }, 1500);</script>
Dieses Skript wartet 1,5 Sekunden (1500 Millisekunden) damit das Cookie auch gesetzt wurde und löscht dann das „svSession“-Cookie auf deiner Website. Du musst nur daran denken, die genannte Domain anzupassen (bitte den „.“ vor der Domain nicht entfernen). Unter Umständen solltest die Zeitspanne verlängern, je nachdem wie lange deine Seite benötigt, um sich aufzubauen.
Was passiert also? Die Website lädt und mit ihr diverse Skripts und Grafiken. Eines der zuerst geladenen Skripts speichert einen Cookie in deinem Browser. Die danach geladenen Skripts bekommen diesen Cookie-Inhalt womöglich noch überliefert, können also noch den eindeutigen Besucher identifizieren. Nach den 1,5 Sekunden bzw. nach dem nächsten Seitenaufruf beginnt das Spiel erneut. Der Nutzer kann also nicht über mehrere Seitenaufrufe verfolgt werden.
Der Cookie bleibt – allerdings mit einer Sekunden-Lifetime und ist damit faktisch fast kein Cookie mehr, was nahelegt, ihn als „unbedingt notwendig“ oder nicht mehr als „Cookie“ anzusehen, sodass keine Einwilligung erforderlich wäre. Jedenfalls wird das Risiko das von diesem Cookie ausgeht, so erheblich reduziert.
3. Iframe Sandbox
Eine Lösung kann auch das Nutzen einer iframe-Sandbox sein. Du nutzt eine weitere Domain und bindest per iframe einfach deine komplette Domain als iframe in einer Sandbox ein. Damit kannst du das Setzen – zumindest von third party Cookies – verhindern. Das kann zum Beispiel so aussehen auf example.com:
<iframe src="https://echte-homepage.example.com" sandbox="allow-forms,allow-scripts"></iframe>
Oft, etwa im Fall von Wix, lässt sich dann die Seite jedoch nicht mehr ordnungsgemäß bedienen. Erst wenn wir auch noch „,allow-scripts“ entfernen, um sicherheitshalber alle Skripte zu blockieren.
Außerdem musst du darauf achten, dass deine aufgerufene Website (z.B. https://echte-homepage.example.com) nicht einfach direkt von außen aufgerufen wird. Suchmaschinen solltest du dazu per robots.txt Anweisungen erteilen und per JavaScript oder .htaccess (s. Beispiel 6) kannst du sicherstellen, dass die Website tatsächlich nur in dem iframe aufgerufen werden darf. Per JavasScript kann dies beispielsweise so aussehen:
<script type="text/javascript"> if(window!=window.top) { location.href = 'https://www.example.com'; } </script>
4. Skripte blockieren
Du kannst auch alle JavaScripts blockieren. Der Weg dahin: Ändern wir type=“text/javascript“ z.B. zu type=“blocked“ wird das JavaScript nicht mehr ausgeführt.
Medium.net beschreibt ausführlich, wie dies funktionieren kann. Beachte: Auch diese Lösung kann dazu führen, dass deine Website nicht mehr ordnungsgemäß funktioniert. Das hängt vor allem davon ab, wie einfach sie aufgebaut ist bzw. wie aufwändig sie von „hübschen“ Visualisierungseffekten Gebrauch macht.
5. Anbieter wie CookieYes
Du willst es noch etwas einfacher? Für Plattformen wie WordPress & Co. gibt es bereits fertige Lösungen, einen Überblick findest du hier.
Womöglich sind jedoch auch plattformunabhängige Lösungen interessant für dich. So etwas bieten z.B. CookieYes und CookieBot an. Der Nachteil: Nicht immer können alle Cookies verhindert. Dann bietet sich eine Kombination mit der Lösung 2 an – dem manuellen Blockieren, um Cookies zu verhindern.
Sehr geehrte Damen und Herren,
ich bin habe meine Webseite bei Wix erstellt, leider ist die zweite Lösung nicht umsetzbar. Der svsession ladet trotzdem, oder gibt es ein neues Skript für dafür? Wie sieht es mit den anderen Marketing und Statidtik Cookies von Wix aus? Gleiches Script Prinzip?
Ich würde mich auf mehr Informationen sehr freuen!
Mit freundlichen Grüßen
Armin Salkanovic
Der SvSession-Cookie wird zwar zunächst erstellt, sollte aber nach einigen Sekunden gelöscht bzw. jedenfalls nicht dauerhaft gespeichert werden. Abhängig davon, welche Skripte auf der Website ggf. mit Verzögerung noch geladen werden und den Cookie erneut setzen, kann es sein, dass der Cookie nach dem Löschen erneut gesetzt wird. Auch in dem Fall verhindert die Lösung jedoch die dauerhafte Erkennung des Nutzers über Seitenaufrufe hinweg.
Für die anderen Cookies kann das Skript entsprechend angepasst ebenfalls verwendet werden, ja.