O BrowserGate do LinkedIn, e por que uma única identidade de navegador não basta mais

No começo de abril, um grupo europeu de usuários do LinkedIn chamado Fairlinked e.V. publicou uma investigação que, dependendo de como você conta, foi ou a história mais detalhada ou a menos surpreendente de fingerprinting de navegador da década. O próprio JavaScript de front-end do LinkedIn, eles mostraram, dispara entre seis e sete mil requisições fetch() para URLs chrome-extension:// toda vez que você carrega o site, testa se cada uma resolve, coleta outras 48 características de dispositivo e navegador, e manda o pacote inteiro — criptografado com RSA, anexado a toda chamada de API seguinte — de volta para o endpoint de telemetria do LinkedIn.

A cobertura foi feita pelo The Next Web, verificada de forma independente pela 404 Privacy, e esmiuçada em nível de código num longo detalhamento técnico que percorre os payloads reais. A organização-irmã da Fairlinked, a Teamfluence Signal Systems, já havia pedido uma liminar preliminar em Munique em janeiro de 2026 sob o Digital Markets Act (DMA — a regulação europeia que governa como plataformas gatekeeper devem tratar usuários) da UE. O tribunal negou. O LinkedIn, por sua vez, disse a jornalistas que as alegações são "simplesmente erradas" e que seu escaneamento só tem como alvo extensões que violam seus termos de serviço.

Este post não é sobre o LinkedIn estar ou não dentro dos seus direitos legais na Irlanda ou na Alemanha. É sobre o que a história ilustra: o navegador em que você está lendo isto nunca foi projetado para reagir a esse tipo de coisa, e — mais importante — não consegue reagir, porque só tem uma identidade para dar.

O que a página realmente faz quando você visita linkedin.com

Há dois mecanismos rodando em paralelo, e vale entendê-los mesmo que você nunca abra o painel DevTools.

Detecção ativa de extensões. A página traz embutida uma lista fixa de mais de 6.000 IDs de extensões do Chrome. Para cada um, ela dispara um fetch() para um arquivo conhecido dentro do pacote daquela extensão — chrome-extension://<id>/manifest.json, por exemplo, ou um ícone específico. Se o fetch tem sucesso, a extensão está instalada; se o Chrome rejeita a requisição, não está. O truque só funciona em extensões que expõem pelo menos um "web-accessible resource", o que a maior parte das extensões reais expõe. A reportagem conta que uma variante furtiva usa window.requestIdleCallback() com delays escalonados para não acender o painel de rede.

Varredura passiva do DOM ("Spectroscopy"). Em paralelo, a página caminha pelo seu DOM procurando referências a URLs chrome-extension://. Isso pega extensões que injetam conteúdo na página — as que a lista fixa pode ter deixado escapar, ou as mais novas, que a lista ainda não aprendeu a conhecer.

Os resultados alimentam um pipeline de fingerprinting que, internamente, o LinkedIn chama de APFC, de "Anti-fraud Platform Features Collection", com um nome secundário de DNA, de "Device Network Analysis". Além da lista de extensões, o pipeline coleta:

Esses sinais são combinados em um blob criptografado e anexados como cabeçalho HTTP a toda chamada de API seguinte que a página faz — de forma que o backend do LinkedIn sempre sabe, em cada hop, exatamente qual é o dispositivo que é você. A investigação relata que o LinkedIn tomou providências — suspensões de conta, avisos — contra usuários rodando extensões de que não gosta, o que é a evidência mais direta de que os dados de fato são usados, e não apenas coletados.

Há uma pergunta real enterrada embaixo da jurídica: se o LinkedIn está fazendo isso nessa escala, quantos outros sites estão fazendo uma versão menor? A resposta honesta é: a maior parte dos grandes. O LinkedIn é incomum só na amplitude da sua lista de extensões e no esmero com que foi projetada. O resto da web de consumo roda o mesmo manual básico em graus variados de sofisticação.

O problema não é fingerprinting. É reuso de identidade.

Dê um passo atrás. Canvas, WebGL, WebRTC, enumeração de fontes — nada disso é novo. Todo pesquisador de segurança nos últimos dez anos escreveu um ensaio que termina com "ligue o resistFingerprinting do Firefox" ou "instale o CanvasBlocker". Esse conselho não está errado, exatamente, mas deixa escapar a parede de sustentação do problema.

