Absence is not proof

The Vancouver Police Department published a web feature named Quick Escape. On execution, it removes itself from the browser history. That is the confirmed fact set. Everything attached to it beyond that behaviour is not confirmed. My position is direct. A control whose defined output is the deletion of the record of its own execution is a control that produces no evidence it ran.

Set the design intent aside. Intent is not confirmed. What is confirmed is behaviour, and behaviour is what I am accountable to. The behaviour here is self-erasure on execution. Measured against any requirement for a verifiable record, a mechanism that erases its own trace cannot be verified. You cannot confirm it ran. You cannot confirm it ran correctly. You cannot confirm it ran at all. Absence is the only output, and absence is not proof.

The operating principle holds. If a system allows a behaviour, that behaviour will occur, and it will occur without a record when the record is the thing being erased. A history entry that deletes itself on execution is indistinguishable from a history entry that was never created. The two states are identical from the outside. That equivalence is the whole problem, and it is present the moment the feature is defined this way.

The observable behaviour is limited and specific. Before execution, the feature is present on the page as a button. After execution, the browser history entry associated with that action is not present. Those two observations are the full externally visible behaviour. The system’s measurable output is the removal of its own trace from browser history.

What is observable after the fact is an absence. There is no history entry to inspect. From the browser history alone, you cannot observe that the feature was invoked, when it was invoked, or whether the invocation completed. The output of the control is the elimination of the evidence that the control was used. That is not a side effect. That is the stated function.

What is not observable is everything else, and it must be treated as not confirmed. Whether any artifact persists outside browser history is not confirmed. Whether server-side records, network records, cache, or DNS resolution retain a trace is not confirmed. Whether the removal is complete and consistent across browsers and sessions is not confirmed. Whether every execution succeeds is not confirmed. Absence of the history entry is not evidence of absence of the event anywhere else. It is only absence of the entry.

It failed as a record because its defined behaviour is to destroy its own record. This is not a defect introduced by an attacker or an error in deployment. The failure is definitional. A mechanism whose output is the deletion of its execution trace cannot simultaneously function as a trace. The two requirements are in direct conflict, and the design resolves that conflict by choosing deletion.

Reconstruction of events depends on the persistence of records. This feature’s observable behaviour is the non-persistence of its own record in browser history. It follows, as a logically necessary consequence and not an inference, that no reconstruction of that event is possible from browser history. There is nothing to reconstruct from. The data that would support reconstruction is the same data the feature removes.

I will not imply visibility that is not stated. Whether the event is recoverable from any other source is not confirmed, because the presence of any other source is not confirmed. Contained to what is known, the browser-history record of the execution does not survive the execution. From that boundary, the event is unrecoverable. A control that is measured only by what it removes leaves you with nothing to measure. That is the state the design produces, and it produces it every time it runs.

The mechanism is self-referential deletion. The control’s execution and the destruction of the control’s record are the same operation. There is no separation between the act and the erasure of the act. When execution and evidence-removal are bound into one output, the control cannot leave an enforcement artifact behind. An enforcement point exists to produce a durable result that can be checked against a boundary. This mechanism produces a durable absence. Absence is not checkable.

A verifiable control ties an action to a boundary crossing and preserves a record that the crossing occurred. Here the observable output is the removal of the browser-history entry that would mark that crossing. The mechanism severs the link between the action and any record of the action within that boundary. What remains carries no identity, no time, and no confirmation of completion. The mechanism does not fail to record. Recording is not its function. Its function is removal, and removal is what it delivers, exactly as defined.

The failure resolves to a two-state collapse. Before execution, the button is present on the page. After execution, the history entry is absent. A history entry that was removed and a history entry that never existed are, read from the browser history, the same state. The mechanism collapses ran and never-ran into one observable. Any control that collapses its success state and its never-invoked state into a single reading has no measurable output. That collapse is the mechanism of failure. It is not triggered by an error and not introduced by an attacker. It is the defined behaviour operating as defined.

What this exposes is a class of controls whose success condition is the absence of their own trace. When a mechanism defines success as no record remains, success and failure produce the same output. A run that completed and a run that never started both terminate in absence. You cannot distinguish them, because the distinguishing evidence is the thing the mechanism removes. Every control in this class is unverifiable by construction, not by circumstance.

Hold the same mechanism and press on it. Take any process whose defined output is the deletion of the record of that process. Whether it executed once, executed many times, executed and stopped partway, or was never executed at all, the terminal observable is identical. Nothing remains. The number of executions is not confirmed and cannot be confirmed from the output. The completeness of any single execution is not confirmed and cannot be confirmed from the output. The mechanism does not degrade under these questions. It was never able to answer them. Same mechanism, same blind output.

The pattern also exposes a posture. A system that ships a self-erasing control has accepted that a category of its own actions will be unobservable to it. That acceptance is a decision about what the operator is permitted to see, and the mechanism makes that decision, not the operator. It removes the operator’s ability to confirm the control’s own behaviour. Whether that removal extends beyond browser history is not confirmed. Within browser history it is total. A control you cannot observe is a control you cannot manage. A control you cannot manage is not one you hold. You hold the button. You do not hold the outcome.

State it without softening. A control whose output is the deletion of its own execution record is not a control. It is an unmonitored action with a name. Verification requires a record that survives the event it records. The confirmed behaviour of this feature is that its browser-history record does not survive its execution. Measured against a verification requirement, and contained to the browser-history boundary, this mechanism does not meet it. That is not a claim about intent. Intent is not confirmed. It is a statement about behaviour, and behaviour is the only thing I am accountable to.

What must now be true is narrow and non-negotiable. If execution must be verifiable, execution must produce a durable artifact that is independent of the mechanism being executed and that survives that execution. Whether any such artifact exists outside browser history is not confirmed. Absence of the history entry is not evidence about any other store, in either direction. Until a surviving, independent record is confirmed to exist, the correct operating assumption is that within the confirmed boundary the event is unrecoverable. Assume nothing the facts do not carry.

If a system allows a behaviour, that behaviour will occur, and a behaviour that erases its own record will occur without leaving one. Design decides what you can see after the fact. This design decides you see nothing in browser history. A record that deletes itself is not a record. A control that cannot be verified is not effective. Do not measure this by the button you can press. Measure it by the record you can produce. Within the confirmed boundary, there is none.