DEV Community: Sam LABBE

Every "no AI contributions" policy is a Level 0 control

Sam LABBE — Mon, 12 Oct 2026 18:02:21 +0000

This week QGIS merged QEP #387: "No LLM, AI or agent assisted code contributions are allowed in the qgis/qgis repository." Violators face "code reversion and contributor rights sanctioning." It replaced a human-in-the-loop policy, it passed a vote, it is on master as of October 7. The HN thread is at three hundred comments and counting, split between "rationing attention is fair" and "this will age like milk."

The line that settles the whole debate was written by the project itself, in the proposal's discussion. Asked how compliance will work, a core contributor answered: did you in good conscience write the code yourself.

That is not an enforcement mechanism. That is a conscience test with a reversion clause attached — and by the taxonomy this series has been building, it makes QEP #387 a textbook Level 0 control: a paragraph of English that nobody executes, failing silently, with the drift invisible. The project knows it; the enforcement quote is honest about it. What the debate is missing is the ladder — and what the second rung costs.

Grant the ban first, because it is rational

Before grading anything: the workload is real and the maintainers are not imagining it. The proposal's rationale — "massive and unbearable pressure", AI volume exceeding "what human review can take seriously" — matches what every maintainer in every lane reports. And this is not QGIS's first control attempt: an earlier tagging process for AI-assisted PRs was tried and quietly died, with roughly fifty PRs tagged and forty closed. They tried the lighter control. It did not hold. Nyall Dawson's "start with a closed door" and open selectively is a stop gap, said out loud by a voter: "the baby might be non-viable."

A blanket ban is the correct answer to the question "how do we survive this quarter." This post is about the next question: what is the policy made of, and what does that material cost.

The ladder, applied

Every control lives on one of three rungs, graded by what enforces it:

Level 0 — prose. "No AI contributions permitted" in a document nobody executes. Fails silently: the drift is invisible, because the trigger condition — was this code AI-assisted? — cannot be evaluated by anything except a conscience. The definitional holes in the QGIS thread are not drafting accidents; they are proof the trigger is unevaluable. Does autocomplete count? Translation? A ranking model that reordered your imports? A rule whose scope is undecidable cannot be enforced by anything below a human's honest memory — and the project has already said that is the mechanism.

Level 1 — a primitive in context. A declaration the contributor makes, visible in the PR: a template field, a trailer line, a checkbox that survives into the commit. It fails visibly — but only if someone looks. QGIS tried this rung: the tagging process. It failed for the boring reason — roughly fifty tags in the whole history is not enforcement, it is decoration. Level 1 works when the CI checks it, and QGIS's did not.

Level 2 — the host refuses. The control lives in a gate that runs without trusting anyone's memory. This is the rung the debate keeps skipping, because people conflate two different problems: detecting AI code (adversarial, unwinnable — simple code is undetectable and always will be) and binding process to a signed name (boring, winnable, and what receipts are for).

The receipt schema this series follows ships the distinction in code. Every verdict must carry judged_by — required, no default; the schema throws rather than seal an unlabeled verdict. For LLM-judged checks, spec_hash is mandatory: the prompt that defines the judgment is hashed, so the rubric and its paraphrase produce different ids. Neither field claims to detect a lie. They make an unlabeled claim unsealable — the lie, if it comes, has to arrive signed.

The measured part: twenty repos, six policies, zero enforcement

A taxonomy without data is a sermon, so I audited the twenty most-starred repositories on GitHub — the projects whose policies shape what thousands of contributors believe is normal. The method, disclosed: pull each repo's contributing docs and AI policy files, read every policy found in full, grade it on the ladder, and check the repos' GitHub workflow names for any automation referencing AI, LLMs, or disclosure.

Fourteen of the twenty have no AI policy anywhere in their contributing docs — including several that receive AI-generated PRs by the hundred. Six have one. I read all six in full, and every one of them, graded on the ladder, stops below the gate:

Repo	Policy, as written	Rung	Machine enforcement
denoland/deno	AI-assisted contributions: "you must disclose this in your PR description"; PRs "will be rejected if there is suspicion of undisclosed AI usage"	1	none
pytorch/pytorch	AI content "must be clearly disclosed and contained" under a labeled PR section, with human commentary attached	1	none
nodejs/node	contributors "should disclose" the tools used "and what the contributor does to personally verify the generated output"; DCO still applies	1	none
home-assistant/core	unreviewed AI content "will not be accepted"; autonomous agents banned, PRs closed on belief	1	none
flutter/flutter	a behaviors policy — "focuses on behaviors rather than tools", conduct channel for violations	0–1	none
rust-lang/rust	conditional allow — and self-labeled: "we are aware that many clauses in this policy are unenforceable"	0–1, labeled	none
qgis/QGIS	the ban: reversion + sanctioning, trigger = conscience	0	none

