Im Browser statt im Cookie

Was ein Cookie eigentlich tut

Ein Cookie ist ein kleiner Textschnipsel, den ein Server dem Browser mitgibt und den der Browser sich für diese Domain merkt. Das Entscheidende passiert danach, denn der Browser schickt das Cookie von sich aus bei jeder weiteren Anfrage an dieselbe Domain wieder mit, ohne dass die Seite oder der Nutzer etwas dafür tun müssen. Das gilt für den Seitenaufruf selbst genauso wie für jedes Bild, jedes Skript und jeden API-Call.

Genau für diesen Zweck wurde das Cookie erfunden. HTTP ist zustandslos, jede Anfrage steht für sich, und ohne ein solches Merkzeichen wüsste ein Server nicht, dass die dritte Anfrage von derselben Person kommt wie die erste. Für eine Anmeldung ist das unverzichtbar, weil der Server bei jedem Klick erkennen muss, wer gerade angemeldet ist.

Daten, die man gar nicht schicken wollte

Weil das Mitschicken automatisch geschieht, wandert alles, was in einem Cookie steht, bei jeder Anfrage über die Leitung, und zwar unabhängig davon, ob der Server es in diesem Moment braucht. Auf dem Weg passiert es Load Balancer, CDN und Proxys, und es landet je nach Konfiguration in deren Logs. Was als harmlose Einstellung für die Oberfläche gedacht war, wird so nebenbei zu Daten, die an mehreren Stellen verarbeitet werden.

Noch weiter reicht der Mechanismus, wenn eine Seite Inhalte anderer Domains einbindet, etwa ein Tracking-Pixel, ein Analyse-Skript oder einen eingebetteten Button. Auch diese Domains dürfen Cookies setzen und bekommen sie bei jedem Aufruf zurück, und zwar auf jeder Website, die denselben Dienst einbindet. Aus vielen einzelnen Besuchen entsteht so ein Profil über Seiten hinweg, und genau dafür werden Drittanbieter-Cookies in der Praxis überwiegend eingesetzt.

Der Banner hängt am Zweck, nicht an der Technik

Die Einwilligungspflicht, die hinter jedem Cookie-Banner steht, ist in Deutschland in § 25 TDDDG geregelt, dem früheren TTDSG. Das Gesetz spricht dabei gar nicht von Cookies, sondern allgemein von der Speicherung von Informationen in der Endeinrichtung und dem Zugriff darauf. Es ist also technologieneutral, sodass derselbe Maßstab für den localStorage gilt, wenn eine Seite ihn für Tracking verwendet.

Entscheidend ist die Ausnahme in Absatz 2, nach der keine Einwilligung nötig ist, wenn die Speicherung unbedingt erforderlich ist, damit ein vom Nutzer ausdrücklich gewünschter Dienst bereitgestellt werden kann. Darunter fallen die Sprachauswahl, die Session einer Anmeldung oder der Warenkorb, und deshalb braucht keines dieser Cookies einen Banner. Auch diese Website setzt genau zwei Cookies, eines für die gewählte Sprache und ein kurzlebiges, das nach dem Absenden eines Formulars die Erfolgsmeldung transportiert, und beide sind rein funktional.

Daraus folgt eine Einordnung, die sich im Alltag lohnt. Ein Cookie-Banner erscheint nicht, weil eine Website Cookies benutzt, sondern weil sie Informationen für Zwecke erheben will, die über das hinausgehen, was der Besucher gerade tut, typischerweise Reichweitenmessung, Werbung oder Profilbildung. Wer sich über einen Banner ärgert, stellt deshalb die bessere Frage, wenn er nicht nach der Technik fragt, sondern danach, warum der Betreiber diese Informationen überhaupt braucht und was damit passiert, denn für die Funktion einer Seite ist das so gut wie nie nötig.

Der localStorage: Daten, die im Browser bleiben

