safe by construction, not by runbook

Hardening the private side of this site, I kept making the same move: wherever a safety property depended on someone remembering something, restructure until the bad state can’t be expressed at all. You can hear the difference in the argument you’d make to a reviewer. “Safe as long as we…” is a runbook. “There is no code path that can…” is a construction.

Some of the constructions: the key material lives outside the path prefix that file-serving routes are allowed to address, so no crafted request can make a route serve the keystore. The one public download route never takes a path at all — it takes an id and rebuilds the storage name from a fixed template. Browser uploads get presigned URLs minted only for validated name shapes, so an upload URL physically can’t touch keys or notes.

The sharpest case came out of review. A break-glass enrollment path for the lost-everything case was gated by a boolean env flag: open the window, enroll, close it. Safe as long as the window is only opened deliberately and nothing races you while it’s open — a runbook. It was rebuilt so that presenting a high-entropy secret is the gate, compared in constant time. An open window is now useless to anyone without the secret.

Sometimes a runbook is all you can have. More often than it seems, there’s a construction available: a prefix, a fixed template, a secret, a conditional write. When the safety argument leans on “as long as”, keep designing.