Was ein Consent-Banner technisch tut
Zwischen dem Klick auf „Ablehnen“ und dem, was der Browser danach tatsächlich lädt, liegen mehrere Schritte. Wer sie kennt, erkennt schnell, ob ein Banner die Entscheidung wirklich umsetzt oder nur anzeigt.
Ein Consent-Banner ist kein Schild, sondern ein Türsteher. Seine eigentliche Arbeit besteht nicht darin, eine Frage anzuzeigen, sondern darin, alles andere so lange anzuhalten, bis die Antwort da ist. Genau daran scheitern viele Umsetzungen.
Der Ablauf von der Anfrage bis zum Nachladen
- Der Blockierer startet als ErstesEin kleines Skript ganz oben im Dokument. Es fängt Skript-Einbindungen ab, bevor der Browser sie ausführt.
- Die gespeicherte Entscheidung wird gelesenLiegt eine gültige Entscheidung vor, erscheint kein Banner – und alles Erlaubte startet sofort.
- Die Frage erscheintErst jetzt, und ohne dass währenddessen etwas Zustimmungspflichtiges lädt.
- Die Antwort wird gespeichert und protokolliertLokal für die nächste Sitzung, auf dem Server für den Nachweis: Zeitpunkt, Fassung des Banners, gewählte Zwecke.
- Freigegebene Dienste starten nachNur die zugestimmten. Abgelehnte bleiben stehen, bis die Entscheidung geändert wird.
Warum die Reihenfolge alles entscheidet
Ein Browser arbeitet ein Dokument von oben nach unten ab. Steht die Einbindung eines Werbeskripts vor dem Blockierer, ist der Aufruf bereits abgeschickt, wenn der Blockierer startet. Zurücknehmen lässt sich der Aufruf nicht: Die Verbindung wurde aufgebaut, die IP-Adresse übertragen, ein Cookie möglicherweise gesetzt.
Deshalb liegt der Kern jeder ernsthaften Lösung in einem kleinen Skript, das vor allem anderen läuft. Alles Weitere – Gestaltung, Sprachen, Protokoll – ist danach.
Zwei Bauweisen, die von außen gleich aussehen
Was gespeichert wird und wo
Die Entscheidung wird an zwei Stellen abgelegt, und beide haben verschiedene Aufgaben. Im Browser liegt sie, damit die Frage nicht bei jedem Aufruf erneut erscheint. Auf dem Server liegt sie, damit sich später belegen lässt, dass zugestimmt wurde – und wozu genau.
Das serverseitige Protokoll ist kein Beiwerk: Ohne es lässt sich die Nachweispflicht nicht erfüllen, weil ein Eintrag im Browser der betroffenen Person weder erreichbar noch fälschungssicher ist.
Ein sauberes Protokoll enthält den Zeitpunkt, die abgefragten Zwecke, die getroffene Wahl, die Fassung der Texte und die Sprache. Was es nicht enthalten sollte, ist eine Klartext-IP-Adresse: Für den Nachweis genügt ein Hashwert, und eine gespeicherte Adresse wäre selbst wieder ein personenbezogenes Datum, das ohne eigenen Grund vorgehalten würde.