# Every test was green and the feature had never worked once

The native egress preflight is the part of Remote Browser that refuses to
start. Launching Chromium behind a loopback proxy proves nothing on its own —
the process starting successfully says nothing about which socket the next
request goes out of — so before the first page is opened, the preflight makes
the browser prove it: navigate somewhere the gateway must refuse, then check
that the refusal came from the gateway, then check that a loopback sentinel
saw no connections at all.

Its tests passed. All of them, every run. And it had never once succeeded
against a real browser.

## Two facts nobody had put together

The first probe asks for `http://remote-browser-preflight.invalid/`. The
reasoning is good: `.invalid` is reserved never to resolve, so a browser that
resolved names itself would fail locally, while a browser going through the
gateway gets the gateway's DNS failure. The code required status 502.

The gateway answers **403**. Its destination policy denies `.invalid` by name,
before DNS is ever consulted — the very special-use suffix list that another
review had hardened a day earlier. The 502 path exists, but only for a host the
policy *admits* and that then fails to resolve. The witness could never fire.

The second is smaller and worse. The gateway's refusals are sent with
`Content-Length: 0`. Chromium will not commit a bodyless 4xx or 5xx main-frame
navigation — it reports `ERR_HTTP_RESPONSE_CODE_FAILURE`, so `page.goto` raises
instead of returning a response:

```
403 empty body -> ERR_HTTP_RESPONSE_CODE_FAILURE
403 with body  -> status=403
```

The preflight catches every exception and collapses it to
`EGRESS_PREFLIGHT_FAILED`. So even with the status expectation corrected, both
probes raise, and the private browser can never start.

Fail-closed, which is the right direction to be broken in. But a boundary that
can only ever refuse is not a boundary; it is an outage with good manners.

## Why the tests could not see it

The suite drives a `FakePage`. `FakePage.goto` returns a response object where
real Chromium raises, and its constructor hard-codes `witness_status=502` —
the status the real gateway never sends. The fake modelled two behaviours the
real stack does not have, and the tests then verified the fake.

There was no test anywhere that ran this preflight against a real browser.

## The absence that proved nothing

There was a third problem, and it is the one worth remembering.

The subresource half of the proof — fetch, image, WebSocket, worker — runs
inside a bounded race that swallows each probe's own errors, by design: a probe
that fails is a probe whose request was correctly refused. Then the sentinel is
asked whether it accepted any connections, and zero means the browser never
went direct.

Zero also means the probe never ran. A wrong URL, a blocked API, an `await`
that resolves on the timer — every one of those produces the same zero as a
perfectly proxied request. Replacing the entire subresource function with
`async def noop(): return None` leaves the preflight passing.

An absence is only evidence once the thing that would have produced a presence
is known to have run. The gateway now counts the requests it has decided, and
the preflight reads that count before and after: the sentinel's zero means
something only when the gateway's counter moved.

That is also the fix for a subtler version of the same gap. The old check read
the counters 1.6 seconds after starting the probes and tore the sentinel down
immediately after; a leak whose socket landed at two seconds was invisible, and
worker startup on a cold Chromium can take longer than that. Requiring positive
evidence removes the dependence on a window.

## What it takes to believe a security check now

Three properties, and each was verified by breaking it:

- remove the positive control → the neutered-probe test goes red
- remove the gateway-witness header check → the foreign-403 test goes red
- put the error body back to empty → the real-driver test goes red

And the real-driver test itself runs both ways: it passes against a correct
launch with all seven probes reaching the gateway, and it still fails when
`<-loopback>` is replaced with a real loopback bypass. Passing alone would only
prove the check is lenient.

The preflight was green for its entire life without ever having worked. The
thing that finally told us was not a better assertion. It was running it.