Olá a todos!
Disclaimer antes de começar: uso o LinkedIn. Tenho perfil, faço conexões, às vezes até posto coisas :]. A probabilidade alta é que tenham descoberto este blog pelos meus posts por lá.
Estou tão preso naquela plataforma como o resto de nós. O que vou descrever aqui não é razão para pânico — mas é razão para pensar com mais cuidado sobre o que corre no vosso browser quando abrem aquele separador que todos temos sempre aberto.
Há uns dias deparei-me com uma investigação publicada pela Fairlinked e.V. — uma associação europeia de utilizadores comerciais do LinkedIn — que me fez fechar o computador durante dez minutos e ir fazer um café enquanto deixava aquilo assentar. Não porque seja tecnicamente impossível. Não porque seja sequer surpreendente, para quem já passou tempo a perceber como estas plataformas funcionam por baixo. É perturbador precisamente porque é metódico. Porque não parece um acidente nem uma feature mal documentada. Parece um sistema desenhado, testado, expandido ao longo de anos, e nunca mencionado a ninguém.
O nome que lhe deram é BrowserGate. E vale a pena perceber o que é, como funciona, e porque é que devia importar-vos — independentemente de se são marketers, developers, ou simplesmente pessoas que têm uma conta no LinkedIn e preferem não ser varridas por um scanner de inteligência sem o vosso conhecimento.
Uma pequena curiosidade, o próprio chatpgt censura quando lhe pedes para fazer uma ilustração sobre o tema. Para referencia, a openAI e o LinkedIn tem a mesma parent company: Micro$oft.
O ficheiro JavaScript que está no centro de tudo
Toda a investigação técnica parte de um único ponto: um bundle JavaScript que o LinkedIn serve a todos os utilizadores com Chrome (e derivados — Edge, Brave, Opera, Arc) quando visitam o site. O ficheiro foi identificado como Webpack chunk ID “chunk.905”, módulo de extensão scan 75023, com 2,7 megabytes e 13.159 linhas de código minificado. O framework é Ember.js.
Dentro desse bundle, na linha 9571, existe um array hardcoded. Cada entrada tem dois campos: um ID de extensão da Chrome Web Store com 32 caracteres, e um caminho interno conhecido dentro do package dessa extensão — coisas como popup.html, icon.png, ou manifest.json.
São 6.222 extensões. Seis mil duzentas e vinte e duas.
Isto não é uma lista gerada automaticamente por scraping de IDs aleatórios. É uma lista curada. Alguém no LinkedIn identificou individualmente um recurso web-acessível específico para cada uma dessas extensões. Alguém manteve essa lista ao longo do tempo. Alguém a expandiu — de 38 extensões em 2017 para 6.222 em fevereiro de 2026. O crescimento nos últimos dois meses documentados foi de aproximadamente 12 extensões por dia.
O nome do ficheiro JavaScript muda a cada deployment, porque é derivado do content hash. Mas as string literals, os URLs de endpoint, e as funções de deteção são pesquisáveis por keyword. Qualquer pessoa com as DevTools do Chrome pode abrir o LinkedIn, localizar o bundle mais pesado (cerca de 2,7 MB), e pesquisar a string fetchExtensions ou qualquer ID de extensão Chrome para encontrar o sistema.
Está lá. Verificável. Público. Simplesmente nunca foi anunciado.
Como funciona o scan: três camadas que se complementam
A arquitetura de deteção opera em três fases. Cada uma foi desenhada para apanhar o que a anterior não consegue.
Fase 1: Comunicação direta. O código tenta contactar cada extensão usando a Chrome Messaging API (externally_connectable). Se o developer da extensão desactivou este canal no manifest.json, a deteção falha e o sistema avança para a fase seguinte.
Fase 2: Resource probing. Usando a API fetch() do browser, o código tenta aceder a um ficheiro interno conhecido de cada extensão. Usa Promise.allSettled(), o que significa que os 6.222 pedidos são disparados simultaneamente. Um response bem-sucedido significa que a extensão está instalada. Um rejection significa que não está. Há também um modo sequencial controlado por um parâmetro chamado staggerDetectionMs, que introduz um delay configurável entre cada probe — suficiente para reduzir a visibilidade do scan em ferramentas de monitorização de rede.
Fase 3: Spectroscopy. É o mais interessante — e o mais invasivo. Em vez de consultar ficheiros de extensões, percorre toda a DOM tree da página, inspecionando cada text node e atributo de elemento à procura da string "chrome-extension://". Qualquer extensão que tenha injectado elementos, modificado atributos, ou adicionado scripts à página deixa rastros na DOM que o Spectroscopy extrai. O ID da extensão com 32 caracteres é retirado do URL fragment. Uma VPN que modifique um único pixel da página renderizada é detectável por este método.
Os dois métodos principais complementam-se de uma forma específica: o resource probing detecta extensões instaladas que não injectaram nada na página actual; o Spectroscopy detecta extensões que modificam activamente a página mas que podem não estar na lista hardcoded. Juntos cobrem ambos os casos.
48 pontos de dados por sessão
O scan de extensões alimenta um sistema de fingerprinting mais abrangente que a investigação identifica internamente como APFC — Anti-fraud Platform Features Collection — também referido como DNA (Device Network Analysis). O sistema recolhe 48 características distintas do browser e do dispositivo.
Identificadores de hardware incluem número de núcleos de CPU (hardwareConcurrency), memória disponível (deviceMemory), resolução de ecrã e profundidade de cor, e características de hardware de áudio capturadas através de um AudioContext fingerprint com nós de oscilador, compressor e analisador. Características de rede incluem endereço IP local via WebRTC, tipo de ligação, velocidade de download, e round-trip time. Canvas e WebGL fingerprints são capturados através de elementos ocultos renderizados; a recolha WebGL inclui 65 valores de parâmetros separados mais strings de renderer e vendor. O sistema também enumera fontes de sistema instaladas, câmaras, microfones e colunas ligadas via enumerateDevices, e regista nível de bateria, estado de carregamento e tempo estimado de descarga.
Há um detalhe que merece atenção especial. A feature número 23 na lista APFC é doNotTrack — a configuração do browser através da qual um utilizador sinaliza que não quer ser rastreado. O LinkedIn regista esta configuração. Depois exclui-a do hash do fingerprint usando um parâmetro na linha 9512: excludes: { doNotTrack: true }. O dado é recolhido. Simplesmente não é incluído no fingerprint usado para identificação. O LinkedIn regista que pediste para não ser rastreado. E depois rastreia-te na mesma.
Depois de combinados os 48 pontos e os resultados do scan de extensões, o payload é serializado em JSON e cifrado com uma chave pública RSA identificada como apfcDfPK. O payload cifrado é transmitido para três endpoints: linkedin.com/li/track, /platform-telemetry/li/apfcDf, e /apfc/collect. É armazenado em globalThis.apfcDf e injectado como header HTTP em cada pedido subsequente feito durante a sessão. Cada pesquisa, cada perfil visitado, cada pedido de conexão — tudo carrega o fingerprint cifrado como header.
Nada disto está mencionado na política de privacidade do LinkedIn.
Três serviços externos que também recebem dados
Para além dos endpoints do LinkedIn, a investigação identifica três serviços externos que recebem dados como parte do mesmo bundle JavaScript.
O primeiro é a HUMAN Security, anteriormente conhecida como PerimeterX — uma empresa de cibersegurança americano-israelita. O LinkedIn carrega um iframe oculto de li.protechts.net com dimensões 0x0 pixels, posicionado em left: -9999px, e marcado como aria-hidden="true". O iframe passa um timestamp, o tree ID da página, um cookie de sessão com hash (bcookie), e um app ID hardcoded. Lê e define cookies PerimeterX através de cross-origin postMessage. Em maio de 2024, o LinkedIn integrou a HUMAN Security na sua plataforma de publicidade como parceiro de deteção de tráfego inválido. A investigação BrowserGate revela que a mesma integração opera ao nível da infraestrutura de browser em cada carregamento de página, para todos os utilizadores, não apenas em contextos publicitários.
O segundo serviço externo é o Merchant Pool, acessível via merchantpool1.linkedin.com. Um script de fingerprinting separado carrega deste domínio, passando o cookie de sessão do utilizador e um instance ID hardcoded. O terceiro é o Google reCAPTCHA v3 Enterprise, que o LinkedIn carrega e executa no carregamento da página com a acção “onPageLoad”, recolhendo o token resultante silenciosamente.
Nenhum destes fluxos de dados está divulgado na política de privacidade do LinkedIn.
O que está nas 6.222 extensões e o que isso revela sobre quem as usa
Esta é provavelmente a parte que mais me perturbou quando li a investigação. Porque a lista de extensões não é aleatória. É uma lista que, quando analisada por categoria, revela exactamente que tipo de inteligência o LinkedIn está a tentar extrair.
Ferramentas de inteligência comercial concorrente: 209 extensões, incluindo Apollo (600.000 utilizadores), Lusha (300.000), ZoomInfo (300.000), e Kaspr. O produto Sales Navigator do LinkedIn gera aproximadamente mil milhões de dólares por ano em receita. Detectar que os colaboradores de uma empresa estão a usar ferramentas concorrentes dá ao LinkedIn visibilidade em tempo real sobre quais as organizações que estão a avaliar alternativas ao seu próprio produto.
Extensões de pesquisa de emprego: 509 entradas com uma base de utilizadores combinada de 1,4 milhões de pessoas. Detectar estas extensões no browser de alguém cujo perfil mostra um empregador actual significa que o LinkedIn sabe que essa pessoa está a procurar trabalho em silêncio — na mesma plataforma onde o seu gestor e colegas estão activos. Na maioria das jurisdições, é ilegalmente discriminatório perguntar a um colaborador sobre intenções de emprego. O LinkedIn construiu um sistema que infere exactamente essa informação sem qualquer divulgação.
Extensões religiosas: A lista inclui PordaAI (descrita como “Blur Haram objects in Images and Videos, Real-time AI for Islamic values”, com aproximadamente 5.000 utilizadores) e Deen Shield (“Blocks haram & distracting sites, Quran Home Tab”). Detectar qualquer uma destas extensões no browser de um utilizador identificado é, segundo a análise legal da investigação, processar dados que revelam crença religiosa — uma categoria que o RGPD proíbe recolher sem consentimento explícito.
Extensões políticas: Incluem “Anti-woke” (“Shows warnings about woke companies”), “Anti-Zionist Tag” (“Adds a tag to the LinkedIn profiles of Anti-Zionists”), “No more Musk” (“Hides digital noise related to Elon Musk”), e “Political Circus” (“Politician to Clown AI Filter”). Opiniões políticas são também dados de categoria especial sob o Artigo 9 do RGPD.
Ferramentas para neurodivergência e deficiência: Inclui “simplify”, descrita explicitamente como uma ferramenta “for neurodivergent users”, com aproximadamente 79 utilizadores. Detectar esta extensão é, sob a interpretação do Tribunal de Justiça da UE no caso Lindenapotheke (C-21/23, outubro de 2024), processar dados de saúde — independentemente da intenção declarada do controlador.
Ferramentas de segurança e privacidade: Incluem Malwarebytes Browser Guard (10 milhões de utilizadores), KeepSolid VPN Unlimited, Zoho Vault, e LinkedIn Profile Privacy Shield. Mapear quais os colaboradores de quais organizações que usam ferramentas de segurança revela a postura de segurança dessas organizações — informação sensível para equipas de IT empresarial e agências governamentais.
O afidavit sob juramento que confirma o que negam publicamente
A investigação inclui um afidavit apresentado em processos judiciais alemães por Milinda Lakkam, identificada como Senior Manager of Software Engineering and Machine Learning na LinkedIn Corporation. O documento foi apresentado a 6 de fevereiro de 2026 em Mountain View, Califórnia, e referenciado como documento judicial Anlage AG 4. Lakkam identifica-se como a pessoa no LinkedIn responsável por “desenvolver e implementar os sistemas técnicos anti-abuso em múltiplas camadas relacionados com scraping.”
O parágrafo 3 do afidavit afirma: “O LinkedIn investiu em mecanismos de deteção de extensões sem os quais o LinkedIn não teria sido capaz de rastrear a causa de impactos de serviço e interrupções.” O parágrafo 5 repete a admissão em termos similares. Estas declarações confirmam que a deteção de extensões é um investimento de engenharia deliberado e sustentado, não um subproduto técnico incidental.
O parágrafo 4 do mesmo documento contém uma tensão interna que a investigação sublinha. O afidavit afirma simultaneamente que os modelos do LinkedIn “não têm em conta o uso de quaisquer extensões de browser específicas” e que os sistemas do LinkedIn “podem ter tomado acções contra utilizadores do LinkedIn que por acaso têm [XXXXXX] instalado.” Se os modelos não consideram quais extensões estão presentes, não é claro como é que acções de enforcement dirigidas contra utilizadores de extensões específicas poderiam ocorrer. Numa declaração sob juramento.
A exposição legal: não é apenas uma multa de RGPD
A análise legal da investigação identifica violações em seis frameworks jurídicos distintos. Vale a pena percorrê-los, porque a dimensão da exposição é relevante.
RGPD Artigo 9: Proíbe o processamento de dados que revelem origem racial ou étnica, opiniões políticas, crenças religiosas, dados de saúde, e categorias relacionadas. A proibição não é condicional à intenção. O Tribunal de Justiça da UE confirmou no caso Meta Platforms v. Bundeskartellamt (C-252/21, julho de 2023) que dados de navegação e de uso de aplicações qualificam como dados de categoria especial quando permitem inferir características protegidas. A multa máxima é 20 milhões de euros ou 4% do volume de negócios global anual. A receita anual da Microsoft no ano fiscal de 2025 foi de 281,72 mil milhões de dólares. Quatro por cento disso é 11,27 mil milhões de dólares.
RGPD Artigos 6, 13 e 14: Requerem base legal para qualquer processamento de dados pessoais e divulgação transparente do processamento no momento da recolha. A política de privacidade do LinkedIn não menciona o scan de extensões.
Directiva ePrivacy: Exige consentimento explícito antes de aceder a informação armazenada no dispositivo terminal do utilizador. Cada um dos 6.222 pedidos fetch para URLs chrome-extension:// é, pela letra desta directiva, um acesso a informação no dispositivo do utilizador. A Alemanha transpôs este requisito como TTDSG secção 25, com penalidades de até 300.000 euros por violação.
Direito penal alemão: O §202a do Strafgesetzbuch criminaliza o acesso não autorizado a dados, com pena de até três anos de prisão. O Tribunal Federal de Justiça alemão confirmou no caso 5 StR 614/19 que mesmo medidas de segurança que podem ser rapidamente contornadas qualificam como “besondere Sicherung” (medidas de segurança especiais). Quando um developer de extensão define externally_connectable como desactivado no manifest.json, isso é uma fronteira de segurança explícita. O sistema de três fases do LinkedIn contorna-a. Os §§202b e 202c cobrem intercepção de dados e preparação para espionagem de dados respectivamente, e o §23 da Geschäftsgeheimnisgesetz cobre roubo de segredos comerciais — que a investigação argumenta aplicar-se a cada um dos 6.222 fornecedores de software cujas listas de clientes o LinkedIn está efectivamente a extrair.
Reino Unido: A Secção 1 do Computer Misuse Act 1990 criminaliza o acesso não autorizado a material informático, com pena de até dois anos de prisão. O UK GDPR aplica o Artigo 9 com força idêntica, com multa máxima de 17,5 milhões de libras ou 4% do volume de negócios global.
Estados Unidos: A CCPA e CPRA da Califórnia requerem divulgação da recolha de informação pessoal. A California Invasion of Privacy Act prevê danos estatutários de 5.000 dólares por violação, sem necessidade de provar dano real. Aplicado a milhões de utilizadores californianos do LinkedIn, representa exposição potencial significativa.
A cronologia do verdadeiro problema
A investigação dedica atenção considerável à taxa de crescimento da lista de extensões, e há um motivo específico para isso.
Em setembro de 2023, a Comissão Europeia designou o LinkedIn da Microsoft como gatekeeper sob o Digital Markets Act, exigindo à plataforma que abrisse o acesso a ferramentas de terceiros sob o Artigo 6(10). A resposta do LinkedIn foi publicar duas APIs restritas que processam aproximadamente 0,07 chamadas por segundo. Enquanto isso, o LinkedIn opera internamente uma API chamada Voyager que alimenta todos os seus produtos web e mobile a 163.000 chamadas por segundo. O relatório de conformidade de 249 páginas da Microsoft à UE menciona a palavra “API” 533 vezes. A palavra “Voyager” aparece zero vezes.
Agora olhemos para os números do scan de extensões:
- 2017: 38 extensões
- 2024: ~461 extensões
- Maio de 2025: ~1.000 extensões
- Dezembro de 2025: 5.459 extensões
- Fevereiro de 2026: 6.167 extensões
A aceleração da lista sobrepõe-se directamente ao período de conformidade com o DMA. O regulamento exigia que o LinkedIn tolerasse ferramentas concorrentes de terceiros. Segundo a investigação, o LinkedIn construiu um sistema de vigilância para identificar cada utilizador dessas ferramentas.
Em outubro de 2024, a Comissão de Protecção de Dados irlandesa multou o LinkedIn em 310 milhões de euros por processar dados pessoais para publicidade dirigida sem base legal válida sob o RGPD. Três meses depois, a lista de extensões estava a crescer 12 por dia.
A dimensão que vai além da privacidade individual
A preocupação mais profunda da investigação não é a violação de privacidade individual. É o que os dados permitem à escala.
Porque cada conta LinkedIn está associada a um nome real, empregador, título de função, e localização, cada resultado do scan de extensões é atribuído a uma pessoa específica numa organização específica. Agregar resultados através de todos os colaboradores de uma empresa que usam o LinkedIn produz um perfil da stack tecnológica dessa empresa — qual o CRM que usam, quais as ferramentas de vendas, quais os produtos de segurança, qual o software de produtividade — montado sem o conhecimento da empresa.
A investigação estende esta lógica a governos. Ministérios europeus de defesa, agências de inteligência, organismos de aplicação da lei, reguladores, e funcionários eleitos têm todos perfis no LinkedIn. O scan do LinkedIn não distingue entre um gestor de marketing numa startup e um analista de cibersegurança num ministério governamental. Ambos são varridos. Ambos têm os seus resultados transmitidos para servidores do LinkedIn nos Estados Unidos. Os próprios funcionários da Comissão Europeia responsáveis pela investigação DMA ao LinkedIn estão, muito provavelmente, no LinkedIn.
Isto não é especulação sobre intenções. É a consequência lógica de um sistema que recolhe 48 características de hardware e software, escaneia 6.222 extensões, e associa tudo isso a perfis profissionais reais com localização, empregador, e função identificados.
O que isto significa para quem trabalha com publicidade B2B no LinkedIn
Há uma dimensão comercial aqui que merece ser dita claramente, sem rodeios.
O LinkedIn é simultaneamente a plataforma dominante para publicidade B2B — com uma quota de 41% dos budgets publicitários B2B segundo dados de março de 2026 — e o sujeito de uma investigação que alega que está a usar inteligência ao nível do browser para mapear os ambientes de software dos seus próprios anunciantes.
Se o LinkedIn consegue detectar que colaboradores de uma empresa estão a usar Apollo, Lusha, ou ZoomInfo — ferramentas que concorrem directamente com o Sales Navigator — tem visibilidade em tempo real sobre quais as empresas que estão a avaliar alternativas. Essa informação tem valor directo para as próprias equipas de vendas e produto do LinkedIn. Tem também potencialmente implicações para como a plataforma responde a essas empresas enquanto anunciantes — embora o LinkedIn negue usar os dados para esse fim.
O LinkedIn nega. Mas a negação vem da mesma empresa que ficou confirmado em tribunal ter “investido em mecanismos de deteção de extensões”, que cresceu de 38 para 6.222 extensões scaneadas durante o período em que era supostamente a construir conformidade com o DMA, e que nunca mencionou nada disto na sua política de privacidade.
O padrão que volta a emergir
Este caso encaixa num padrão que já escrevi aqui algumas vezes, sob formas diferentes.
Ferramentas e plataformas que se tornaram infraestrutura crítica para o trabalho profissional têm comportamentos não documentados que afectam privacidade, segurança, e em alguns casos a lei. Escrevi sobre o GitHub e o treino de modelos com código de repositórios privados. Sobre o Cline CLI e tokens comprometidos como vectores de supply chain. Sobre o Claude Code e telemetria silenciosa que invalida o KV cache de backends locais. A história é sempre variações do mesmo tema: os comportamentos que mais importam são os que menos são anunciados.
O que torna o BrowserGate diferente das histórias anteriores é a escala e a metodologia. Não é um comportamento incidental ou mal pensado. É um sistema com três fases de deteção, 6.222 alvos curados individualmente, cifra RSA, transmissão para múltiplos endpoints incluindo terceiros, e injecção como header em cada pedido subsequente. Alguém o desenhou. Alguém o testou. Alguém o expandiu sistematicamente ao longo de quase uma década.
A resposta a este padrão não é paranoia. É ceticismo saudável sobre o que as plataformas fazem com a nossa informação, preferência por aquelas cujo comportamento é auditável, e — onde for possível — controlo sobre a nossa própria infraestrutura de informação.
No caso do LinkedIn, o controlo é limitado. É uma plataforma de rede, e o valor de uma rede de contactos profissionais está precisamente em estar onde todos os outros estão. Mas há coisas que se podem fazer: usar o Firefox em vez de um browser Chromium quando se visita o LinkedIn (a investigação confirma que o scan de extensões Chrome não funciona no Firefox), ser consciente do que as extensões instaladas revelam sobre quem é, e — se forem responsáveis por decisões de segurança numa organização — tratar este relatório como informação relevante para a vossa avaliação de risco.
O estado actual
Os processos legais da Fairlinked contra o LinkedIn sob o DMA foram confirmados como apresentados. O evidence pack está disponível para download e é criptograficamente verificável. O BleepingComputer confirmou independentemente, através de testes realizados no início de abril de 2026, que o script de scan de extensões do LinkedIn está activo e a detectar 6.236 extensões. Queixas podem ser apresentadas junto de qualquer autoridade de protecção de dados de um Estado-Membro da UE, com a Comissão de Protecção de Dados irlandesa como regulador principal do LinkedIn na UE.
O código é verificável. O afidavit é um documento judicial público. A análise legal está fundamentada em estatutos e jurisprudência. E a lista tem agora 6.236 entradas — e está a crescer.
Um abraço, Nuno
P.S.: Para quem quiser verificar por si mesmo: abra o LinkedIn no Chrome, abra as DevTools (F12), vá ao separador Sources, encontre o bundle JavaScript maior (~2,7 MB), e pesquise a string fetchExtensions. O sistema está lá, em código minificado mas legível, servido em cada carregamento de página. Não é necessário acreditar na minha palavra nem na da Fairlinked.
P.P.S.: A investigação completa, incluindo o evidence pack com timestamp criptográfico RFC 3161, está em browsergate.eu. Quem tiver curiosidade técnica vai encontrar lá documentação suficiente para verificar cada afirmação feita neste post. Quem tiver curiosidade legal vai encontrar uma análise jurídica detalhada para cada jurisdição mencionada. Vale a pena ler.
P.P.P.S.: Se usam o LinkedIn para gestão de campanhas B2B e isto vos preocupa do ponto de vista da vossa organização, a questão mais imediata não é abandonar a plataforma — é perceber que dados sobre a vossa stack tecnológica interna podem estar a ser recolhidos de formas que não contrataram nem autorizaram. Isso é uma conversa que vale a pena ter com as vossas equipas de segurança e jurídicas. Se precisarem de ajuda a estruturá-la, já sabem onde me encontrar.
Disclamer: Este post foi escrito com ajuda de AI, por ser demasiada informação cruzada e precisava mesmo de entender as ramificações legais.