codexproof

glossary / Fail-closed

the design posture where missing, stale, or unverifiable security state causes DENIAL rather than acceptance - the system would rather stop than guess.

certificate chainsrljit capturep50 and p99
Fail-closed - Two failure philosophies: the shrug and the stop

Two failure philosophies: the shrug and the stop.

Etymology and backstory

the principle is Saltzer and Schroeder's "fail-safe defaults" from their 1975 paper The Protection of Information in Computer Systems - base access on permission, not exclusion, so errors deny. Real-world systems constantly betray it for availability's sake (browsers soft-failing revocation is the canonical betrayal), because closed failures generate support tickets and open failures generate silence - until they generate headlines.

Ecosystem

SELinux enforcing mode, HSTS, certificate pinning, DNSSEC-validating resolvers - each a fight to keep a fail-closed stance against availability pressure.

In codexproof

the stance is total and priced openly: no fresh revocation list, no authorization; no verifier clock, no authorization (main.rs line 146); every availability attack converts to denial of authorization (Q18's "starve it"). The paper's phrase to say on stage: denial, never forgery - you can turn the system off; you cannot make it lie.

"Fail-closed trades forgery risk for outage risk - so the ops discipline becomes freshness monitoring, and the worst-case headline becomes 'it was down,' never 'it lied.'"
References: Saltzer and Schroeder, "The Protection of Information in Computer Systems," Proceedings of the IEEE (1975) - fail-safe defaults.

All terms · Questions & answers · The verifier