Generating grime95, without leaking tomorrow's arrest

You can visit a fictional booking terminal stuck on Saturday, December 2, 1995 at grime95.com[1]Ref. 1grime95.com grime95.com. A new booking appears every day at noon Eastern, with a mugshot and charge sheet, plus an incident report. I've given Ponder County a damned filing system even though the county doesn't exist.

The browser looks like a terminal. Underneath, it's flat HTML[2]Ref. 2HTML developer.mozilla.org on GitHub Pages[3]Ref. 3GitHub Pages pages.github.com, with Python[4]Ref. 4Python python.org rendering the records before you ask for them. There's a private schedule and a public subset, and the builder makes pages from that subset. Most of the design is keeping those separate.

The private release schedule stays outside the public web root. The publisher reads it and appends due records to the public site's content.json. The public one has the same filename, but it holds published data and feeds the builder, and it's the publisher's verification artifact. The browser doesn't load it.

Generated robots.txt[5]Ref. 5robots.txt rfc-editor.org disallows /content.json. That asks crawlers nicely; it doesn't make the file private. A file in the public web root is public even if you put a polite note beside it. Tomorrow's story stays in the private schedule.

The builder doesn't choose today's record. It renders whatever you hand it. Its today value supplies sitemap dates and does nothing to gate releases. Feed it the private schedule and it can do its job perfectly while you leak the whole thing. Well, fuck.

I covered the retry ledger in Never post twice[6]Ref. 6Never post twice blog.patpadgett.com. A successful Git push doesn't prove GitHub Pages is serving the new record, so the publisher checks the live site. The generated file can be sitting right there on disk while nobody can read it.

Tomorrow's criminals have an appointment. They can wait.