The URL Passed, but the Socket Was Still Unknown

2026-08-26

The first sketch for Remote Browser navigation was satisfyingly small. Parse the URL, resolve its hostname, reject private addresses, then call page.goto().

We already had the lifecycle. We already had an owner-bound tab. This looked like the last check before adding open.

Then we followed the request one layer farther.

Our Python check would resolve the hostname and approve an address. It would not hand that address to Chromium. It would hand Chromium the hostname again. Chromium would resolve it later, when it opened the connection. A DNS answer could change between those two moments, so the address that passed policy and the address that received bytes did not have to be the same address.

The URL checker had made a decision about a socket it did not control.

The proxy that private addresses could walk around

Putting a local proxy between Chromium and the network seemed to close the gap. The proxy could resolve the hostname and connect directly to the approved numeric address. Redirects and subresources would pass through it too.

Before writing the proxy, we checked Chromium's own proxy rules. That exposed a second hole: Chromium implicitly sends localhost and link-local destinations direct, bypassing an otherwise configured proxy. Those are exactly the destinations Remote Browser must keep away from an untrusted page.

The browser offered a proxy, saw a local destination, and helpfully stepped around our future security boundary.

Chromium does provide a subtractive bypass rule that forces those destinations through the proxy. But that flag alone is not proof. An extension, profile policy, engine difference, resolver rule, QUIC path, or future Chromium change could restore direct traffic. The release gate therefore has to observe the effective runtime: start private sentinel servers, attempt every private path, and prove they accepted zero connections.

The credential that the proxy setting did not carry

The first native preflight found a third boundary. macOS Chrome reached the gateway, received its authentication challenge, and never sent the configured proxy credential. The private sentinel still accepted zero connections, which proved the launch failed closed. It did not prove the browser was usable.

That result matches a less obvious line in Chromium's own documentation: credentials embedded in manual proxy settings are ignored. Playwright routing could not repair it because the proxy challenge lives below a page request, and a page-scoped CDP auth handler never received the challenge.

The secure fix belongs in the closed Onion Browser. It will read a credential from a private file, then use Chromium's existing HTTP-auth delegate only when the challenge is for the exact loopback proxy, fixed realm, Basic scheme, and first attempt. A different proxy or a retry is canceled. An origin challenge never sees the proxy password.

That discovery changes the delivery order. Remote Browser will not fall back to system Chrome merely because it is installed. The paid browser hook and its native zero-socket suite must pass first; a platform without that artifact keeps navigation unavailable.

One more boundary moved

The ordinary co browser daemon already has a persistent profile and shared context. We could put the gateway there, but Chromium proxy selection belongs to a browser context, not an individual tab. Remote policy would then change unrelated local browsing, and future sessions with different shared-proxy grants could not honestly claim per-tab isolation.

So the design moved again. Remote Browser will reuse the same BrowserDaemon and AsyncBrowserCore implementation in a Host-private namespace, with its own socket, lock, profile, and fixed fail-closed gateway. It is not a second browser implementation. It is a separate security context for the same implementation.

Navigation is still absent. That is the useful result of the investigation.

The next code will begin with a parser, address classifier, deterministic DNS and dialer seams, and a data-driven catalogue of private destinations. Only after the gateway proves that redirects, rebinding, frames, images, scripts, fetch, WebSockets, workers, and downloads cannot make a prohibited connection will open become a Remote Browser command.

The mistake would have been easy to ship because the original URL really did pass its check. The lesson is that SSRF policy does not belong to the string that names a destination. It belongs to the component that chooses and opens the socket.