Mesmo que você tivesse resistência perfeita a fingerprinting — todo sinal normalizado, todo canvas em branco, toda conexão WebRTC recusada —, seu navegador ainda tem um único pote de cookies, um único arquivo de histórico, um único conjunto de sessões logadas, um único cofre de senhas salvas, uma única lista de extensões instaladas, um único endereço IP na camada de rede. Tudo o que você faz na web sai dessa única identidade. Um fingerprinter que não consegue ler seu canvas ainda consegue perceber que a pessoa que entrou no LinkedIn, a pessoa que entrou no Facebook, a pessoa que olhou uma pequena livraria independente e a pessoa que checou o portal de saúde vieram todas da mesma instância de navegador, com os mesmos cookies, do mesmo IP. E o efeito de rede é cross-site: os dados do LinkedIn se tornam mais úteis no momento em que são cruzados com os de qualquer outro site.

É por isso que uma extensão anti-fingerprinting isolada não resolve de fato o problema, e por isso que "usar uma VPN" por cima de um navegador comum também não resolve. Uma VPN muda seu IP aparente, mas não divide seu navegador em múltiplas identidades. Você ainda tem um pote de cookies. Ainda tem um conjunto de sessões. LinkedIn e Facebook ainda enxergam a mesma máquina — e, agora, convenientemente para eles, uma máquina que foi cruzada com o histórico de IPs da VPN.

O argumento da VPN por aba

Aqui começa a parte que soa diferente. Como cada aba do Bromure é sua própria máquina virtual Linux descartável, a VPN pertence à aba, não ao navegador inteiro. Não ao computador inteiro. À aba.

Você pode anexar um endpoint Mullvad na Suécia ao seu perfil do LinkedIn, um endpoint ProtonVPN na Suíça ao seu perfil do Facebook, Cloudflare WARP a um perfil de "links aleatórios" e nada ao seu perfil de banco local — tudo ao mesmo tempo, no mesmo Mac, no mesmo app Bromure. O LinkedIn enxerga a saída sueca. O Facebook enxerga a saída suíça. O banco enxerga sua conexão de casa real. Nenhum deles tem uma forma limpa de perceber que está olhando para o notebook da mesma pessoa.

Essa não é uma separação teórica. O Bromure sobe um kernel Linux real por aba, usando o Virtualization.framework da Apple. Cada VM tem sua própria stack de rede de kernel, seu próprio /etc/hosts, sua própria árvore de processos, seu próprio conjunto de flags do Chromium, seu próprio diretório de perfil em seu próprio disco virtual. Duas abas em dois sites de fingerprinting, servidas por dois endpoints de VPN diferentes, são indistinguíveis de duas pessoas separadas usando dois notebooks separados, porque na camada em que o fingerprinting opera, elas são.

A configuração de VPN por aba vive no painel VPN & Ads do perfil, com três opções: Cloudflare WARP (o serviço de criptografia de consumo da Cloudflare), WireGuard (qualquer provedor, qualquer servidor auto-hospedado — cole um .conf) ou IKEv2 (para VPNs corporativas). A VPN roda dentro da VM, o que significa que nem mesmo o processo Chromium convidado enxerga o seu IP real.

O Bromure desliga o WebRTC por padrão

O WebRTC é a causa direta do vazamento de IP de LAN no BrowserGate. Ele foi projetado para chamadas de vídeo e áudio entre navegadores e, como efeito colateral da forma como descobre caminhos de rede, pode ser pedido a enumerar as suas interfaces de rede local. Qualquer site — não só os que você está chamando — pode rodar essa enumeração em segundo plano e aprender coisas como "este usuário recebeu o 192.168.1.47 do roteador, então ele está numa rede doméstica típica, que é a mesma faixa da última visita a partir deste fingerprint".

O Bromure desliga o WebRTC por padrão para todo perfil que não tenha simultaneamente webcam e microfone habilitados. Concretamente: quando um perfil não precisa de acesso a webcam ou microfone, o launcher do Bromure adiciona duas flags do Chromium:

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