Für alles, was nur die Oberfläche angenehmer machen soll, gibt es seit Langem eine passendere Ablage. Der localStorage ist ein Speicher im Browser, den jede Website für ihre eigene Domain nutzen kann und in dem Daten erhalten bleiben, bis die Seite oder der Nutzer sie wieder löscht. Der Unterschied zum Cookie liegt in einem einzigen, aber wesentlichen Punkt, denn der Browser schickt den Inhalt des localStorage nie von sich aus an den Server.

Was dort liegt, verlässt den Rechner also nur, wenn die Seite es bewusst und für einen bestimmten Zweck in eine Anfrage packt. Damit dreht sich die Richtung der Entscheidung um, weil nicht mehr alles standardmäßig mitreist und man sich aktiv überlegen müsste, es wegzulassen, sondern nur das übertragen wird, was in diesem Moment tatsächlich gebraucht wird. Genau das verlangt die DSGVO mit dem Grundsatz der Datenminimierung und mit Datenschutz durch Technikgestaltung, und hier ergibt es sich ganz von selbst aus der Architektur.

Das Beispiel: unser Kontaktformular

Wie das in der Praxis aussieht, lässt sich am Kontaktformular dieser Website zeigen. Die Einstellung am Mischpult, ein angefangener Entwurf und der zuletzt genutzte Kontaktweg liegen im localStorage deines Browsers, sodass ein Neuladen oder ein Sprachwechsel nichts verloren gehen lässt. Beim Server kommen diese Angaben erst an, wenn du das Formular ausdrücklich absendest, und dann genau einmal, als Inhalt deiner Anfrage.

Auch der Verlauf deiner bisherigen Nachrichten, den das Formular bei jedem Besuch wieder anzeigt, stammt aus dem localStorage und nicht vom Server. Um ihn anzuzeigen, muss die Website weder ein Konto anlegen noch deine früheren Anfragen vom Server abrufen, und eine Bestätigung per E-Mail ist auch nicht nötig, weil dein Browser selbst festhält, was du uns geschrieben hast. Diese lokale Kopie bleibt an diese eine Browser-Instanz gebunden, sie taucht auf keinem anderen Gerät auf, und mit einem Klick auf „Lokalen Verlauf löschen" ist sie vollständig weg.

Das heißt nicht, dass bei uns nichts ankommt. Sobald du das Formular absendest, empfängt unser Server deine Nachricht, deinen Kontaktweg und die Mischpult-Einstellung, verarbeitet sie und leitet sie an Slack weiter, das wir intern für die Bearbeitung von Anfragen nutzen. Wie das im Einzelnen abläuft und wie lange die Daten dort bleiben, beschreibt unsere Datenschutzerklärung. Der Unterschied liegt darin, dass nur diese eine, ausdrücklich abgeschickte Anfrage übertragen wird, während Entwurf, Voreinstellungen und die Anzeige deines Verlaufs bei dir bleiben, sodass alles, was nicht zwingend übertragen werden muss, auch nicht übertragen wird.

Was das für dein Produkt heißt

Für jedes eigene Produkt lohnt sich bei jedem neuen Merkwert dieselbe kurze Prüfung, bevor er in einem Cookie landet. Braucht der Server diesen Wert bei jeder Anfrage, wie eine Session-ID oder die Sprache, dann gehört er in ein Cookie. Braucht ihn nur die Oberfläche, etwa eine Sortierung, ein zugeklapptes Panel, einen Entwurf oder eine Voreinstellung, dann gehört er in den localStorage, wo er niemandem über die Leitung folgt.

Diese Unterscheidung kostet in der Entwicklung kaum Aufwand, zahlt sich aber an mehreren Stellen aus. Jeder Wert, der nicht beim Server ankommt, taucht in keinem Log auf, muss in keinem Verarbeitungsverzeichnis stehen und kann bei einem Sicherheitsvorfall nicht abfließen. Datenschutz entsteht so nicht als Pflichtübung am Ende eines Projekts, sondern als Eigenschaft eines Produkts, das von Anfang an nur das erhebt, was es wirklich braucht.