A privacy statement that does not fall behind the code

01The mistake happens quietly#

A privacy statement lists what a website stores. It is written carefully once, often with legal help, and on that day it is complete. Then comes half a year of work on the site: a new field in the analytics, a new button whose clicks would be interesting, a toggle you would rather like to know whether anyone uses.

What is maintained separately in two files will drift apart. Not perhaps — eventually, certainly.

Each of these changes is small, each is meant harmlessly, and none of them triggers anything. No test fails, no browser warns, nobody notices. The statement promises completeness and no longer delivers it — and the drift happens exactly where nobody looks, because each side on its own is fine.

It happened to us. The light-and-dark toggle had been reporting an event to our own analytics since the day it was built. The server accepted it and discarded it silently, because it was not on its list — and it was not in the statement either. We only found it by laying both sides side by side.

02Generating the statement from the code#

The way out is unspectacular: the enumeration in the statement is no longer maintained by hand but generated at build time from a table. That table holds one row per stored field, with its technical name and a sentence in German and English explaining it. Those sentences make up the paragraph on the privacy page.

A promise nobody checks is an intention.

Nothing is won yet — the table could grow just as stale as the text before it. The second step is the one that matters: at build time the program reads the list of fields out of the analytics source and compares it with the table. If a field is missing from the statement, or the statement describes one the counter no longer stores, the build stops and says which row is missing.

The same one level down: ‘events’ is a single field, but what sits inside it is nine different things — a product click, a language switch, an expanded question. Explaining them individually is half the promise; checking them individually is the other half.

03Three checks that stop the build#

We now have three, and each catches a different way things can drift. First: the counter accepts an event the statement does not know. Second: the statement describes one the counter no longer accepts — also wrong, just in the other direction. Third: the browser reports an event the server's allow-list does not know, which is therefore discarded in silence.

The build stops. That is inconvenient, and exactly the point.

The third would have caught our toggle mistake at the next build. It costs twelve lines. You only have to write it before you make the mistake — and for that you have to have accepted that you will make it.

All of it took half a day. It is not worth doing because an authority might ask. It is worth doing because a site that promises completeness otherwise keeps that promise only as long as nobody touches it.