e carrega uma pequena extensão de navegador chamada webrtc-block que substitui o construtor RTCPeerConnection por um stub que não faz nada. Essa última parte importa: a flag de política sozinha impede que o IP vaze por UDP, mas um fingerprinter determinado ainda consegue instanciar RTCPeerConnection e observar comportamento; o stub faz até o construtor falhar. O efeito líquido é que um site tentando o truque de IP de LAN do LinkedIn, num perfil do Bromure que não precisa de WebRTC, recebe de volta nada.

Você não precisa alternar nada para isso. É o estado padrão para qualquer perfil que não tenha hardware de chamada de vídeo habilitado. Se você ligar o compartilhamento de webcam ou microfone no painel Media de um perfil, os casos de uso de VPN e chamada de vídeo que precisam de WebRTC voltam automaticamente. A configuração é "ligado só quando você realmente precisa", o que está mais próximo de como a web deveria ter funcionado.

O que o isolamento não conserta

Duas coisas que vale nomear de cara. Primeiro, se você entra no LinkedIn com o seu nome verdadeiro a partir de todo perfil, o LinkedIn sabe que é você. O isolamento não te torna anônimo para serviços nos quais você voluntariamente faz login; ele quebra a junção de identidade cross-site e impede a reidentificação passiva entre sessões. Essas são vitórias reais, mas não são anonimato.

Segundo, o Bromure não consegue impedir o LinkedIn de rodar seu escaneamento de extensões dentro da VM do Bromure. Ele consegue, e faz, tornar os resultados do escaneamento desinteressantes: por padrão, um perfil do Bromure não tem extensões do Chrome instaladas além das internas do próprio Bromure, e essas vivem em IDs de extensão diferentes, com escopo de perfil, que a lista fixa do LinkedIn não inclui. A página sonda obedientemente 6.000 IDs; nada retorna. A impressão de 48 atributos ainda é coletada — mas ela identifica uma única VM descartável cujo WebRTC, cookies e IP não se sobrepõem com nenhuma outra VM que você roda.

Isso é o bastante para neutralizar o BrowserGate como ferramenta de correlação cross-site. Não é o bastante para te esconder do LinkedIn depois que você fez login, e não vamos fingir o contrário.

Configurações recomendadas no Bromure para o LinkedIn (e sites similares)

Se você está montando um perfil dedicado para o LinkedIn, ou um para o Facebook, ou qualquer outra plataforma social conhecida por fazer fingerprinting agressivo, estes são os padrões que vale checar. Tudo abaixo está no painel de configurações por perfil (ícone de engrenagem ao lado do perfil na lista).

Algumas observações não tão óbvias. WebRTC já está desligado para esse perfil enquanto webcam e microfone estiverem ambos desligados — você não precisa configurar em lugar nenhum, e não há caixa de seleção para isso, porque é derivado dessas duas configurações.

Se você está rodando um perfil dedicado do LinkedIn para trabalho e quer que a sessão de VPN sobreviva ao fechamento de abas individuais, pareie Reter Dados de Navegação com Connect on Startup no WireGuard — a VPN subirá automaticamente toda vez que você reabrir esse perfil.

Você pode ir mais longe. O painel Avançado tem uma opção Criptografar Dados de Navegação, que criptografa o disco persistente usando LUKS com uma chave guardada no Keychain do macOS. Esse é um nível razoável de paranoia para qualquer coisa próxima de rede social que você mesmo assim queira preservar entre reinicializações.

O formato da correção

O BrowserGate é um bom símbolo para algo que vem sendo verdade há um tempo e está piorando: navegadores comuns não conseguem reagir de forma significativa a essa classe de vigilância, porque toda a sua arquitetura é construída em torno de uma única identidade por instância de navegador. Você pode instalar extensões para mitigar vazamentos específicos, e deveria; mas a resposta estrutural é um navegador em que cada aba é seu próprio computador, com sua própria rede, sua própria superfície de privacidade e sua própria capacidade de terminar. Fecha a janela, e essa identidade — qualquer dado que o scanner do LinkedIn tenha coletado, qualquer cookie de correlação anexado — se foi.

Esse é o formato inteiro da correção. Ele não depende de o LinkedIn concordar em parar, e não depende do DMA. Depende de o seu navegador ter um formato diferente daquele que estava no notebook com o qual você o comprou.