El BrowserGate de LinkedIn y por qué una sola identidad de navegador ya no basta

A principios de abril, un grupo europeo de usuarios de LinkedIn llamado Fairlinked e.V. publicó una investigación que, según cómo se mire, fue o bien la historia más detallada o bien la menos sorprendente de la década sobre fingerprinting de navegadores. Demostraron que el propio JavaScript del frontend de LinkedIn lanza entre seis y siete mil peticiones fetch() a URLs chrome-extension:// cada vez que cargas el sitio, comprueba si cada una resuelve, recopila otras 48 características del dispositivo y del navegador, y envía el paquete completo —cifrado con RSA y adjuntado a cada llamada posterior a la API— de vuelta al endpoint de telemetría de LinkedIn.

La historia fue recogida por The Next Web, verificada de forma independiente por 404 Privacy, y sometida a ingeniería inversa a nivel de código en un desglose técnico extenso que recorre los payloads reales. La organización hermana de Fairlinked, Teamfluence Signal Systems, ya había presentado una medida cautelar en Múnich en enero de 2026 al amparo del Digital Markets Act (DMA) de la UE —la regulación europea que rige cómo las plataformas guardianas deben tratar a los usuarios—. El tribunal la denegó. LinkedIn, por su parte, declaró a los periodistas que las acusaciones son «sencillamente falsas» y que su escaneo solo apunta a extensiones que violan sus condiciones de servicio.

Este artículo no trata sobre si LinkedIn actúa dentro de sus derechos legales en Irlanda o Alemania. Trata sobre lo que la historia ilustra: el navegador con el que estás leyendo esto nunca fue diseñado para oponerse a este tipo de cosas y —lo que es más importante— no puede hacerlo, porque solo tiene una identidad que ofrecer.

Lo que la página realmente hace cuando visitas linkedin.com

Hay dos mecanismos funcionando en paralelo, y merece la pena entenderlos aunque no abras jamás un panel de DevTools.

Detección activa de extensiones. La página incluye una lista codificada en duro de más de 6000 IDs de extensiones de Chrome. Para cada una, lanza un fetch() a un archivo conocido dentro del paquete de esa extensión —chrome-extension://<id>/manifest.json, por ejemplo, o un icono específico—. Si el fetch tiene éxito, la extensión está instalada; si Chrome rechaza la petición, no lo está. El truco solo funciona con extensiones que expongan al menos un «web-accessible resource», cosa que hacen la mayoría de las extensiones reales. El artículo informa de que una variante sigilosa usa window.requestIdleCallback() con retardos escalonados para no iluminar el panel de red.

Escaneo pasivo del DOM («Spectroscopy»). Por separado, la página recorre tu DOM buscando referencias a URLs chrome-extension://. Esto captura las extensiones que inyectan contenido en la página —las que la lista codificada en duro podría haber omitido, o las más nuevas que la lista aún no conoce.

Los resultados alimentan una canalización de fingerprinting que LinkedIn llama internamente APFC, por «Anti-fraud Platform Features Collection», con el nombre secundario DNA por «Device Network Analysis». Junto a la lista de extensiones, la canalización recopila:

Estas señales se combinan en un blob cifrado y se adjuntan como cabecera HTTP a cada petición posterior de la API que la página realiza —de modo que el backend de LinkedIn siempre sabe, en cada salto, qué dispositivo exacto eres—. La investigación informa de que LinkedIn ha tomado medidas —suspensiones de cuentas, avisos— contra usuarios que ejecutan extensiones que no le gustan, lo que constituye la prueba más directa de que los datos se usan de verdad y no solo se recopilan.

Hay una pregunta real enterrada bajo la pregunta legal: si LinkedIn está haciendo esto a esta escala, ¿cuántos otros sitios están haciendo una versión más pequeña? La respuesta honesta es: la mayoría de los grandes. LinkedIn es inusual solo por la amplitud de su lista de extensiones y por el esmero con el que fue diseñado. El resto de la web de consumo ejecuta el mismo manual básico con distintos niveles de sofisticación.

El problema no es el fingerprinting. Es la reutilización de identidad.

Da un paso atrás. Canvas, WebGL, WebRTC, enumeración de fuentes: nada de esto es nuevo. Cada investigador de seguridad de los últimos diez años ha escrito un artículo que termina con «activa el resistFingerprinting de Firefox» o «instala CanvasBlocker». Ese consejo no está equivocado, exactamente, pero pasa por alto el muro de carga del problema.

