Kill Switch vs Tor Browser Isolation: Two Different Tests

Kill switches and browser identity models get confused because both are described as privacy features. One blocks traffic at the network layer, and the other limits what a browsing session can link together. Passing a test of the first says nothing about the second, and a page loading inside Tor Browser says nothing about the first. The decision is which control answers which question, because that choice decides what evidence counts.

Two Controls at Two Boundaries

A kill switch is a rule about routes: when the tunnel is not up, traffic that would otherwise take a different path is dropped. Its scope is whatever the implementation covers, which may be the whole system, one application, or only the address families the client manages. Browser isolation concerns what a site can observe about a visitor across a session: cookies, cached state, fingerprints, logins. Neither mechanism can substitute for the other, because they act on completely different objects.

That is why a machine can pass a perfect kill-switch test and still leak identity through a login. The reverse happens just as often: a well-isolated browser on a host whose telemetry takes a path the policy never covered.

Filing both under one label is what produces bad evidence, because a pass on either side then stands in for the pair. Keep them in separate columns from the start. The column heading also tells you which artefact the test owes you, a blocked packet or a session record.

The Outage Run Answers a Narrower Question

A controlled outage shows whether the client blocks the traffic you tested, on the platform you tested, for as long as the test ran. Include the address families, applications and network transitions the requirement mentions, because each one is a separate claim. A block that holds for IPv4 and not IPv6 is a real finding, and so is a block that holds on a wired network but not across a mobile handover. Write the scope beside the result, since an unqualified pass is how a narrow test becomes a broad assumption.

The negative control matters as much as the positive one. Confirm that the same request succeeds while the tunnel is up, so the block clearly came from the policy rather than from a destination that never worked. A test that failed in both states proves nothing at all, and it is worth saying so in the record rather than quietly discarding it.

Isolation Is a Browser Property, Not a Route

Tor Browser's stated design limits linkability by keeping circuit and browser state together and by clearing state on request, and the project documents what that means in practice for managing identities. That design assumes the supported configuration, not a generic browser pointed at a proxy port. Extensions added for convenience can undo part of the isolation, and a captured login links everything that follows regardless of the circuit. The documented behaviour is short enough to read directly.

Browser observations and network observations answer different questions, so keep them in separate notes. A page that loads over Tor while the VPN is up tells you the proxy works and nothing about the VPN's drop behaviour. A blocked packet during an outage says nothing about whether two logins were linkable an hour earlier.

Two Records, Two Questions

For the kill switch, ask whether a named application can leave by an unwanted route during a failure, and bring a controlled outage with a logging destination you own. For browser isolation, ask which accounts, state and signals could link two activities, and bring a workflow rather than a packet capture. If a second application matters, test that application separately, since scope is per-application more often than vendors imply. Two different questions produce two different artefacts and one honest report.

Draw both paths before testing: the normal route and the route after a tunnel failure, for every application in scope. A drawing exposes the gap that a single green indicator hides, because it forces you to name what is covered and what is not. Do that while the systems are healthy, when nobody is under pressure to declare the check finished.

Neither control certifies the other, and a combined setup needs both records before it can claim both properties. Claiming both from a single green indicator is the exact failure this pairing is meant to prevent.