Fail-closed vs fail-open security
Every safety system eventually faces the same question: what should happen when the check itself does not work? The answer separates two design philosophies, and it quietly decides how much protection a system actually delivers on its worst day rather than its best one.
The two defaults, defined
Fail-open means that when a check cannot complete, the thing being checked is allowed through. The system prioritises availability: better to serve something than nothing. Most content filters, many ad blockers and a great deal of web infrastructure work this way, because an outage in the checker should not take the whole product down with it.
Fail-closed means the opposite: when a check cannot complete, the thing being checked is denied. The system prioritises safety, and accepts that an outage in the checker will reduce what it can offer. Locks on doors, aircraft interlocks and payment authorisation all work this way.
Neither is universally correct. A fail-closed lift door that jams is a serious problem; a fail-open lift door that jams is a fatal one. The right default depends entirely on what happens when the wrong thing gets through.
Side by side
| When… | Fail-open | Fail-closed |
|---|---|---|
| The safety check times out | The content is shown. The visitor never learns that no check happened. | The content is withheld. The visitor sees a shorter list of verified results. |
| The checking service is down | Everything passes through, so an outage silently disables the protection. | Nothing unverified passes through, so an outage reduces coverage instead of safety. |
| The result is ambiguous | Ambiguity is resolved in favour of availability. | Ambiguity is resolved in favour of the person reading the page. |
| An attacker deliberately stalls the check | Stalling becomes an attack: slow down the checker and get shown anyway. | Stalling gains nothing, because a stalled check is a hidden result. |
Why search filtering has to fail closed
A fail-open search filter is only as strong as its slowest dependency. If an unassessed site is shown whenever the assessment is slow, then the protection disappears exactly when it is most needed: during an outage, under load, or when somebody deliberately makes their site slow to check. Protection that can be switched off by the party being inspected is not protection at all.
The consequence is visible and deliberate. Marisei returns fewer results than an unfiltered search engine. A site can be missing not because it is dangerous, but because we could not establish that it is safe — and we would rather say less than imply more than we know.
Making fail-closed survivable
The usual objection to fail-closed design is that it is brittle. That is only true if the system has no way of recovering from a failed check, so most of the engineering effort goes into recovery rather than into loosening the rule.
Recent successful scores can stand in briefly
If a site was assessed successfully in the recent past and a fresh check does not return in time, its last known passing score can be reused for a short window. Nothing that has never passed is ever shown on the strength of a cached answer.
Slow sites are finished in the background
Some legitimate sites genuinely take a long time to assess. Rather than abandoning them forever, those assessments are queued and completed after the search has already been answered, so the site is available the next time somebody looks for it.
Retries with backoff, not a single attempt
A timeout or a temporary error is retried with a short, randomised delay before the result is given up on. Rate-limited responses wait longer. Only after retries are exhausted does the fail-closed rule take effect.
A verified allowlist for sites already checked
Sites that have been reviewed and approved can answer instantly from a trusted list rather than being re-assessed on every single search, which removes most of the latency pressure that pushes other systems toward fail-open.
Every one of these makes the system faster or more complete without ever showing a site that has not passed. That is the line: latency can be optimised, the verdict cannot be assumed.
How to tell which model a product uses
- Ask what happens during an outage of the safety service. If results keep flowing unchanged, it is fail-open.
- Look for warning labels you can click past. Interstitials imply the content was allowed through and the decision was handed to you.
- Check whether unverified items are marked as unverified or removed. Showing something as "unknown" is a fail-open choice with better manners.
- See whether result counts ever drop. A filter whose totals never change is probably not removing much.
Where fail-closed stops
The rule covers what Marisei shows you. It cannot cover what happens after you leave: links and redirects you follow from a trusted site have not been assessed, and a site can change after its assessment was taken. Keep your usual judgement once you are off the results page.
Keep reading
- How trust-filtering prevents phishing — the signals that expose an impersonation.
- How Marisei Search works — the three steps behind every search.
- About Marisei — our mission and the trust score.