Incluso si tuvieras una resistencia al fingerprinting perfecta —cada señal normalizada, cada canvas en blanco, cada conexión WebRTC rechazada—, tu navegador seguiría teniendo un único tarro de cookies, un único archivo de historial, un único conjunto de sesiones iniciadas, una única caja fuerte de contraseñas guardadas, una única lista de extensiones instaladas, una única dirección IP en la capa de red. Todo lo que haces en la web sale de esa única identidad. Un fingerprinter que no pueda leer tu canvas aún puede deducir que la persona que se logueó en LinkedIn, la persona que se logueó en Facebook, la persona que miró una pequeña librería independiente y la persona que consultó su portal de salud vienen todas de la misma instancia de navegador con las mismas cookies desde la misma IP. Y el efecto de red es transversal: los datos de LinkedIn se vuelven más útiles en el momento en que se cruzan con los de cualquier otro sitio.

Por eso una extensión anti-fingerprinting aislada no arregla realmente el problema, y por eso «usar una VPN» encima de un navegador normal tampoco lo arregla. Una VPN cambia tu IP aparente, pero no divide tu navegador en varias identidades. Sigues teniendo un único tarro de cookies. Sigues teniendo un único conjunto de sesiones. LinkedIn y Facebook siguen viendo la misma máquina —y ahora, cómodamente para ellos, una máquina que ha sido cotejada con el historial de IPs de una VPN.

El argumento de la VPN por pestaña

Aquí es donde la cosa empieza a sentirse distinta. Como cada pestaña de Bromure es su propia máquina virtual Linux desechable, la VPN pertenece a la pestaña, no a todo el navegador. No a todo el ordenador. A la pestaña.

Puedes asociar un endpoint de Mullvad en Suecia a tu perfil de LinkedIn, un endpoint de ProtonVPN en Suiza a tu perfil de Facebook, Cloudflare WARP a un perfil de «enlaces aleatorios» y nada en absoluto a tu perfil de banca local —todo a la vez, en el mismo Mac, en la misma app de Bromure—. LinkedIn ve la salida sueca. Facebook ve la salida suiza. El banco ve tu conexión doméstica real. Ninguno de ellos tiene una forma limpia de darse cuenta de que están mirando el portátil de la misma persona.

Esta no es una separación teórica. Bromure arranca un kernel Linux real por pestaña, usando Apple's Virtualization.framework. Cada VM tiene su propia pila de red en el kernel, su propio /etc/hosts, su propio árbol de procesos, su propio conjunto de flags de Chromium, su propio directorio de perfil en su propio disco virtual. Dos pestañas en dos sitios que hacen fingerprinting, servidas por dos endpoints de VPN distintos, son indistinguibles de dos personas separadas usando dos portátiles separados, porque en la capa en la que opera el fingerprinting, eso es lo que son.

El ajuste de VPN por pestaña vive bajo el panel VPN y Anuncios del perfil, con tres opciones: Cloudflare WARP (el servicio de cifrado de consumo de Cloudflare), WireGuard (cualquier proveedor, cualquier servidor autoalojado —pega un .conf) o IKEv2 (para VPNs corporativas). La VPN corre dentro de la VM, lo que significa que ni siquiera el proceso de Chromium invitado ve tu IP real.

Bromure desactiva WebRTC por defecto

WebRTC es la causa directa de la fuga de IP de LAN en BrowserGate. Se diseñó para llamadas de video y audio entre navegadores y, como efecto colateral de cómo descubre rutas de red, se le puede pedir que enumere las interfaces de tu red local. Cualquier sitio —no solo aquellos a los que estás llamando— puede ejecutar esa enumeración en segundo plano y aprender cosas como «a este usuario su router le asignó 192.168.1.47, así que está en una red doméstica típica, que es el mismo rango que la última visita con esta huella».

Bromure desactiva WebRTC por defecto para cualquier perfil que no tenga habilitados tanto webcam como micrófono. En concreto: cuando un perfil no necesita acceso a webcam ni a micrófono, el lanzador de Bromure añade dos flags de Chromium:

• --force-webrtc-ip-handling-policy=disable_non_proxied_udp
• --enforce-webrtc-ip-permission-check