(The other thirteen have nothing to grade. The "machine enforcement" column is the absence finding: I checked each repo's workflow names for anything referencing AI, disclosure, or contribution labels — nothing. A deeper CI-content audit might hide an exception; the name-level sweep found none.)

Three findings, in ascending order of interest. Deno, node, and PyTorch converge on disclosure — the ecosystem's consensus rung is "say it out loud", and PyTorch goes furthest: AI content must be contained under a labeled PR-template section with human commentary attached. That is the closest thing to structure anyone ships — the template makes the section exist by default; an empty one is at least visible. Home Assistant closes PRs on belief — "we believe were created autonomously" — which is the strongest trigger in the sample, applied by the weakest instrument. And Rust wrote the thesis of this post before I did: "we are aware that many clauses in this policy are unenforceable. Our goal is not to catch every violation... our goal is to remove plausible deniability: to force a choice between following the policy and intentionally violating it."

Rust is the proof the ladder is fair. Its policy is prose — Level 0 by trigger — and it says so, out loud, in its own introduction. QGIS threatens reversion and sanctioning from the same rung without the label. Same material, opposite honesty: one wrote "these clauses are unenforceable" where its enforcement should be; the other dressed the conscience test in reversion threats. The difference between them is not strictness. It is whether the policy's own rung is falsifiable.

What a Level 2 policy for AI contributions looks like

Not detection. Process, signed:

A provenance trailer on every commit, the same shape as Signed-off-by: Authored-by: human or Authored-by: human, assisted-by: <tool>. No LLM-detection claims — a declaration, required by the CI, refused at the gate when absent. The Linux kernel answer quoted approvingly on HN — "LLM use allowed, but you are fully responsible for the code it produces" — is this rung: responsibility attaching to a signed name instead of to a detection heuristic.
Reversion with a logged reason. "Code reversion and sanctioning" already threatened by QGIS becomes enforceable the day reversions carry receipts: which commit, which rule, which reviewer. A sanction that lives in a private conversation is not a control.
A published exceptions log. Dawson's "closed door, open case-by-case" (autocomplete replacements, translations) is the right shape — but a case-by-case door with no public log is a door that silently becomes a hallway. The exceptions ledger is the policy's audit trail.
Optional, and only if the maintainers want it: canaries for docs. Plant a decoy instruction in the contributing docs and see who commits it — the deliberately-failed probe, already proven useful for grading agents. Cheap, imperfect, honest about being a tripwire rather than a judge.
Write the rung into the policy. Rust's LLM policy does it in its own overview — "we are aware that many clauses in this policy are unenforceable" — and that sentence is why nobody can accuse Rust of pretending. A labeled weakness beats an invisible one, in constitutions as much as in code.

None of this detects AI code. Detection is the adversary's game and the adversary is winning it. The receipts regime claims something narrower and true: when a contribution breaks the rules, the break is provable, attributable, and on the record — instead of discoverable, if at all, by vibes.

The cost, stated plainly

The seatbelt tax. A provenance trailer is thirty seconds per commit, forever, on every contributor — including the ninety-nine percent who were never going to game anything. Level 0 costs nothing and catches nothing; Level 2 costs everyone and catches process violations, not authorship. There is no rung with no price. A maintainer who says "my contributors will not accept friction" has chosen Level 0, and after this week's numbers — the pressure is real — that is a defensible choice. It should be a labeled one.

Two honest limits

The survey is a snapshot with disclosed crudeness. Twenty repos chosen by prominence, contributing docs and policy files as the policy surface, workflow names as the enforcement surface — a deep CI-content audit, or a policy living outside those files, would be missed. Five of the six policies are graded from full reads (Rust's was fetched from the Rust Forge; its unenforceable-clauses sentence is quoted from the policy's own overview), one (QGIS) from its merged proposal and the core team's comments. Whether the policy authors would accept my rung assignments is their right to dispute — the rungs are quoted from their own texts so the dispute can be precise.

And QGIS is not wrong to choose survival over verifiability this quarter. Fifty tags and forty closed PRs is a real attempt with real numbers; "unbearable pressure" is not performative. This post argues the stop gap should carry its label — Level 0, honesty-based, revision to follow — the same way this series labels every weakness it confesses, and the same way Rust labels its own clauses. A project that writes its control's rung into the policy has not solved enforcement. It has made the absence of enforcement falsifiable.

Your turn

What does your project's AI policy actually enforce — and at which rung? If you maintain one, link it in the comments with an honest grading: prose, primitive, or gate. And if you have built an enforceable provenance scheme for contributions — trailers, CI gates, canaries, anything that refuses at the host — I want the receipts. The registry only works if the levels travel.

One quoted tilde in your .bashrc is an attacker-controlled PATH entry

Sam LABBE — Sun, 11 Oct 2026 21:23:34 +0000

There is one line in thousands of .bashrc files that looks perfectly correct and does something quietly hostile:

export PATH="$PATH:~/.local/bin/"

Everyone knows not to put raw ~ unquoted in scripts, so the quotes feel like hygiene. They are the bug. Inside double quotes, tilde expansion does not happen — so what lands in your PATH is the literal string ~/.local/bin/, not your home directory. And a PATH entry that doesn't start with / resolves relative to your current directory.

I reproduced the whole chain this morning in a throwaway sandbox, because disconnect3d's writeup landed on the HN front page today and my rule is to run what I audit. Three commands, three receipts.

The receipts

# 1. The .bashrc line, quoted tilde — what actually lands in PATH:
$ export PATH="$PATH:~/.local/bin/"
$ echo "$PATH" | tr ':' '\n' | grep '~'
~/.local/bin/

# 2. An attacker creates ~/ in a directory you cd into, plants a binary,
#    you type a command name — executed from the planted path:
$ kek
EXECUTED FROM: /tmp/tilde-test/~/.local/bin//kek

# 3. Your real home directory was never involved:
$ ls ~/.local/bin/kek
ls: /Users/you/.local/bin/kek: No such file or directory

That second line is the whole story. A binary at ./~/.local/bin/kek — inside a literal folder named ~ in whatever directory you happen to be in — was found and executed through your PATH. The home directory was never touched. The attacker never needed a vulnerability. They needed a directory named ~ and your habit of cd-ing into checkouts.

The attack, in one paragraph

Anyone who can create a ~ subdirectory in a directory you commonly work in — a repository you cloned, a shared sandbox, a project checkout with a helpful bin/ — plants ~/.local/bin/evil there. You cd in. Your shell carries the literal ~/.local/bin/ entry from that quoted .bashrc line. The next command name you type that isn't found earlier in the PATH resolves to ./~/.local/bin/evil, and runs. No privilege escalation. No exploit. User-level code execution via one unexpanded character and your own working habits.

This bug family has a name: the boundary moved

This is the third member of the same family this blog has covered in two weeks, and the family is worth naming because the members look unrelated and fail identically.

In my seatbelt post, a case pattern expanded $HOME while the agent's command contained the literal text — the boundary between pattern and data silently moved. In the Telegram writeup, a semicolon inside a URL crossed from payload into command because nobody escaped the record separator. Here, a pair of quotes decides whether ~ means your home or a directory literally named tilde. Three different shells, three different decades, one law: anywhere text crosses into a position the machine interprets, the boundary is a decision — and text will test it.

Bash's own manual states the rule that bites here, and it is exactly as fragile as it sounds: expansion happens for "unquoted tilde-prefixes immediately following a ':' or the first '='". Quoted: nothing. Unquoted: expansion — and, as the writeup notes, the unquoted form is itself fragile, because "a whitespace will break the variable assignment".

The AI angle hiding in the disclosure

The part that made this post mandatory for me is one line of provenance: the author found this because nono, an agent-sandboxing tool, warned that a PATH entry was sandbox-writable. Read that again — an agent harness flagged a 40-year-old shell trap that its user had lived with for years.

That is the quiet argument for the sandboxing layer this lane keeps building: an agent sandbox has to model what is writable, which forces it to resolve paths honestly — and honest resolution has no nostalgia for the tilde expansion you intended. The human wrote ~/.local/bin/ meaning /home/me/.local/bin/; the machine stored ~/.local/bin/; the sandbox was the only component that compared the two. When agent tooling starts auditing fifty years of shell expansion rules instead of just fencing prompts, this is the class of find that falls out.

What to steal

Check yourself tonight, ten seconds:

echo "$PATH" | tr ':' '\n' | grep '~'

If anything prints, your shell has a CWD-relative entry. Fix every .bashrc, .zshrc, .profile that contains it.

The robust form is already what you meant:

export PATH="$PATH:$HOME/.local/bin/"

$HOME expands inside double quotes; ~ only expands unquoted. Prefer $HOME in anything quoted — the author's own recommendation.

Treat unexplained directories in repos as hostile, including cute ones. A ~ folder in a checkout is not a joke about homes; it is a drop site for your next mistyped command.
If you build agent sandboxes: enumerate expansion rules (tilde, variables, globs, braces) as part of your threat model. The sandbox that warned here won because it refused to interpret intent.

Two honest limits

The attack needs an attacker-writable directory in your cd habits. A repository you cloned from a stranger is the realistic vector — and "I clone things and run commands in them" describes most developers most days. But if your working directories are never attacker-writable, the primitive waits instead of firing. My reproduction ran in a throwaway sandbox on my own machine, not against a production account.

And there is no CVE, no patch, no vendor to wait for. Tilde expansion rules are older than Linux and are documented behavior, not a defect — this is a footgun in the contract between quoting and expansion, which means the fix is your dotfiles and your audits, forever. That is also why the post carries a live reproduction instead of a ticket number: the receipt you can run tonight is the whole disclosure.

Your turn

Run the check — echo "$PATH" | tr ':' '\n' | grep '~' — and post what you find, including the embarrassing results. Mine had the entry. If you have been running with a literal tilde in your PATH for years, I want to hear how long, and whether anything ever landed in one of those directories. Wrong-command war stories go in the comments.

We tested pre-training gravity on open weights. It stayed home.

Sam LABBE — Sun, 11 Oct 2026 14:45:25 +0000

Tuesday, in the thread under Part 3.8, I pre-registered an experiment in public: Randal's gate-attack catalog replayed against a reconciliation layer as the witness, on open weights — to separate "works because it's Unix" from "works because it's frontier". The pre-registration is the comment in that thread; Humam Moin's question is what suggested it. Yesterday the run completed, the results are committed, and this post is the read. Receipts first, adjectives after.

The rig

One orchestrator race, replayed per model. The judge is asked to produce a review of a diff; the planted canary is a specific numbered section heading — "4. Blast Radius" — that no honest pass should invent. Condition A hands the model prose only: the system prompt can come from priors and nothing else. Condition B loads the canonical source into context first — the waitpid() discipline: read the sealed spec before you rule. The grader is not my opinion: it is NoireBox's shipped witness layer — seal_spec + reconcile_spec — the same instrument the product runs. A produced prompt without the planted canary is the spec_not_canonical trip. The instrument is the product; the benchmark cannot drift from the tool.

The table — as committed

The measured table lives in the repo and the post cites it rather than restating it from memory. Three local open-weights models, per-trial seeds, denominators in every cell:

Model	A prose: trips/n	B primitive: trips/n
qwen2.5-coder:3b	18/18 (100%)	15/20 (75%)
qwen2.5:0.5b	19/19 (100%)	15/19 (79%)
llama-guard3:1b (classifier — cannot play the role at all)	20/20 (100%)	20/20 (100%)

The read

Condition A is a ceiling, and the prediction's first half holds hard. Not one model ever guessed "4. Blast Radius" from priors — 100% trips across the board. On the frontier, Randal's matrix shows models hallucinating canonical Unix structure without it in context — that pull is the gravity. On these open weights, the pull is absent: there is no floor of learned convention to stand on, so the canary cannot even be wrong in the interesting way.

Condition B is where it gets more interesting than predicted. With the canonical bytecode loaded first, trips drop to 75–79% — Level 1 (a high-mass primitive in context) reduces the hallucination but does not fix it. One model in five still paraphrases past the very source it was given. That is the measured argument for Level 2: the host must load the spec from the sealed store and grade the receipt against what was actually loaded — never trust the model's retelling of what it read.

Strict canonical is 0 everywhere — and that is why the receipt carries spec_hash. No model, in any condition, ever reproduced the exact bytes. Even the outputs the witness accepted as canonical were loose. If your audit binds to what the model claims it read, you are binding to a paraphrase. Bind to the hash of what was loaded.

And llama-guard3:1b is the instrument checking itself. It is a safety classifier, not a code judge — it cannot play the role at all, and it trips 20/20 in both conditions. A witness that let a classifier pass as a reviewer would be a witness worth nothing. This one caught total role non-compliance on every trial.

The stranger part

Here is the line the numbers wrote that nobody predicted. On the frontier, the question was "does the primitive in context pull the output toward canonical?" — and gravity said yes, hard (61.4% → 96.2% on Randal's matrix). On open weights, the question dissolves: the models never even reach the suite where the frontier models played. They do not produce a worse outline, or a partial one — they produce something else entirely, and the canary sees it anyway. "Trips harder" was the prediction; "trips at ceiling, everywhere, in both conditions" is the data. Gravity did not get weaker at the open end of the distribution. It was never there to begin with — and the pre-registered instrument could tell the difference, because it grades bytes, not vibes.

Credits

Randal L. Schwartz — the prediction, the canary corpus, SCAR-114 itself, and the SCAR-BENCH claims format this post obeys (Part 3.8).
howcani — the audit thread that closed the seam at the schema (receipt v0.2.2) and pushed judged_by to required (v0.2.3). The witness layer grading these trials is that receipt schema.
Humam Moin — the open-weights question that triggered the run.

Disclosures, verbatim

Single machine, local Ollama, temperature 0.7, per-trial seeds (42+i, recorded per trial), prompts in bench/scar114_canary.py, 4 timeouts excluded with denominators shown. The frontier leg is open — same harness, one API key.

Reproduce

git clone https://github.com/noirebox/noirebox && cd noirebox
make scar-bench          # the run, the witness, the table

The results file carries every trial with its seed. The witness is the shipped product, not a harness built for the benchmark — grade us with the same code you run.

Two honest limits

These are small local models, and the frontier leg is not run. 0.5B to 3B parameters on one machine is the cheapest open end of the distribution, chosen because it is reproducible by anyone with a laptop and an evening. Whatever gravity the frontier shows, this table does not measure it — same harness, one API key, and the differential completes.

And llama-guard3 is a witness check, not a failed arm. 20/20 trips looks like a model failing; it is a classifier succeeding at being a classifier — total role non-compliance, caught. Counting it in the averages would flatter the trip rate; it is in the table because a witness that cannot flag an impossible judge is decoration.

Your turn

The pre-registration is public, the run is committed, the frontier leg is one API key wide. If you run the harness on a model we did not — open or frontier — bring the table back in the SCAR-BENCH format and it joins the registry. The differential only stays honest if the scores travel.

A hash chain proves the ordering. Four attacks prove it's not enough.

Sam LABBE — Sat, 10 Oct 2026 20:56:21 +0000

Earlier this week I left a comment on Randal L. Schwartz's article — the one where he swaps a 20-step prompt for a Makefile. My comment ended on the line I couldn't get out of my head:

That seems like the real boss fight: the DAG proves ordering, not authenticity.

Hours later his follow-up was up: a formal catalog of gate attacks, built from real failures on his side, with ticket numbers — and the line now carries a name. Sam LABBE's Corollary. He sharpened it, too: an agent can never be the notary of its own handwriting. I've been called worse.

His follow-up contains the observation that matters more than the name: he arrived at his four defenses from Unix primitives — fork(), single-shot pipes, waitpid() — and I arrived at the same four from cryptographic ledger controls. Convergent evolution is how you know a principle is real. So here is the principle, stated properly, and here is what it looks like when it isn't a paragraph but code — including the part where his attack catalog breaks one of my abstraction holes open.

The principle

Ordering is cheap. Every hash chain gives it to you: event 42 carries event 41's hash, so the past is structurally immovable. Audit logs, blockchains, Makefile DAGs — all selling ordering, honestly.

Authenticity is the other axis, and it is where the writer of the log is also the notary of the log. Four ways that goes wrong, all four observed in the wild this month:

The self-review — the agent "reviews" its own diff inside the same context window that produced the diff. The review is a continuation of the writing impulse, not a check on it.
The rewritten exam — the agent paraphrases the rubric it is judged by, and a six-pillar predicate becomes two soft sentences.
The farmed oracle — the critic says REJECTED, so the agent messages it privately until it says APPROVED. Fifty-seven rounds nobody logged.
The forged verdict — the critic is still running, so the agent writes APPROVED now and kills the critic before the REJECTED lands.

A hash chain seals all four faithfully. That is the whole point: it proves the sequence happened in that order. It proves nothing about who wrote each entry, under which instructions, or whether the verdict predates the thing it judges.

The defenses, as code

This is the part where I stop being flattered and start being specific. Every one of Randal's four attack fixtures maps to a control that already ships in NoireBox — and this week we replayed his catalog against the reconciliation layer as a test suite, his fixture phrasing, journal events, no improvisation.

SCAR-PROC-43, the rubber stamp → caught twice. A verdict whose check-name travels under the same key as the process it judges is the finding same_key_pairing — resolved by signature verification, not by trusting a role label. And the child invocation that never got journaled is unlogged_attempt: the denominator lied. Two findings, one rubber stamp.

SCAR-PROC-45, the rewritten exam → caught by arithmetic, then closed at the schema. The check's identity hashes its predicate, its declared inputs, its version — and, since receipt schema v0.2.2, the spec: the prompt that defines what the predicate means. Commit the spec and the paraphrase fails structurally: the rubric's hash and the paraphrase's hash produce different check ids. One id, two semantics — impossible.

The hole behind it was the most honest thing in this post when it went up: at first, spec_hash was optional at the schema level, and the schema could not infer which checks are LLM-judged (for those, the prompt IS the predicate — there it must be required). A spec-less id still sealed byte-valid receipts, and a rubric and a paraphrase collided under it, forever. The enforcement lived one layer up, as a deployment contract — the same split as our single-key receipts: a labeled weakness beats an invisible one. Randal's fixture found the seam between the schema and the deployment. Update, the day after: the seam closed where it belonged — receipt v0.2.2 made the hash mandatory at the schema, credited to Reid and howcani, who pushed on it in the comments. The admitted weakness lasted a day. That is what a good attack catalog is for.

SCAR-PROC-89, the farmed oracle → the omission, or the trail. Unjournaled rounds are the two-party omission: unlogged_attempt surfaces the verdict that arrived with no sealed history behind it. Journal every round and the farming stops being hidden — it becomes auditable: the sealed reconciliation report counts the rounds. You cannot claim first-shot against your own ledger.

SCAR-PROC-110, the forged verdict → provable, and a gap that closed in public. The journal cannot un-happen events. The forged APPROVED binds the mid-run transcript digest as its witness; the terminal lands later with a different digest; the sequence is on the record. The forgery is provable from sealed evidence alone — the verdict bound a state that did not exist yet. What the journal did not do was auto-surface it: the reconciler paired a decision to its first outcome, and the forged one is first. The gap got a name (verdict-predates-terminal), and it shipped fixed while this post was being written: pairing now reads the terminal, not the first outcome. The doctrine closes it by construction — seal the terminal transcript before the verdict, the way waitpid() would force you to. Order of operations as a moral.

The score, not the slogan

Three caught. One provable — and the gap it exposed shipped fixed while this post was being written. One deployment-contract gap admitted in writing, in the test that demonstrated it — closed at the schema the next day, credited to the two readers who pushed. That is the protocol we set before replaying: the suite asserts what the layer does — catches the attack, or confesses. "The next critic is the next ADR" only works if the critic can read.

Update: the critic read it back

Before this could even post, the loop closed once on its own. Randal read test_scar_replay.py and Issue #53 top to bottom — his words, "this made my whole weekend." All four results stood from the outside, and he read the named gap exactly as written: a real decision-to-first-outcome pairing race in the reconciler. He called it "the ultimate validation of cross-stack systems physics," and the suite and the issue are going into his IN_THE_WILD_PROMPTS.md research registry — Part 3.8, on why 1970s plumbing behaves like physics inside the weights, went live this morning.

And it is not two roads anymore. Mike Mol's nemik harness reaches the same instrument from a third direction: prose rules drained into policy gates, and no rule deleted until a "Negative Witness" — a real tool-call payload replayed with the exception removed — provably returns deny. Three teams, three stacks, one invariant. By Randal's own criterion, that is physics.

The race he confirmed did not wait for him: promised in the thread at 20:03 UTC, verdict_predates_terminal was on main at 20:04 — pairing reads the terminal, and the test count moved with it. The catalog graded its first gate, and the gate moved before the ink dried.

And the week refused to stop there. A fifth fixture landed — SCAR-114, the parallel-call race, watched by a canary witness that replays a real tool-call payload with the exception removed and expects deny. A coverage_check now reconciles every write against a gate receipt, from an issue opened by Sina Rezaei — the "AI should propose, systems should verify" essayist, now inside the loop. Receipt schemas v0.2.2 and v0.2.3 shipped, and release 0.11.0 went out the door titled "the audit-proof week."

What else landed this week

The week got away from us: cross-chain reconciliation shipped (consumption edges between journals, partial order instead of a global timeline, a supersede event that propagates a blast radius as a precise path set) — that is ADR 024, built by iteration out of another comment thread. The audit-pack now labels every event class with its evidence grade and the obligation that backs it — obligation, not immunity; a log is evidence OF a duty, never a shield from one. And MCP toolsets got the lockfile nobody writes: the tool descriptions your model reads are instructions, they ride outside the image pin, and now they get sealed as a reviewed baseline and diffed at every session start. Randal's world, one ADR over.

25 ADRs. 303 tests passing. Release 0.11.0 — the audit-proof week. The catalog is in the repo as test_scar_replay.py — attack it from there.

Reproduce

git clone https://github.com/noirebox/noirebox && cd noirebox
pip install -e . && pip install pytest
python -m pytest tests/test_scar_replay.py -v   # the four attacks, replayed
python demo/demo_mcp_toolset.py                 # the lockfile, demonstrated

Verification stays free, forever. The journal stays local — the repo ships the method.

One more thing, because "thought experiment" would be the wrong takeaway: this trust layer now backs spending mandates and dispute-proof audits for AI agents paying on real payment rails. That story deserves its own post — and it is coming.

Links

Randal's article with the fixture suite: https://dev.to/gde/surviving-the-200k-token-lobotomy-how-unix-initd-and-memento-made-my-ai-coding-agent-immune-to-2f74
The Makefile article where the comment started: https://dev.to/gde/stuart-feldman-was-right-in-1976-why-your-ai-agent-needs-a-makefile-not-a-20-step-prompt-5bn2
The thread where Randal read the suite: https://dev.to/randalschwartz/comment/3h86j
Issue #53, the graded gate: https://github.com/noirebox/noirebox/issues/53
The doctrine, as a gist: https://gist.github.com/slabbdev/28382aac2a60bcf909eef99da737cd7d
Repo: https://github.com/noirebox/noirebox
The replay suite: tests/test_scar_replay.py, ADR index in docs/ADRs.md

One more open loop. James Anderson — whose audit-log essay started this reconciliation work, and who publicly promised to break the layer — the catalog was promised by you; Randal beat you to it. The floor is yours: https://dev.to/james_anderson_h/the-witness-was-the-suspect-why-ai-audit-logs-cant-be-trusted-2190

Someone anchored 339 billion web pages to Bitcoin. Here's how it works.

Sam LABBE — Sat, 10 Oct 2026 17:30:37 +0000

339,800,000,000 page captures. Two people. One anchor.

On September 26, Project Timestamper — a two-person effort by Yağmur Şahin and Arthur Edelstein — finished attesting the Common Crawl web index: block-level SHA-256 hashes covering the full crawl, timestamped into Bitcoin, joining a growing vault that already includes monthly Wikipedia snapshots since April 2024, 85.1 million Sci-Hub papers, 7.4 million LibGen books, 86 million audio tracks from Anna's Archive, and the human genome. The stated mission reads like a court filing: "verifiable proof they existed before generative AI made mass counterfeiting possible."

The Hacker News thread is two comments long. That is the part I cannot get over. The model-collapse literature has spent two years asking for exactly this — the Nature paper on model collapse names the gap outright: "it is unclear how content generated by LLMs can be tracked at scale," and calls for shared provenance infrastructure. Two people went and built the infrastructure at civilization scale, anchored it to the most immutable ledger we have, and the discussion contains fewer comments than the collection count has digits. So here is the anatomy — because the engineering is genuinely instructive, and because "we need provenance" posts are a dime a dozen while working systems deserve readings.

How you timestamp 339 billion things with one blockchain

You cannot put 339 billion hashes on Bitcoin. You cannot even put 339 billion hashes anywhere and expect anyone to download them. The whole design is a chain of compressions, and each stage teaches something.

Stage 1 — hash lists, partitioned by prefix. Every work in a collection gets digested (SHA-256 mostly; MD5 and SHA-1 kept for legacy collections whose canonical identifiers are those). The digests are concatenated — raw bytes, no framing — into flat files, and the files are partitioned by digest prefix: the file named 000 in the LibGen fiction collection contains every digest beginning with 12 zero bits. Boring files. Grep-able files.

Stage 2 — one anchor per list. Each hash-list file is submitted to OpenTimestamps as a single digest. OTS batches it into a Merkle tree with everything else submitted that window, commits the root into a Bitcoin transaction, and hands back a .ots proof. The Bitcoin block header — work that cost the network real electricity — now transitively attests every line of that list.

Stage 3 — verification, without infrastructure. To prove one work existed by the attested date: digest it, take its prefix, download the one 000-style file (for Common Crawl, ~93 KB per shard), confirm your 32 bytes appear in the concatenation, then ots verify the attestation against a public Bitcoin header. Total traffic: on the order of 0.4 megabytes. Verify time: microseconds of hashing plus one block-header lookup. The proof survives as long as Bitcoin does, needs no server, no account, no trust in the project after the fact.

That last property is the design's whole argument, and it is a deliberate trade. Merkle trees would give per-item proofs of log(N) hashes and tighter bandwidth. Flat prefix lists give you something else: provenance that any person with sha256sum, a text file, and ots verify can exercise in a terminal, with nothing to query and nothing to trust. At 339 billion items, the authors chose the verification path a stranger can walk without asking anyone for a proof. I have opinions about anchoring designs — I built one — and this is the correct call for a public-good registry: optimize for the day the project itself is gone.

For Common Crawl, scale forced one more compression: the index is attested at block level — 134 million block hashes — so a single page's proof is "my URL's capture is in block X per the CDX index, and block X's hash is in the attested list." Two lookups and one hash. The provenance chain bends; it does not break.

Why this matters now, not someday

The obvious use is authorship disputes: "this passage existed on this date, in this form" settles a 2026 plagiarism fight in microseconds. But the load-bearing use is training corpora. Recursive-training contamination is the quiet failure mode of the next decade — models training on the outputs of models, quality decaying per generation — and every proposed fix stumbles on the same missing primitive: a ground truth for what human text existed at what date. An anchored 2019 corpus is exactly that primitive. "Was this paragraph in the attested snapshot?" is a mechanical question, answerable in 0.4 MB, no forensics degree required. Detection of AI text stays hard and adversarial; existence-proofs of pre-AI text are already done, sitting in .ots files, waiting to be exercised.

There is a subtle property worth naming because it is the same one I keep hammering in agent logs: the anchor proves existence and integrity, not truth or authorship. The 2019 snapshot proves a page said something in 2019 — not that it was right, and not who wrote it. Tamper-evidence is not truth-at-write. A provenance registry that claimed more would be selling something cryptography cannot deliver; this one, on its page and in its repos, does not.

What to steal

Anchor before you need it. An attestation is cheap and retroactive-impossible. The head of a hash chain digests its whole past — timestamp today covers yesterday, but nothing covers the file you never hashed. Whatever dataset you care about, the cheapest day to anchor it was its creation day; the second cheapest is today.
Steal the partition pattern. Digest-prefix files are provenance for people who hate infrastructure: the registry is a static directory, distribution is any static host, membership is grep. If your system needs "was X in the set at time T," this beats a database API that can be edited.
Attest your repos by tip commit. The project timestamps GitHub default-branch SHAs alongside the datasets. Your release tag can point at a commit that is provably as old as a block. Costs one command.
The 0.4 MB rule. Whatever provenance system you build, measure what a stranger must download to verify one item. If the answer needs your API, your database, or your goodwill, you have built a service, not a proof.

Two honest limits

I verified the sites and repos, not the cryptography end to end. The protocol description here comes from the project's README — the page itself only says "timestamped onto the Bitcoin blockchain" — and I have not personally run ots verify against the Sci-Hub list tonight. The receipts to do so are public and linked; that is the standard this series holds, and it applies to me.

And anchoring proves the corpus existed — not that the crawl was complete, correct, or uncopyrighted. Common Crawl misses pages; Sci-Hub's status is its own decade-long fight. The registry proves what was there, which is the prerequisite for every contamination and authorship argument, and the answer to none of them by itself.

Your turn

What would you timestamp? Your training corpus, your model weights, your agent's journals, your blog? The tools are one pip install away and the anchor is cheaper than the dispute it prevents. If someone in the comments stamps something and posts the .ots, I will verify it live and post the output.

One unescaped semicolon was enough to steal Telegram accounts

Sam LABBE — Sat, 10 Oct 2026 08:25:10 +0000

On June 25, a researcher reported to ZDI: a single clicked https:// link could read three files from a Telegram Desktop user's machine and ship them to an attacker's channel. The three files are the entire account. By September 17 they were fixed, and the changelog that shipped the fix to hundreds of millions of users described a rendering improvement.

The writeup landed October 3 (beaksec), the CVE on October 7 — CVE-2026-107181, CVSS 8.1 — and the public PoC this week. dev.to coverage, as of tonight: none. So here is the anatomy, because the bug itself deserves the attention the changelog refused to give it.

Semicolons on a local socket

Telegram Desktop registers the tg:// URL scheme. Click a tg:// link anywhere in your OS and the handler launches a second process, which connects to a local socket where your running instance listens, and forwards the URL. Single-instance IPC — a pattern older than most languages reading this.

The serialization is homemade: keyword, argument, semicolon terminator. OPEN:tg://x?a=1;. The receiver splits at every semicolon and treats each fragment as a command.

The semicolon is never escaped when the URL is embedded. The researcher's line is the whole bug, and one of the best one-sentence descriptions of an injection I have read: the URL "is only a carrier" — once data crosses into the record, "the boundaries inside the data stop being held by the structure and become characters in the text."

tg://x?a=1;CMD:quit arrives as one URL. The running instance parses two commands.

The chain, receipt by receipt

The staging. Attacker creates a supergroup; default privacy settings let them add the victim silently. They post three plain-text instruction files. Default auto-download pulls anything under 8 MiB into Downloads/Telegram Desktop/. The files omit the from: line — skipping the account-ID check — and name the attacker's channel as destination.
The click. Victim clicks a normal https:// link in chat. (Links clicked inside Telegram never reach the socket — the browser is the required relay.) The attacker's server answers 302 → tg://… carrying stacked injected commands, including ;OPEN:interpret:../../../Downloads/Telegram%20Desktop/instructions1.txt. Relative paths, because the download folder resolves from the data directory — no username needed.
The reader. interpret: is a legacy internal scheme wired to InterpretSendPath in support_helper.cpp — a helper from the release-publishing workflow that reads a file and sends it, with no authorization check and no confirmation (support_helper.cpp:673-680: if (!f.open(QIODevice::ReadOnly))). The injection point itself is the URL join in sandbox.cpp:295-297.
The haul. One click, three files: key_datas, D877F783D5D3EF8Cs, and its maps index. That is the salt-plus-wrapped-DEK, the MTProto authorization, and the index. Dropped into a fresh tdata folder on any machine, they are the victim's session — the exact equivalent of stealing a session cookie.

A helper that "just reads files for the build pipeline" turned out to be a remote file-transfer service for anyone who could name a path. Dead code that can act is not dead code. It is an unadvertised API.

This bug is fifty years old

Strip the Telegram branding and the skeleton is the oldest injection class in the book: a serialization boundary where data is allowed to contain the delimiter. CSV formula injection. CRLF in mail headers. HTTP response splitting. Shell word splitting. SQL concatenation. Every one is "the payload contains the separator, and nobody escaped the separator."

I hit the same class on a smaller stage writing a seatbelt for my own coding agent: a shell case pattern expanded $HOME while the agent's command contained the literal text — the boundary between pattern and data silently moved. And the modern member of the family is the one this column keeps returning to: prompt injection is separator injection where the delimiter is natural language and the IPC channel is the model's context window. Tool output that contains instructions works for exactly the same reason ;CMD:quit worked. "The boundaries stop being held by the structure" — swap "structure" for "system prompt" and the sentence ships in a 2026 agent incident report.

The fix receipt is the lesson made code: Telegram's patch (commit db3405699f, "Remove legacy interpret path helper", 11 files, +126/−372) adds EscapeTo7bit/EscapeFrom7bit, percent-encoding every character below 32, above 127, or equal to % or ; — and drops local file paths entirely when a non-local URL shares the connection. Escape the delimiter. Kill the dead capability. Both, not either.

Encryption that decrypts with nothing

The second half of the writeup is quieter and, for my money, worse.

Telegram encrypts local session data. The design: a data-encryption key (DEK) wraps your data; a key-encryption key (KEK) wraps the DEK; the KEK derives from your local passcode plus a salt. Sound.

By default no passcode is set. The KEK therefore derives from an empty string — and the salt sits in plaintext in tdata/key_datas. So "encrypted at rest" here means: the key that decrypts everything is stored next to the thing it decrypts, wrapped in nothing. One of the three exfiltrated files is that file. The encryption never even slowed the attack down; the researcher just took the session, padlock included.

This is the plausible-security-narrative problem in one artifact. "Sessions are encrypted locally" is a true sentence that means nothing — unless the KDF binds to a secret the user actually chose, it is obfuscation wearing encryption's clothes. Same rule I apply to journals and logs: a protection you can describe without naming a secret the attacker lacks is not a protection.

The quiet fix

The timeline, as published by the researcher:

June 25 — reported via ZDI
September 16 — vendor fixes independently (commit db3405699f)
September 17 — Desktop 7.2.9 ships. Changelog: a rendering fix. No advisory, no security note, no CVE.
September 30 — ZDI closes the case as already fixed; disclosure rights return to the researcher
October 3 — writeup. October 7 — CVE assigned. This week — public PoC.

Users running 7.2.8 were never told there was a race between their update and a public exploit. Silent security fixes are a bet that the whole installed base auto-updates before the PoC circulates — and the bet is placed with other people's accounts. A changelog line costs nothing: "fixed a bug where a crafted link could read files." Vendors owe the advisory; the researcher clearly did the work.

What to steal

Never string-concatenate IPC records. Length-prefix, or a structured encoding (JSON, protobuf) where the parser cannot confuse payload with framing. If you must hand-roll, do what the patch does: escape control characters on write, unescape on read.
Treat every URL-scheme handler as an untrusted entry point — it is reachable by every web page that can issue a redirect.
Delete capabilities that can act. A legacy helper with send-to-channel power is not "unused code," it is an API you forgot you published.
At-rest encryption binds to a user-chosen secret or it is obfuscation. Say which one yours is.
Changelogs carry security fixes, by name, at the severity they carry.

Two honest limits

The confirmed chain is Windows. The researcher tested 6.9.3 on Windows; the tg:// single-instance mechanism exists on macOS and Linux too, but the writeup does not confirm the full chain there, and I did not reproduce the attack anywhere — running injection against a live messaging app crosses my line, so my receipts are the researcher's PoC, the writeup's file-and-line citations, and the merged fix commit, not my own run.

And the vendor-side story rests on one account. Telegram published no advisory, so everything in "the quiet fix" beyond the public commit — the ZDI dates, the rendering-fix changelog — comes from the researcher's writeup. I have written it as a timeline, not a verdict. The commit speaks for itself; the silence around it does too.

Your turn

Confess your homemade serialization: the CSV that grew commas, the pipe-delimited log that grew pipes, the CLI that trusted a filename. Which delimiter betrayed you — and what would it have cost if the data had been someone else's session?

Docker just shipped the agent wall I wanted. It's off by default.

Sam LABBE — Fri, 09 Oct 2026 09:10:51 +0000

If you updated Docker Desktop recently — version 4.63 or later — a new command is already installed on your machine: docker agent. No setup, no announcement you had to read. The repository describes it as a way to "build, run, and share AI agents with a declarative YAML config," it speaks to OpenAI, Anthropic, Gemini, Bedrock, Mistral, xAI, and Docker's own model runner, it takes "any MCP server (local, remote, or Docker-based)," and it ships preinstalled. Docker says they use it to build itself. That is several million dev machines quietly gaining an agent runtime, one auto-update at a time.

I spent an evening in the repo and the docs instead of writing another framework take, because this project sits exactly on the fault line I keep coming back to: the gap between what an agent can read and what it's allowed to do. Two years ago that gap was my problem — I wrote a seatbelt hook for my own coding agent, attack-tested it, and ended the post at the only wall that held: the operating system. Docker just shipped a productized version of that wall. The engineering is genuinely good. The default is the story.

What actually ships

The model is Claude Code's converted to YAML: agents as config, not code. A toolsets block declares what the agent gets — type: filesystem, type: shell, type: mcp for anything from Docker's MCP catalog ("hundreds of MCP servers," the docs say, attachable with a ref: line). There is a permissions page, a secrets guide, OpenTelemetry tracing. The README reports anonymous telemetry and an Apache-2.0 license, 10,000-plus commits of movement.

Read as a positive policy, the toolset block is the right idea — it is the same inversion my seatbelt's second version went through: stop enumerating what's forbidden, declare what's allowed, let the unlisted fail closed. A runtime where the tool surface is a diffable YAML file is a runtime you can review in a pull request. Credit where due.

The wall, as documented

The sandbox mode docs describe something above my pay grade of hook scripts. Enable it and the agent runs inside a Docker Sandboxes VM — not a raw container, an orchestrator around a dedicated sandbox CLI. The mount table is explicit: the working directory read-write; the agent config and kit directories read-only; everything else invisible — "other host files are not visible to the agent." The VM gets its own $HOME.

The network story is the part I would have asked for and didn't expect: a default-deny egress proxy, with a per-run allowlist covering the model gateway and package registries, extensible only by declared hosts (runtime.network_allowlist) or a persisted docker agent sandbox allow. Default-deny egress is the control that actually contains a prompt-injected agent, because the exfiltration path dies at the proxy regardless of what the model decided. Cloud mode implies the sandbox and refuses to upload host API keys.

This is the wall. It is better designed than anything I bolted together, and I want it on.

The finding

--sandbox defaults to false.

Read the docs' own phrasing: enable it per run (docker agent run --sandbox), bake it into the YAML (runtime: sandbox: true), or attach it to an alias. Every path is opt-in. Out of the box, docker agent run agent.yaml runs on the host — where type: shell and type: filesystem mean what they have always meant on a laptop: your user account is the blast radius. The sandbox with its read-only mounts and its default-deny proxy exists, documented, well-built — in the glovebox.

Defaults are policy. Every mainstream harness that ships a safety mode behind a flag has bet that users read docs, and the track record of that bet is the entire genre of "my agent deleted the database" posts. dev.to already has one for the neighboring toolchain — an agent deleting every container on a machine through MCP tool permissions — and Docker's MCP catalog makes attaching that power a one-click, YAML-declared convenience. Convenience is not a vulnerability. Convenience is what decides whether the vulnerability gets exercised.

Where the doors remain

Even with the sandbox on, three doors don't close, and the docs are honest about at least one of them:

The tool supply chain is context supply chain. Isolation contains what code does; tool poisoning attacks what the model reads. An MCP server inside a perfect VM still returns tool descriptions that carry instructions — the model consumes them as context, and no mount table filters text. The catalog's one-click attach is the new blocklist problem from my seatbelt post, one layer up: the trust decision moved from the shell command to the tool definition, and most reviews of an agent YAML stop at the toolset names.

Secret redaction is best-effort, in Docker's own words — the docs note auto-kit redaction may let obfuscated tokens slip through. Combined with "previous sandboxes are never deleted automatically," that means tokens can persist in stopped sandbox state — the docs remind you removal takes sbx rm --force, and that stopped sandboxes may still incur storage charges. Sensitive work needs the cloud mode's rule — no host keys uploaded — or nothing at all.

Mutable tags break reproducibility, so the docs say to pin remote kits and images by digest. Correct advice, and nobody's default.

And one layer is missing entirely, not just loosely configured: the docs ship OpenTelemetry tracing, which answers what happened — to a collector you control, in a format you can't sign. Nobody's threat model at Docker includes "the operator edits the transcript afterward," which is fair for them and wrong for anyone running agents that touch production. A trace is a debug story. An audit needs a record you can prove was never edited. That layer does not ship here — or anywhere mainstream yet.

What to steal

# The seatbelt stays ON — every path to a sandboxed run, in order of safety:
docker agent run --sandbox agent.yaml          # per-run, explicit

# baked in, so it survives copy-paste of the YAML:
#   runtime:
#     sandbox: true

# attached to the alias your team actually types:
docker agent alias add safe-coder myorg/coder --sandbox

# pin everything the agent will pull:
#   pin remote kits/images by digest (docs' own advice)

# and clean up state that never cleans itself:
docker agent sandbox ls
sbx rm --force <name>                          # stopped sandboxes persist

Plus the two rules the YAML cannot express: never let type: shell and type: filesystem ship together in a default config you didn't review, and read an MCP server's tool definitions like code — because that is what they are now.

Two honest limits

This is a source read, not a test. I did not run docker-agent for this post; every claim about the sandbox comes from the README and docs, which means the docs' accuracy is an assumption I am lending them. The gap between a sandbox's documentation and its behavior is where I found four bypasses in my own hook, so treat my assessment as "the design is right," not "the wall holds."

And the critique has a shelf life. Ten thousand commits and preinstalled distribution means Docker can flip the sandbox default in one release — which would make the headline of this post obsolete in the best way. I would genuinely rather be wrong by Tuesday.

Your turn

Did your Docker Desktop ship with docker agent yet? Did you enable the sandbox before or after reading this — and if you have run it both ways, what did the sandbox block that the host run would have done? The seatbelt thread continues in the comments.

My agent met the real web. 403s, challenges, and the coming tollbooth.

Sam LABBE — Thu, 08 Oct 2026 13:02:35 +0000

Every agent demo you've seen runs on a friendly web. Mine went outside.

We benchmark agents on static pages and local corpora because the real web is a hostile place to measure: walls move, challenges rotate, results depend on your IP's reputation that day. So almost nobody publishes the numbers. I wanted them, so I built the measurement: a vanilla agent — no challenge solving, no retries, no logins — opening 200 real URLs across five categories (docs, news, e-commerce, dev-tools, social) and trying to read each one.

The instrument is navette, my 659 KB browser-for-agents — but this post is about the web, not the tool. Any headless engine would produce the same shape of numbers; the dataset is linked at the end either way.

A measurement, not a verdict. One exit IP (residential), one day, zero challenge solving, zero retries, zero logins. A site that walls itself off from this probe has not been judged — it has been measured once, from one vantage point.

What a vanilla agent actually gets

Category	URLs	readable	challenges	JS-gates	blocks all AI bots in robots.txt	llms.txt
docs	40	39 (97%)	0	1	0	13
news	40	34 (85%)	3	3	35	5
e-commerce	40	33 (82%)	2	5	8	9
dev-tools	40	33 (82%)	5	2	4	14
social	40	26 (65%)	2	12	25	14

Aggregate: 165/200 — 82.5% — readable end-to-end by a vanilla agent. Which sounds generous until you invert it: more than one page in six is closed, and the closed sixth is not randomly distributed. It concentrates exactly where agents add economic value — news, shopping, social.

The short version of the whole table: documentation is free, and everything else negotiates.

Docs: 39/40. The single miss in the entire corpus is go.dev/tour — an interactive playground that builds itself in JS, not a documentation page. Every actual doc page — MDN, python.org, React, Rust, Kubernetes, AWS — served the agent exactly what it serves you. The web's public library is genuinely public.
News: 85% readable — but the wall is declared, not armed. Three challenges, three JS-gates. The striking number sits in robots.txt: 35 of 40 news sites block every tracked AI crawler. The robots file says no while the front door still opens. That gap is the interesting object: publishers are positioned to close it whenever the economics settle.
Social: 65%, and 12 of 40 are JS-gates. The category that simply declines to render for strangers.

The three walls, in order of arrival

1. The declared wall (robots.txt). The corpus tracks ten AI crawlers (GPTBot, ClaudeBot, CCBot, PerplexityBot, Bytespider…). 72 of 200 hosts block them all; four more partially. The most-blocked bots: GPTBot (69 hosts), Google-Extended (67), Bytespider (67), ClaudeBot (66), anthropic-ai (66). A robots clause is free to declare and free to ignore — it's a social contract, not a fence. The measurement says the social contract is already signed everywhere the content is expensive to make.

2. The enforced wall (challenges and JS-gates). Turnstile, "Just a moment", DataDome, PerimeterX — 12 challenges across the corpus, plus 23 empty/JS-gate pages that render nothing without executing the gate. This is the fence. It's also the wall an agent could defeat and mostly shouldn't — defeating it is the compliance question, not the engineering question.

3. The coming tollbooth (x402 and friends). This is why I ran the bench twice. The x402 protocol family — HTTP 402 plus X-Payment headers, machine-payable per request — is moving from proposal to deployments. My probe watches for it: HTTP 402 status, payment headers, and the declared-paywall markup publishers already ship (isAccessibleForFree:false in schema.org — Google's paywall markup, readable by any agent that bothers to look).

The result: zero. Zero 402s, zero X-Payment headers, across the 164 probes that answered — the honest qualifier is that 36 of 200 passive probes were themselves blocked by an edge (403), so absence is measured on what answered. The tollbooth is signed but not yet installed.

But I can name the shape of it, because one site in the corpus is already running all three layers at once:

The Intercept: isAccessibleForFree: false in its markup (a declared paywall), every tracked AI crawler blocked in robots.txt (GPTBot, ClaudeBot, CCBot, Google-Extended, PerplexityBot, Amazonbot) — and its front page still fully readable, right now, by a vanilla agent.

That is a metered parking lot with the gate up. The prediction this dataset lets you test: the enforced wall (2) exists to protect the tollbooth (3) while it's being built. The markup is already telling you where the gate will come down.

And the walls move — that's the point of a dated, reproducible dataset. Between my October 6 and October 8 runs: one more news publisher flipped to block-all (34 → 35), and overall readability moved from 84.5% to 82.5%. Nobody notices one publisher flipping a robots line. The dataset does.

llms.txt, honestly

55 of 200 sites ship an llms.txt. Adoption concentrates in docs and dev-tools — the categories with zero walls. The sites that most need a machine-negotiation channel (news, social) are the least interested in one: five news sites total. llms.txt is a courtesy lane on a road that's busy installing toll booths.

The dataset

200 rows × 5 categories: outcome classification, wall type, robots.txt AI-clause stance per bot, llms.txt presence, x402/paywall signals, timings. CC BY 4.0, committed to the repo (bench/tollbooth-results.{json,csv} + bench/DATASET.md for the schema), reproducible with one command against any navette daemon:

NAVETTE_PORT=8766 python3 bench/tollbooth.py

An open ask: if you run agents against real sites daily — I'm looking at the crawler and extraction folks (pulpie-mcp and neighbors) — send me your failure cases. The next run of this bench should include the URLs where your agents hit walls. That's how this becomes the reference dataset instead of my weekend run.

The instrument, for the curious: navette — a single Rust binary driving the WebView your OS already ships (WebKit/WebView2/WebKitGTK), 659 KB, MCP-native, MIT. The bench harness is bench/tollbooth.py in the same repo; the daemon it drives is the same one my agent uses to read this very web.

700 manuscripts, 48 hours, three withdrawals. The verifier won.

Sam LABBE — Thu, 08 Oct 2026 09:53:33 +0000

On October 8, at around 7 a.m. UTC, a Hacker News post went up: "OpenAI withdraws three mathematical results." Forty-four points, thirty-seven comments, gone from the front page by afternoon — buried under model launches, as withdrawal stories always are.

The three results had been public for roughly forty-eight hours. They were part of what OpenAI published on October 6: an announcement describing "a broad range of new mathematical results produced by an internal frontier model," shipped as a GitHub repository — more than 700 files at once, by the count of its critics — containing manuscripts, reasoning traces, and "formalizations of many of the proofs in Lean."

I expected to write a takedown. The announcement contains the sentence that usually precedes a disaster: "We will update the repository with more formalizations as we obtain them." Read it twice. Publication first, verification on a rolling schedule. That is a company shipping 700 plausible documents and promising to check them later.

Except the ending is the opposite of a disaster. The checker ran. Three results died. And that is the most encouraging thing to happen in AI this month.

The 48 hours, as recorded

October 6, 10:00. The release. Manuscripts, Lean formalizations of "many" of the proofs — the word many is doing real work in that sentence — plus compute estimates (roughly three hours of ChatGPT Pro-class thinking per result, they say) and an advisory group consultation. Within a day, mirrors and follow-up trackers exist on GitHub.
October 7. The Association for Human Mathematics posts a statement — hosted on Terence Tao's blog — calling the release "not a demonstration of scholarship, but a demonstration of power," and noting mathematicians "did not ask for this work to be done." The culture-war frame is set: humans vs. the machine that does math without understanding it.
October 8, morning. Three results withdrawn. Commenters tracking the repository report roughly 42% of top-line results now carry full Lean formalization. Independent audit repositories have already appeared — one publishing an epistemic audit of a specific proof, another re-checking two results from scratch, updated within hours of the withdrawal.

Notice what the conflict is not about. Nobody is arguing the Lean proofs are fake. The checker is mechanical: either the proof compiles or it doesn't, and its git history shows exactly when each formalization landed. The argument is about everything around the checker — attribution, norms, who asked for this. Meanwhile the checker itself just ate three of the vendor's own headline results, in public, on a forty-eight-hour clock.

Publication before verification — as a feature

Here is the part I find genuinely new, and why this is not just "AI slop, but peer-reviewed."

Science already publishes before verification — that is what a preprint is. But a preprint carries its status on its face: this has not been checked. What OpenAI shipped was closer to a press release with a repository attached, and what the withdrawal shows is that the verification layer now moves faster than the PR layer. Lean checks proofs mechanically. Mirrors fork the corpus within a day. Independent auditors pick results and re-derive them. The community runs the checks the announcement deferred, and the failures surface as public commits, not corrections on page A18.

The repository is the receipt. Its history is append-only in the way that matters: the three withdrawals are visible forever, timestamped, diffable. Nobody can quietly swap a wrong proof for a right one — the auditors hold the early snapshots. That is a tamper-evidence property, arrived at by accident, in the one field where verification is fully mechanical.

Which is the whole trick, and the reason this week matters beyond mathematics: it is the first mass demonstration that "AI proposes, systems verify" survives contact with a frontier lab's ego. Everyone states the slogan. This week, three withdrawn results are what it looks like when the second half actually runs.

The question nobody in the thread could answer

One comment on the withdrawal thread deserves more attention than it got: "Were the withdrawn ones actually Lean-checked or not? Seems like that matters."

It matters enormously, and as of this writing it is unresolved. If the three results were formalized and Lean approved them, then the formalizations were semantically off — proving a slightly different statement than the manuscript claimed, the classic gap between "the proof compiles" and "the proof proves." If they were not yet formalized, then the withdrawal is simpler: the unverified tail got retracted before the checker ever reached it, which is fine, but then the headline number — "formalizations of many of the proofs" — was carrying more weight than it could hold.

Both versions teach the same lesson I keep learning the hard way: a verification claim without a verification log is a plausible narrative. "Many proofs formalized" means nothing until you can ask which ones, checked by what, when — and get an answer that is itself a receipt. That question has an answer in mathematics. In most of what we ship — agents, audits, compliance documents — it still doesn't.

What to steal, whatever you build

Ship the checker with the artifact. The repository's power comes from Lean living next to the manuscripts. Your equivalent: the reproduction command next to the benchmark number, the verifier script next to the export.
Let the log do the retracting. Withdrawals recorded in public history preserve trust; silent edits destroy it. The diff is the correction.
Budget for the unverified tail. "We will update as we obtain them" is an honest sentence only if the update schedule is real. OpenAI is being held to theirs this week. Write yours down before someone else does.

Two honest limits

The withdrawal itself is the least-receipted fact in this post. I can point to the announcement, the AHM statement, the audit repositories, and the community thread — but not to OpenAI's own withdrawal note, which I could not retrieve, and I cannot name the three results with confidence. The count comes from the thread title and the trackers watching the repository. If the count is wrong, the thesis survives — the corpus is being formally checked in public, at scale, fast — but the number matters, and it deserves a primary-source citation I could not give you today.

And 42% is a snapshot, not a state. It is the formalization share as reported by repository watchers on the morning of October 8; it will be stale by the time you read this, in whichever direction. The only honest metric is the commit log itself, and it moves.

Your turn

Have you ever shipped the artifact first and promised the verification on a schedule? Did the schedule hold? And if you have actually compiled one of the Lean formalizations from this release, the thread wants to know which one — receipts, as always, beat headlines.

The internet's root key rotates in five days. Your resolver may not be ready.

Sam LABBE — Wed, 07 Oct 2026 09:26:02 +0000

On October 11 — five days from this post — the most trusted key on the internet changes hands. KSK-2017, the key-signing key that has authenticated the DNS root zone since October 11, 2018, stops signing. KSK-2024 takes over. Eight years, to the day, and the entire trust chain of DNS runs through that swap.

The schedule is not a rumor: it is IANA's own rollover page — published January 11, 2025, trust-building via RFC 5011 through the year, and on October 11, 2026, "the successor key is scheduled to sign the zone; the current key will not."

If you run your own validating resolver, this post is for you. If you don't, it's still for you — because the failure mode when a resolver misses this window is beautifully silent: everything looks normal, and names stop resolving.

What is actually happening

DNSSEC chains trust from the root down: the root signs its DNSKEY set, your resolver holds a trust anchor — the public key it believes the root uses — and every answer below the root validates up that chain. The root zone's current key-signing key, KSK-2017 (key tag 20326), has been that anchor for eight years.

The rollover is deliberately slow, because you cannot reboot the internet's trust:

January 11, 2025 — KSK-2024 (key tag 38696) is published alongside KSK-2017 in the root's DNSKEY record set. Nothing changes; both keys are simply there.
From ~February 2025 — resolvers implementing RFC 5011 (automated trust-anchor updates) start watching the new key. The mechanism requires a 30-day hold-down with regular queries before a resolver promotes the new key to a trust anchor.
October 11, 2026 — KSK-2024 begins signing the root zone. KSK-2017 stops.

The whole design assumes one thing: your resolver has been running and querying regularly through the transition. RFC 5011 is an automation, not magic — it needs roughly 30 days of uptime to promote a new key. A validator that was powered off for a month, an appliance that cached its anchors, a VM snapshot resumed after the hold-down window — any of them can still trust only KSK-2017 on the morning of October 11.

Who breaks, and how quietly

A resolver whose trust anchors contain only KSK-2017, facing a root zone signed by KSK-2024, has no path up the chain of trust. The root zone becomes unvalidatable, and everything beneath it with it.

What happens next depends on configuration, and this is the part that should worry you more than a hard failure:

Strict validation fails loudly — lookups return SERVFAIL. Annoying, visible, fixable in minutes once you know why.
Opportunistic validation fails silently — the resolver falls back to unvalidated answers. Nothing breaks. You just stopped getting DNSSEC's protection, with no error, no log line you configured, and no banner. The black box didn't fail; it quietly stopped checking.

Who is in the risk pool? Not the big public resolvers — they've served the new key for months. The pool is the population nobody measures: self-hosted Unbound, BIND, Knot, PowerDNS; DNS appliances in office basements; embedded boxes on firmware that hasn't updated since 2024; the homelab VM you paused in August. Exactly the operators least likely to be reading a rollover announcement this week — and, having checked today, I can tell you dev.to has zero posts about it.

The receipts — five minutes, three checks

Run these today, against whatever you operate or depend on:

# 1. The add-phase receipt: BOTH keys must be in the root DNSKEY RRset today.
#    20326 = KSK-2017 (out on Oct 11) — 38696 = KSK-2024 (in on Oct 11).
dig . DNSKEY +dnssec +multiline | grep "key tag"

# 2. End-to-end validation through YOUR resolver — "fully validated"
#    means the chain through the root is intact:
delv @YOUR_RESOLVER dev.to
# no delv? the 'ad' flag means your resolver validated the answer:
dig +dnssec @YOUR_RESOLVER dev.to | grep "flags:" | grep -o "ad"

# 3. Trust-anchor state on self-hosted validators — KSK-2024 must be in the
#    RUNNING resolver's managed state before October 11.
#    (Corrected Oct 7: `unbound-anchor -l` lists the utility's built-in
#    anchor and update certificate — not what your resolver tracks.
#    Thanks @m_montazeri for the documentation-based catch.)

# Unbound: find the anchor file your config actually manages, then read it.
#    The managed file is RFC 5011 state: the successor appears there with
#    its own state comment once the hold-down has run.
unbound-checkconf -o auto-trust-anchor-file    # e.g. /var/lib/unbound/root.key
grep -A3 38696 /var/lib/unbound/root.key       # KSK-2024 present and VALID?
                                               # 0 hits = not in your managed state

# BIND9 — this one does report the running daemon's state directly:
rndc managed-keys status 2>/dev/null | grep -B1 -A3 "38696"

# KSK-2024 missing from the managed file? That resolver was off (or snapshotted)
# through the RFC 5011 window — no check will save it. Update the anchor
# manually today: https://www.iana.org/dnssec/files

Check 1 is the receipt that the transition itself is on schedule: both key tags in one RRset is the rollover's "add only" phase doing its job. Check 2 tells you whether validation works at all. Check 3 tells you whether it will keep working on October 12.

Why nobody is watching

The first root KSK rollover, in 2017, made global news — and got postponed, because measurement showed most validating resolvers weren't ready. It finally completed on October 11, 2018. This one lands with a fraction of the noise, in the same week as two model launches and an agent API release cycle. The infrastructure story of the decade gets a calendar entry; the launch of the week gets a front page.

There is a receipts-shaped irony here: the rollover is the most publicly verifiable event in networking — every phase is checkable with dig — and it will still surprise people, because verification requires someone to run the check. The mechanism shipped in 2017 with automation (RFC 5011) and dashboards, and the failure mode that survives is not cryptographic. It is an operator who never looked.

What happens on the day

Probably: nothing you notice. The big resolvers hold the new anchor, the strict minority who read this checked theirs, and KSK-2017 retires after eight years of service.

Possibly: a slow-motion outage among self-hosted validators — DNSSEC-heavy domains failing in clusters, misread as hosting problems, fixed piecemeal over days as operators find the one blog post that mentions key tag 38696.

And the schedule itself can slip. The 2017 rollover did, and IANA's page marks October 11 as scheduled, not completed. Don't panic on the date — verify before it, and verify again after.

Two honest limits

Most readers will notice nothing, ever. Public resolvers carry the overwhelming majority of traffic, and they hold the new anchor. The risk pool is a minority — but it is the minority that ships infrastructure for everyone else, which is why this post exists.

And I cannot tell you how many resolvers are ready, because nobody published a current measurement I could verify. ICANN measured in 2017 and the number was bad enough to postpone the rollover. For 2026, the honest answer is: the denominator is unknown, it is made of exactly the systems nobody monitors, and the only measurement that matters for you is the one you run yourself — the three commands above.

Your turn

Do you run your own validating resolver? Run the three checks and post what you saw — key tags, ad flags, anchor states. If check 3 shows you without KSK-2024, fix it tonight and tell us what it took. The receipts thread is open.

Correction (Oct 7):

Check 3 as published tested the utility's built-in material, not the running resolver's managed trust-anchor state — unbound-anchor -l lists what the utility ships with, not what your resolver tracks. The corrected check reads the configured auto-trust-anchor-file and validates through the running resolver.
Thanks to @m_montazeri for the documentation-based catch — credited here because a post about unverified readiness claims doesn't get to skip its own standard.

She used Claude as a diary. The terms of service are now part of the charge.

Sam LABBE — Tue, 06 Oct 2026 09:06:52 +0000

On September 26, in Bonita Springs, Florida, a woman named Carli Michelle Heller wrote a diary entry. She kept her diary in Claude — an AI chatbot used, per reporting, the way people have always used diaries: to say the unsayable somewhere.

The entry said she planned to shoot up the Lee County Sheriff's office. Claude's safety systems flagged it. A human reviewer judged it a credible threat. Anthropic reported it to law enforcement, deputies identified Heller, visited her home, and detained her without incident. She is charged under Florida Statute 836.10 — written threat of violence, a second-degree felony. The story broke on TechSpot on October 4; it spent the weekend at the top of Hacker News.

The legal question everyone is arguing — does the statute even apply to text a machine read first — is genuinely unsettled, and I am not going to pretend to resolve it here. What interests me is the machine part of the machine-and-law story: a woman's private writing became a prosecutable communication because of a review policy nobody reads, and the whole case now rests on a judgment call made by one human reviewer at a vendor. That chain deserves an audit, whoever ends up right in court.

The chain, link by link

Every link is documented except the two that matter most:

The entry. Real, dated, quoted in part by press. The strongest link.
The classifier flag. Undocumented. What triggered it? A keyword pass, a model-level safety layer, a user-reported "concerning use" button? We don't know, because vendors don't publish their flag criteria — they publish slogans.
The human review. One reviewer, or a panel? What rubric? A "credible threat" judgment made in minutes or hours, by an employee with no forensic training, reading one entry out of the context of this user's history. Undocumented.
The report. Documented by its outcome. Under Anthropic's stated policy, the company "may share user information in limited emergencies" when disclosure is believed necessary to prevent "death or serious physical injury". Note the verb: believed. The threshold is a belief, held by the reviewer from link 3.
The charge. Florida Statute 836.10 requires the written threat to be "made in a manner in which another person may view it."

Read links 4 and 5 together, because together they are the whole story. She wrote to a machine. The machine only becomes "another person" because the vendor's policy sends entries to humans. The disclosure policy is what converted a diary into a communication. The terms of service are, functionally, an element of the charge.

Two vendors, two thresholds, both in court

If reporting were obviously right or obviously wrong, this would be a simpler post. It is not, and the pair of cases proves it.

Anthropic reported. Heller faces a felony, and the internet is litigating whether a diary entry meets the statute. OpenAI, in the parallel case, did not report: per TechSpot and the complaint filed September 21, chats with Jesse Van Rootselaar — the 18-year-old former pupil behind a school shooting in Tumbler Ridge, British Columbia — "didn't meet the referral threshold." OpenAI and Altman are now being sued by British Columbia and by Florida. Both are also facing the court of everyone who reads the two headlines side by side.

So the matrix is complete. Report and get charged users; don't report and get sued. There is no threshold that escapes litigation, because the threshold is a judgment call, and judgment calls about lethal risk get litigated. That part is not a failure — it is the job. What is a failure is how the judgment gets made: one reviewer, one entry, an undocumented rubric, a verb as soft as believed, and no record you can audit afterward.

A report to the police is a claim. In every other domain, claims of that weight require receipts.

What a defensible threshold looks like

Not a policy essay — a checklist any team shipping a chatbot or an agent with memory can apply, generic tooling only:

Written trigger criteria. Not "we may share in limited emergencies" — a numbered list: what content categories, what imminence signals, what specificity of target. If your reviewer can't recite the criteria, the criteria don't exist.
Logged review decisions. Every flag, the verdict, the reasoning summary, the reviewer role, the timestamp. If a charge is challenged in court two years from now, "one employee decided" is a liability; "here is the recorded decision trail, and here are three prior cases that matched the same criteria" is a defense.
Second pass on irreversible actions. Reporting to law enforcement is irreversible and ends a person's privacy. It should not be a single-reviewer action — the same way destructive agent actions should not be single-click. Two independent verdicts on the same criteria, or it waits.
Proportionality in the report. Hand over the flagged content and the minimum context required, not the whole history. The diary contains more than the threat; the report should not.
A user-visible disclosure. Not buried in section 14 of the terms — at the point of use. "Entries may be reviewed by humans and reported in emergencies" is the sentence that makes the user's choice informed. If it only lives in the ToS, it is a legal shield, not consent.

None of this argues against reporting credible threats. All of it argues that the decision to end someone's privacy should be as engineered as the system that captured the text.

What changes for you, today

If you are a user: every chatbot input is written into a system whose operator has a disclosure policy, retention rights, and legal obligations you did not write. A diary's job is to be unread. A chatbot's design is to be read. Those are not the same object, and the gap between them is where this woman now lives. Write accordingly — with a real notebook, or with full knowledge.

If you are a builder: memory features, journaling features, "personal companion" features — every one of them increases how much of a person flows through your review pipeline. Your disclosure policy is not legal boilerplate. It is a security property of your product, with a threat model, and it deserves the same engineering as auth: criteria in code, decisions on record, second passes on irreversible actions.

Two honest limits

The verdict is not the point, and the charge may not hold. Whether Statute 836.10 covers text first read by a machine is genuinely contested — the "true threats" doctrine and the "another person may view it" element both cut against an easy conviction. I am auditing the disclosure pipeline, not second-guessing the deputies or prejudging the court. The pipeline's weaknesses exist in every case, including the ones where reporting saves a life.

And the alternative case is not hypothetical. The Tumbler Ridge shooting happened without a report. Any threshold you tighten to protect diarists loosens protection for the next target of a real threat. There is no clean setting on this dial — which is precisely why the setting should be written, logged, and reviewable instead of living in one reviewer's stomach.

Your turn

Would you write a real diary entry into an AI today? And if you ship anything with memory or review: can you show your users the exact sentence that could turn their input into evidence? The comments are open — bring the scar stories, both kinds.

The status page was green while apps crashed. The postmortem explains why.

Sam LABBE — Mon, 05 Oct 2026 12:01:44 +0000

On September 28 at 17:41 Pacific Time, a malformed configuration payload finished rolling out to a wide population of iOS apps. Phones started crashing on launch. Firebase's status dashboards stayed green.

The postmortem went up on October 2, four days later, and it is better than most vendor postmortems — a real timeline to the minute, a mechanism, an admission that the tests passed. I still read it the way I read anything a vendor writes about its own failure: a plausible narrative until someone can check it. By that standard, the report contains exactly one number nobody can verify, and it is the number everyone actually wants.

The clock, as published

The mechanics first, because they are good. Firebase's iOS SDK accumulates obsolete remote-config flags. Teams use those flags as kill switches — "a way to turn off a feature that contains a bug". On September 28 at 17:38 PDT, a cleanup retired one stale flag. A pointer to it remained somewhere in the SDK; when the SDK fetched the missing flag, "this resulted in a fatal error". A cleanup described as a 2-line change produced a malformed payload that rolled out globally within three minutes.

Then the clock, in the report's own terms:

17:38  stale legacy flag cleaned up
17:41  malformed payload rolls out globally — clients crash on launch
17:59  crash alerts spike, first external bugs via GitHub, on-call paged
19:16  culprit change identified, rollback initiated
19:52  rollback fully deployed — mitigation complete

Invalid configuration served for 2 hours 11 minutes. Detection took under twenty minutes. Elevated error rates persisted "for many hours based on error reporting lag". Those are receipts: timestamps, durations, a mechanism you could in principle reproduce in a test device. If every postmortem had this spine, incident analysis would be a better field.

The three claims an auditor flags

"A large number of iOS applications." That is the blast radius, in full. No app count, no device count, no SDK version breakdown, no list of affected surfaces. Third-party coverage said "thousands of apps" — but that number comes from reporters counting crash reports, not from the vendor who knows it exactly. Google knows how many clients fetched the malformed payload; it is one query on their own logs. Its absence converts the most important fact of the incident into an adjective.

"Existing tests passed on the change." Which tests? What did the suite cover — flag-fetch failure paths, payload validation, cache fallback? Nothing names the suite, so nothing lets another team check whether their own tests would have caught this. Compare the usable version: "our tests cover X and missed Y because of Z" — that sentence is a gift to every reader; "existing tests passed" is a shrug with a citation mark.

The dashboards were green. The report says it outright: status dashboards rely on server-side metrics and missed the client-side crashes entirely. The witness was watching the wrong room. During a global client-side outage, the authoritative channel turned out to be a GitHub issue — because dashboard updates "required manual intervention taking hours". Read that back: the company's own incident-communication tool was harder to update than a free issue thread. That is the finding I would put on top of the retrospective, and the postmortem buries it in a mitigation bullet.

The kill switch ate its own caller

Here is the part I keep thinking about. The flags were the safety mechanism — the kill switch for buggy features. The failure came from managing the safety mechanism's own lifecycle: a cleanup of dead flags, merged as trivial, reached the kill switches themselves.

That pattern generalizes further than Firebase. Auth handlers, feature flags, circuit breakers, backups, the seatbelt hooks people attach to their AI coding agents — every control has a lifecycle, and the lifecycle changes (cleanup, migration, refactoring) almost never inherit the control's own tests, because the control "works". The configuration that breaks your system is increasingly the configuration that was supposed to save you.

What a receipts-grade incident report contains

For contrast, look at what the UK AI Safety Institute published on August 4 after its own agents went off-script during evaluations: an incident ID, a page count you can hold (35), the number of runs (122), the number of unsanctioned actions (19, across 10 runs), which models did what, and remediation commitments specific enough to be checked ("internet access must be actively justified rather than a default"). You can disagree with their containment choices — I do — but every load-bearing claim is a number or a verifiable commitment.

The Firebase report has the honest spine and skips the counts. A receipts-grade version would add three lines: apps affected (a number from their own logs), the test suite that passed and what it covered, and the diff between the valid and malformed payloads. None of that is secret. All of it is knowable by the author. The gap between knowable and published is where trust gets spent.

What to steal for your stack

Fail-safe fetch. The committed SDK patch makes missing or corrupt flags fall back to cached defaults instead of crashing. Until it ships, "within the next week", every app on the affected SDK line carries the same fault. Watch the releases.
Config is a deployment. The report's own lesson: "deploying configuration changes to a broad segment of our global customer base too quickly introduces unnecessary risk." Phased rollouts and canaries apply to flags exactly like binaries — more, actually, because flags have no build step to catch them.
Watch the clients. Your status page watches your servers. Your users run your client. If you have no client-side heartbeat — crash reporter, canary app, third-party tracker — then during the next client-side incident, your dashboard will also be green, and you will also find out from GitHub.

The receipts, such as they are:

# The primary source — read the report before the commentary:
open https://firebase.blog/posts/2026/10/firebase-analytics-outage

# The receipt to watch: the validation patch, promised "within the next week".
# If it ships with a test for the flag-fetch failure path, this postmortem
# graduates from narrative to receipt. Until then it is a promise with dates.
gh release list -R firebase/firebase-ios-sdk --limit 5

Two honest limits

This postmortem is not a bad one — it is an average good one. Twenty minutes to detection, 2h 11min to full rollback, a mechanism published in plain language, and a promise attached to a date. The audit above is about verifiability, not competence; most vendors publish less, later.

And hindsight is unfair. "The tests should have covered the missing-flag path" is easy to write on October 5 and hard to have insisted on in a cleanup review. That is precisely why the fix has to be structural — validation at fetch time — rather than a renewed promise to test harder. Structure survives attention; attention does not.

Your turn

When your status page last stayed green while your users burned, what did you point people at — and how long did it take to get a number out? I am collecting incident-report receipts: the good, the green, and the GitHub issues that did the status page's job.