Skip to content
Kempton Watch Tip

Posts

What This Site Refuses to Publish

The record's rules are code. A gate stops any release that breaks them, and a person reads every security finding. Here is where the checks are strong, and where they are not.

By Piet Speurder · · 6 min read

About how it's builtsafetysecurityseriestesting

A site that holds tips and sensitive details owes people care. How the record's rules are written as code and refused at publish time, what the 816 tests guard, where the checks are weaker, and what an AI security audit did and did not find.

Diagram "The publishing gate": new data passes the gate to publish or is blocked with a reason; what the gate blocks, and what is handled outside it.

Kempton Watch

Kempton Watch keeps a record of women killed in Ekurhuleni. To do that, it has to hold things that can hurt people if they ever leak: tips sent in by members of the public, some of them frightened; the contact details of people who chose to leave them; and details of the women themselves, drawn only from what officials and news outlets have already published.

A site that holds all of that owes people one plain thing in return: that it was built with care. This is the first of four posts on how the site was built, and it is about safety.

The rules are code

The most important safety feature on this site is not a firewall. It is a gate between the data and the public, and it refuses to publish anything that breaks the rules.

The record keeps a few firm rules. No home or street address goes out in a location. A suspect is not named unless a court has named them. A woman is named only when an official statement or an on-the-ground outlet named her first, never from a second-hand rewrite. And the deaths are not called a series, because officials have said the link between them is not confirmed, and it is not our place to decide otherwise.

The gate checks some of those rules every time the site prepares new data to go out. If a street address has slipped into a location field, the gate stops. If a description of a suspect reads like a name with no court attached, the gate stops. If a withheld name turns up anywhere, even inside a quote, the gate stops. The other rules are handled elsewhere: a name that only a rewrite carried is withheld when the data is prepared, and the page never uses the word series unless an official has. When the gate stops, it says what broke, so it can be fixed.

This matters more than anything else in this post. Most security work protects the building. This protects what the public actually sees. It is the difference between trusting a person to remember every rule, every time, often late and tired, and having the machine refuse to let the rule be broken. People slip. The gate does not get tired, and it does not make exceptions.

Tested as it was built

The gate is part of a larger habit. The site was built over about a week, and automatic tests grew alongside the code the whole way. There are 816 of them now.

Each one pins down a single thing that should stay true and checks that it still is: that a withheld name stays withheld, that a draft post cannot be read before it is meant to be, that a staff member is refused an action they are not permitted to take. Whenever the website's code changes, its tests run against it, so a change that would quietly break one of those promises shows up before a visitor ever sees it.

Most of the tests, 574 of them, cover the website. Another 172 cover the data pipeline, the gate included. The last 70 cover the parts of the pages that run in your browser.

Checked, and where it is not

The website and the data pipeline are checked in different ways, and one is weaker than the other.

Every time the website's code is changed and pushed, a set of automatic checks runs over it: the tests on two different databases, a tool that reads the code for mistakes without running it, a style check, a type check, and a scan of the outside code the site relies on for known weaknesses. But the site goes live on the same push that starts those checks. They run alongside the deployment, not as a locked door in front of it. They catch problems quickly; on their own, they do not hold a bad change back.

The data pipeline is weaker still. It has no automatic code checks; its tests are run by hand before a change is saved. What saves it is where the strongest protection sits. The pipeline is also where the gate lives, and the gate runs automatically on every release. So the part of the system with the least automatic checking is guarded, at the moment that counts, by the strongest safety feature the site has.

Panel "What checks the code, and when": automatic checks on every website push and the automatic publishing gate in green; pipeline tests by hand and the occasional AI audit in amber.
Kempton Watch

Audited by a machine, judged by a person

Once the site was built, an AI security tool was turned on it and set to probe it the way someone with bad intentions might. It ran against a throwaway copy, never the live site.

It came back with eleven findings. That sounds alarming; it was not. Six were the tool missing a safeguard that was already there. Three were settings that only look wrong on a local test machine and are correct on the real one. Two were small, genuine jobs, and both are done. There was nothing an outsider could exploit, and nothing serious.

Waffle chart "The security audit, in one picture": eleven findings, six false positives, three correct in production, two genuine and low, both fixed.
Kempton Watch

The tool is useful, and it does not get the last word. A person read every finding and checked it against the code before calling it true or false. The machine assists; a person decides. On a site like this one, that order is not up for negotiation.

The quiet basics

Underneath all of that are the ordinary things.

Every staff account must use two-step sign-in; there is no opting out. The browser is given a strict list of the code it may run, and it blocks anything else. When the site fetches something from the web, it may reach ordinary public addresses only, never the private insides of the server it runs on. Tips, and the contact details people leave, are encrypted where they are stored. The site uses Google Analytics on public pages only, with its advertising features off; it is never loaded on victim pages, on the tip form or for staff, and it respects a browser's Do Not Track or Global Privacy Control setting. And the site keeps as little personal information as it can, for no longer than it needs to.

None of this is clever. Ag, it is not meant to be. It is meant to be boring, reliable and out of the way.

Not a badge

Safety here is not something earned once and then displayed. It is an obligation that does not end. New data keeps arriving. The code keeps changing. Tools get better, and so, over time, do the people who would misuse a site like this.

The women in this record cannot be asked how they would want their details handled. That is why the handling has to be careful on their behalf. The tips come from people who took a risk to send them. The outlets we quote trusted that their words would be carried straight. Holding all of that carefully is not an extra on top of the work. It is the reason the site is allowed to exist at all.


Showing the Working — how this site was built: What This Site Refuses to Publish · Built for the Worst Day · The Bill, Itemised · Don't Trust Me. Check the Record.

Written by the people who keep this record, under its rules: names only as published by officials or on-the-ground or wire outlets, suspects described and never named, locations at suburb precision. Corrections to hello@kempton.watch.