Kill switch frente al aislamiento de Tor Browser: dos pruebas distintas

Los kill switch y los modelos de identidad del navegador se confunden porque ambos se describen como funciones de privacidad. Uno bloquea el tráfico en la capa de red y el otro limita qué puede vincular una sesión de navegación. Superar una prueba del primero no dice nada sobre el segundo, y una página que carga dentro de Tor Browser no dice nada sobre el primero. La decisión es qué control responde a qué pregunta, porque esa elección determina qué pruebas cuentan.

Dos controles en dos fronteras

Un kill switch es una regla sobre rutas: cuando el túnel no está levantado, el tráfico que de otro modo tomaría una ruta distinta se descarta. Su alcance es lo que cubra la implementación, que puede ser todo el sistema, una aplicación o solo las familias de direcciones que gestiona el cliente. El aislamiento del navegador se refiere a lo que un sitio puede observar sobre un visitante a lo largo de una sesión: cookies, estado en caché, huellas digitales, inicios de sesión. Ninguno de los dos mecanismos puede sustituir al otro, porque actúan sobre objetos completamente distintos.

Por eso una máquina puede superar una prueba perfecta de kill switch y seguir filtrando la identidad mediante un inicio de sesión. Lo contrario ocurre con la misma frecuencia: un navegador bien aislado en un equipo cuya telemetría toma una ruta que la política nunca cubrió.

Archivar ambos bajo una sola etiqueta es lo que produce pruebas malas, porque entonces un aprobado de un lado sustituye al par. Manténgalos en columnas separadas desde el principio. El encabezado de la columna también le dice qué artefacto le debe la prueba: un paquete bloqueado o un registro de sesión.

La prueba de caída responde a una pregunta más estrecha

Una caída controlada muestra si el cliente bloquea el tráfico que usted probó, en la plataforma que probó, durante el tiempo que duró la prueba. Incluya las familias de direcciones, las aplicaciones y las transiciones de red que menciona el requisito, porque cada una es una afirmación separada. Un bloqueo que vale para IPv4 y no para IPv6 es un hallazgo real, y también lo es un bloqueo que vale en una red cableada pero no en un traspaso móvil. Escriba el alcance junto al resultado, porque un aprobado sin matices es como una prueba estrecha se convierte en una suposición amplia.

El control negativo importa tanto como el positivo. Confirme que la misma solicitud tiene éxito mientras el túnel está levantado, para que quede claro que el bloqueo vino de la política y no de un destino que nunca funcionó. Una prueba que falló en ambos estados no demuestra nada, y vale la pena decirlo en el registro en lugar de descartarla en silencio.

El aislamiento es una propiedad del navegador, no una ruta

El diseño declarado de Tor Browser limita la vinculabilidad manteniendo juntos el estado del circuito y del navegador y borrando el estado cuando se solicita, y el proyecto documenta qué significa eso en la práctica para la gestión de identidades. Ese diseño presupone la configuración compatible, no un navegador genérico apuntado a un puerto de proxy. Las extensiones añadidas por comodidad pueden deshacer parte del aislamiento, y un inicio de sesión capturado vincula todo lo que sigue independientemente del circuito. El comportamiento documentado es lo bastante corto para leerlo directamente.

Las observaciones del navegador y las de la red responden a preguntas distintas, así que guárdelas en notas separadas. Una página que carga por Tor mientras la VPN está levantada le dice que el proxy funciona y nada sobre el comportamiento de descarte de la VPN. Un paquete bloqueado durante una caída no dice nada sobre si dos inicios de sesión eran vinculables una hora antes.

Dos registros, dos preguntas

Para el kill switch, pregunte si una aplicación concreta puede salir por una ruta no deseada durante un fallo, y traiga una caída controlada con un destino de registro que usted controle. Para el aislamiento del navegador, pregunte qué cuentas, estado y señales podrían vincular dos actividades, y traiga un flujo de trabajo en lugar de una captura de paquetes. Si una segunda aplicación importa, pruébela por separado, porque el alcance es por aplicación más a menudo de lo que los proveedores insinúan. Dos preguntas distintas producen dos artefactos distintos y un informe honesto.

Dibuje ambas rutas antes de probar: la ruta normal y la ruta tras un fallo del túnel, para cada aplicación incluida en el alcance. Un dibujo expone el hueco que esconde un solo indicador verde, porque le obliga a nombrar qué está cubierto y qué no. Hágalo mientras los sistemas están sanos, cuando nadie está bajo presión para declarar la comprobación terminada.

Ninguno de los dos controles certifica al otro, y una configuración combinada necesita ambos registros antes de poder reclamar ambas propiedades. Reclamar ambas a partir de un solo indicador verde es exactamente el fallo que este emparejamiento debe evitar.