Eine Datenschutzerklärung, die nicht veraltet

01Der Fehler passiert leise#

Eine Datenschutzerklärung zählt auf, was eine Website speichert. Sie wird einmal sorgfältig geschrieben, oft mit anwaltlicher Hilfe, und ist an diesem Tag vollständig. Dann kommt ein halbes Jahr Arbeit an der Seite: ein neues Feld in der Zählung, ein neuer Knopf, dessen Klicks interessant wären, ein Umschalter, von dem man gern wüsste, ob ihn jemand benutzt.

Was in zwei Dateien getrennt gepflegt wird, läuft auseinander. Nicht vielleicht — irgendwann sicher.

Jede dieser Änderungen ist klein, jede ist harmlos gemeint, und keine löst irgendetwas aus. Kein Test schlägt fehl, kein Browser warnt, niemand bemerkt etwas. Die Erklärung verspricht Vollständigkeit und ist es nicht mehr — und das Auseinanderlaufen geschieht genau dort, wo niemand hinsieht, weil beide Seiten für sich genommen in Ordnung sind.

Uns ist das passiert. Der Umschalter zwischen hellem und dunklem Hintergrund meldete seit seinem Einbau ein Ereignis an die eigene Zählung. Der Server nahm es an und verwarf es stillschweigend, weil es nicht auf seiner Liste stand — und in der Erklärung stand es auch nicht. Gefunden haben wir es erst, als wir beide Seiten nebeneinandergelegt haben.

02Die Erklärung aus dem Code erzeugen#

Der Ausweg ist unspektakulär: Die Aufzählung in der Erklärung wird nicht mehr von Hand gepflegt, sondern beim Bauen aus einer Tabelle erzeugt. In dieser Tabelle steht je gespeichertem Feld eine Zeile mit dem technischen Namen und einem Satz auf Deutsch und Englisch, der ihn erklärt. Aus den Sätzen setzt sich der Absatz zusammen, der auf der Datenschutzseite steht.

Eine Zusage, die niemand prüft, ist eine Absicht.

Damit ist noch nichts gewonnen — die Tabelle könnte genauso veralten wie der Text vorher. Der zweite Schritt ist der, auf den es ankommt: Beim Bauen liest das Programm die Liste der Felder aus dem Quelltext des Zählwerks und vergleicht sie mit der Tabelle. Fehlt ein Feld in der Erklärung oder steht dort eines, das der Zähler gar nicht mehr speichert, bricht der Bau ab und sagt, welche Zeile fehlt.

Dasselbe eine Ebene tiefer: ‚Ereignisse‘ ist ein Feld, aber was darin steht, sind neun verschiedene Dinge — ein Produktklick, ein Sprachwechsel, eine aufgeklappte Frage. Sie einzeln zu erklären ist die halbe Zusage; sie einzeln zu prüfen die andere Hälfte.

03Drei Prüfungen, die den Bau anhalten#

Bei uns sind es inzwischen drei, und jede fängt einen anderen Weg ab, auf dem etwas auseinanderlaufen kann. Die erste: Der Zähler nimmt ein Ereignis an, das die Erklärung nicht kennt. Die zweite: Die Erklärung beschreibt eines, das der Zähler nicht mehr annimmt — auch das ist falsch, nur in die andere Richtung. Die dritte: Der Browser meldet ein Ereignis, das die Weißliste des Servers nicht kennt, das also im Stillen weggeworfen wird.

Der Bau bricht ab. Das ist unbequem und genau der Punkt.

Die dritte hätte unseren Umschalter-Fehler beim nächsten Bau gefunden. Sie kostet zwölf Zeilen. Man muss sie nur schreiben, bevor man den Fehler macht — und dafür muss man akzeptiert haben, dass man ihn machen wird.

Der Aufwand für all das lag bei einem halben Tag. Er lohnt sich nicht, weil eine Behörde fragen könnte. Er lohnt sich, weil eine Seite, die Vollständigkeit verspricht, diese Zusage sonst nur so lange hält, wie sich niemand an ihr zu schaffen macht.