y carga una pequeña extensión de navegador llamada webrtc-block que reemplaza el constructor RTCPeerConnection por un stub vacío. Esto último importa: el flag de política por sí solo impide que la IP se filtre por UDP, pero un fingerprinter decidido aún puede instanciar RTCPeerConnection y observar su comportamiento; el stub hace que incluso el constructor falle. El efecto neto es que un sitio que intente el truco de la IP de LAN al estilo LinkedIn, sobre un perfil de Bromure que no necesite WebRTC, no obtiene nada a cambio.

No tienes que alternar nada para esto. Es el estado por defecto para cualquier perfil que no tenga habilitado hardware de videollamada. Si activas la compartición de webcam o micrófono en el panel Medios de un perfil, los casos de uso de VPN y videollamada que necesitan WebRTC vuelven automáticamente. El ajuste es «activo solo cuando realmente lo necesitas», que se parece más a cómo se suponía que debía funcionar la web.

Lo que el aislamiento no arregla

Dos cosas que conviene nombrar desde el principio. Primero, si inicias sesión en LinkedIn con tu nombre real desde cada perfil, LinkedIn sabe que eres tú. El aislamiento no te vuelve anónimo frente a los servicios en los que te logueas voluntariamente; rompe la unión de identidad entre sitios y detiene la reidentificación pasiva entre sesiones. Son victorias reales, pero no son anonimato.

Segundo, Bromure no puede impedir que LinkedIn ejecute su escaneo de extensiones dentro de la VM de Bromure. Lo que sí puede —y lo hace— es hacer que los resultados del escaneo resulten poco interesantes: por defecto, un perfil de Bromure no tiene ninguna extensión de Chrome instalada aparte de las internas propias de Bromure, y esas viven en IDs de extensión distintos, limitados por perfil, que la lista codificada en duro de LinkedIn no incluye. La página sondea diligentemente 6000 IDs; no le vuelve nada. La huella de 48 atributos sigue recopilándose, pero identifica a una VM desechable cuyo WebRTC, cookies e IP no se solapan con ninguna otra VM que ejecutes.

Eso es suficiente para desactivar BrowserGate como herramienta de correlación entre sitios. No es suficiente para ocultarte de LinkedIn una vez que has iniciado sesión, y no vamos a fingir lo contrario.

Ajustes recomendados de Bromure para LinkedIn (y sitios similares)

Si estás configurando un perfil dedicado a LinkedIn, o a Facebook, o a cualquier otra plataforma social conocida por hacer fingerprinting agresivo, estos son los valores por defecto que merece la pena revisar. Todo lo de abajo está en el panel de ajustes por perfil (icono de engranaje junto al perfil en la lista).

Algunas notas menos evidentes. WebRTC ya está desactivado para este perfil mientras webcam y micrófono estén ambos apagados: no necesitas configurarlo en ninguna parte, y no hay casilla para ello, porque se deriva de esos dos ajustes.

Si llevas un perfil dedicado a LinkedIn para trabajo y quieres que la sesión de VPN sobreviva a los cierres individuales de pestaña, combina Conservar datos de navegación con Conectar al inicio bajo WireGuard: la VPN se levantará automáticamente cada vez que vuelvas a abrir ese perfil.

Puedes ir más allá. El panel Avanzado tiene una opción Cifrar datos de navegación que cifra el disco persistente usando LUKS con una clave almacenada en el Keychain de macOS. Ese es un nivel razonable de paranoia para cualquier cosa cercana a redes sociales que, aun así, quieras que sobreviva a los reinicios.

La forma de la solución

BrowserGate es un buen símbolo de algo que lleva un tiempo siendo cierto y que va a peor: los navegadores normales no pueden oponerse de manera significativa a esta clase de vigilancia, porque toda su arquitectura está construida alrededor de una única identidad por instancia de navegador. Puedes instalar extensiones para mitigar fugas concretas, y deberías; pero la respuesta estructural es un navegador en el que cada pestaña es su propio ordenador, con su propia red, su propia superficie de privacidad y su propia capacidad de terminar. Cierra la ventana y esa identidad —los datos que el escáner de LinkedIn haya recopilado, las cookies de correlación que se hayan adjuntado— desaparece.

Esa es la forma completa de la solución. No depende de que LinkedIn acepte parar, y no depende del DMA. Depende de que tu navegador tenga una forma distinta de aquel que venía en el portátil con el que lo compraste.