Protected nothing

Field notes from a proof-of-concept food-diary tool built alongside one NHS dietetic team,
not an official NHS product, no patient data anywhere in it. A privacy guardrail blocked its
repository from going public. Traced through the code, it protected nothing that going public would
have exposed.

A rule sounded exactly right, protected exactly nothing, and stood as the one thing blocking real
work, until someone traced it back to what the code actually does.

The rule was simple. Before the food diary's repository could go public, it needed a guardrail
against identifiable data leaking through the diary's own free-text fields, chiefly a description a
client might type next to a reference photo. Someone could type their own name into it without
thinking, to help remember whose entry it was. That risk was real, agreed on at the time in the
project's own words as "hard to guard... loose enough to say go public," and it sat there as the one
condition standing between the repository and a public GitHub Pages migration everything else was
ready for.

The condition held for a day. Then, traced through the actual code rather than argued about again,
it didn't survive the first look.

Where the description actually goes

The description a client types is captured in the app, stored as a note on a log entry in IndexedDB
on the device, and exported into a spreadsheet the dietitian handles. It is never committed, never
pushed, never served. The repository's visibility has no effect on it whatsoever, because it was
never in the repository to begin with. A guardrail on that field would have protected data that
going public put at no risk at all.

A second, independent reason cut just as deep. The app ships with no build step at all, just
straight unminified JavaScript, so its entire source has been downloaded verbatim by every single
visitor to the live site since the day it launched. Repo visibility was never protecting the
application code either, because the browser was already handing that code to anyone who asked. The
"code stays private" preference behind two earlier hosting rejections had, for the part of the
project a visitor could actually reach, never once been true.

The place nobody checked

If the free-text field was never the risk, going public should have been safe from day one. It
wasn't, quite, and the reason was somewhere else entirely: roughly forty tracked files sitting
outside the application folder, never served to a visitor and shielded from view by nothing but the
repository itself being private, among them migration notes, deploy docs, session logs, and a stray
config file. Grepping through all of it for anything infrastructure-shaped turned up exactly one
genuinely sensitive string: a hosting-account username, and not even this project's own account. It
belonged to someone else's.

	In the repo	Repo privacy hides it
Free-text descriptions	no	no
Application source	yes	no
~40 files outside the app folder	yes	yes

Three things the repository question could have been about. Only the last is both tracked in the
repository and hidden by nothing else, so it is the only one that going public actually exposes.

The thing everyone had been scared of couldn't actually happen. The thing worth being scared of
had been sitting in a folder nobody had opened, the whole time the guardrail argument was running.

A fix that doesn't depend on remembering

The fix that shipped doesn't ask anyone to remember anything. Rather than scrub the sensitive files
out of a single shared repository and trust every future session to keep scrubbing, the project
split in two: one private repository holding everything, full history intact, and one public
repository synced from it that holds only the application directory's own contents. Nothing outside
app/ can leak, because nothing outside app/ is ever in the public repo to begin with.

Purging the sensitive files from one shared repository's history was considered and turned down on
purpose. NOTES.md gets written every session, which means every future session is a fresh chance
to type an identifier back into a file that's now public, and a miss like that is silent and
unrecoverable the moment the repository is cloned. The split doesn't have that failure mode. There's
nothing to miss, because the sensitive files are never in the repo that goes public in the first
place.

One faster fix was on the table too, and turned down for a completely different kind of reason.
GitHub offers private-repo Pages hosting on its paid tier, for around four dollars a month, which
would have made the whole question go away without touching a single file. Food diary's own author
turned it down outright, on the spot, with two words: "not pro." No technical argument followed it,
because none was needed. It was a spending decision, not an engineering one, and the project didn't
pretend otherwise.

What the guardrail actually protects now

The free-text field is still a real concern. It existed before this repository was ever considered
for public release, and it will keep existing after, because it's a property of what the app lets
someone type, not of who can see the code. It just isn't a hosting decision, and treating it as one
is the mistake this piece is actually about. It has its own design question to answer, on its own
schedule, and the fix for it won't be a line in a hosting migration plan.

The pattern generalises past one repository. The project specified a control against a threat that
sounded exactly right and had never been traced to the actual place the data flows through. It still
held up real work, however briefly. And the thing worth guarding against the whole time was sitting
in plain sight, in a directory nobody had thought to check, because the argument had already used up
everyone's attention on the door that was never actually open.

---

Originally published at thekilted.dev/protected-nothing.