The Browser Opened Before We Knew It Was Safe

2026-08-26

The private BrowserDaemon had a careful launch policy. Chromium received one loopback proxy, no implicit localhost bypass, browser-side DNS failure outside the gateway, blocked Service Workers, disabled QUIC, and disabled non-proxied WebRTC UDP. The process opened successfully.

That last sentence was the problem.

“The browser opened” only proved that the driver created a context. It did not prove which component would resolve a hostname, whether an internal redirect would use the proxy, or whether Chromium would recover from a dead gateway by opening a direct socket. If the daemon returned ready at that point, every later page command would rely on configuration as evidence of network behavior.

For Remote Browser, configuration is a request. Readiness needs a verdict.

Two witnesses, not one successful page

The native preflight now runs against the real persistent context before seed cookies or user pages exist. Its first request uses a reserved .invalid hostname. Browser-side DNS cannot resolve it; only the authenticated gateway can turn that exact attempt into our stable 502 response. That response is a witness that the browser reached the gateway and let the gateway own DNS.

The second request points at an owned IPv4 loopback sentinel. The gateway must reject it with 403 while the sentinel records zero accepted sockets and zero bytes. We repeat the zero-socket observation across fetch, image, WebSocket, and worker paths because browser-owned transports do not all share the same page interception surface.

Neither response is useful alone. A 403 without the DNS witness could come from the wrong layer. A 502 without the sentinel could coexist with Chromium's implicit direct path for loopback. Together they prove the behavior we need at startup, and any timeout, unexpected status, accepted socket, or internal error collapses to one non-secret failure. The partially opened context and driver are then closed.

The 407 that changed the release boundary

The first real-browser experiment did not pass this preflight. System Chrome reached the proxy but never supplied Proxy-Authorization. Credentials in a manual proxy URL are intentionally ignored by Chromium. Playwright routing and page-scoped CDP Fetch interception also failed to cover the browser-owned challenge early enough. The gateway returned 407, while the direct sentinel correctly stayed at zero.

That was not a reason to weaken the test. It clarified the product boundary: system Chrome is not an eligible Remote Browser engine. The closed Onion Browser must answer only the exact first challenge from the pinned loopback proxy, using a credential file owned by the Host-private runtime. A mismatched realm, scheme, challenger, or repeated challenge must be cancelled.

The daemon now writes that file atomically beside the private profile. On POSIX, its parent must be owned by the current user with no group or world access, and the file is mode 0600. The launch policy gives Playwright only the loopback proxy server—never its username or password—and passes the browser a path-only switch. Construction failures and orderly shutdown both remove the file. This still is not native-browser evidence; it is the exact producer side of the contract that the pinned Onion Browser must consume.

This PR therefore stops at a fail-closed checkpoint. Its unit and lifecycle tests pass, but it makes no installed-browser claim. The release gate remains closed until the paid Onionwright engine, native credential hook, and exact browser artifact meet in one stack and pass the full Mac and Linux matrix.

Opening a process is an implementation event. Declaring a private browser ready is a security decision. The preflight exists to keep those two moments apart.