Como o LinkedIn deteta a automatização: conclusões da análise do código de 16 extensões, dos testes na cloud e do motor de deteção do LinkedIn

Analisámos 16 extensões de automatização de atividades no LinkedIn para perceber o que fazem com sessões, cookies, chamadas do navegador e servidores dos fornecedores.

Também criámos contas em sete serviços cloud, com duas contas em cada um, e comparámos os endereços IP de saída que lhes foram atribuídos com uma base de dados independente sobre reputação e risco de fraude.

A terceira parte da investigação analisou o código das próprias páginas do LinkedIn. Esse código inclui um scanner de extensões com 6 167 alvos, um «espectroscópio» do Modelo de Objetos do Documento (DOM) e uma impressão digital do dispositivo composta por 48 sinais, que pode acompanhar os pedidos da sessão.

Este guia mostra que sinais podem aumentar o risco para a conta, que arquiteturas de automatização expõem mais desses sinais e como pode auditar qualquer extensão por conta própria em cerca de cinco minutos.

Resumo: 9 aspetos a conhecer antes de instalar seja o que for

1. O LinkedIn pode analisar navegadores baseados em Chromium à procura de extensões conhecidas. Este processo chama-se Active Extension Detection (AED). Em meados de junho de 2026, o código do LinkedIn sondava 4 934 IDs de extensões do Chrome, com a lista a crescer cerca de 12 por dia.
2. As ferramentas de ponte de cookies criam uma das configurações de maior risco. Estas extensões leem o cookie de sessão li_at do LinkedIn e carregam-no para a cloud do fornecedor, que pode depois operar a sua conta a partir do IP de um centro de dados. Encontrámos este padrão no código de 9 ferramentas amplamente utilizadas.
3. Ler cookies não é o mesmo que exportar a sua sessão. Algumas ferramentas leem cookies, mas mantêm a sessão local. A verdadeira questão é para onde vai o valor do cookie, pelo que seguimos esse percurso em todas as ferramentas deste guia.
4. Bloquear a telemetria do LinkedIn pode expor a ferramenta em vez de a ocultar. Algumas extensões bloqueiam endpoints de monitorização do LinkedIn. Se um endpoint continuar a comunicar, o LinkedIn poderá perceber que os restantes canais de telemetria estão a ser bloqueados.
5. A impressão digital do seu dispositivo pode acompanhar os pedidos da sessão. O LinkedIn recolhe 48 sinais do dispositivo, incluindo gráficos, áudio, tipos de letra, IP local através de Comunicação em Tempo Real na Web (WebRTC) e indicadores de automatização. Essa impressão digital é encriptada e anexada aos pedidos da API durante a sessão.
6. A deteção compreende-se melhor como um modelo de pontuação. A presença de extensões, os vestígios no código, as anomalias de rede e o comportamento da conta podem acrescentar sinais de risco. Limites diários conservadores ajudam, mas não corrigem uma arquitetura arriscada.
7. A prospeção manual não está imune a restrições. Um volume elevado, a abertura de perfis em massa e demasiadas denúncias de «Não conheço esta pessoa» também podem afetar utilizadores que trabalham manualmente.
8. As ferramentas de cloud podem deixar um rasto de IP visível. No nosso teste de sete ferramentas cloud, cinco das seis ferramentas executadas no servidor colocaram contas atrás de IPs de centros de dados ou proxies classificados como de alto risco por uma base de dados independente de fraude. Um fornecedor atribuiu o mesmo IP às duas contas de teste e três ferramentas não relacionadas encaminharam o tráfego através do mesmo fornecedor a montante.
9. A segurança da conta não é uma preocupação de nicho. Em nove mercados de língua inglesa, cerca de 12 050 pesquisas mensais estão relacionadas com restrições do LinkedIn, limitações de contas, verificação de identidade ou bloqueios.

Porque pode confiar neste relatório

Este guia baseia-se em três fontes de evidência: histórico do produto, código das extensões e testes reais na cloud.

A primeira fonte é Alexander Erin, fundador da Linked Helper, que desempenha essa função desde outubro de 2016.

Foi ele quem escreveu a primeira versão da Linked Helper, que era uma extensão do Chrome. No seu auge, ocupava o primeiro lugar nos resultados da pesquisa por «LinkedIn» na Chrome Web Store e tinha cerca de 80 000 utilizadores. Também viu os primeiros sistemas de deteção do LinkedIn afetarem extensões concorrentes. Em agosto de 2019, teve três dias para adaptar a Linked Helper a uma segunda vaga de deteção.

Depois disso, a equipa decidiu sair da Chrome Web Store e reconstruir a Linked Helper como uma aplicação autónoma para computador.

A segunda fonte é o código.

Para este relatório, descarregámos as extensões publicadas de 16 ferramentas concorrentes, desminificámo-las e acompanhámos o que fazem com a sua sessão do LinkedIn. Verificámos o código ficheiro a ficheiro e registámos as referências das linhas em que era possível confirmar o comportamento.

Também utilizámos a investigação BrowserGate, que analisou o JavaScript de produção do LinkedIn entre dezembro de 2025 e março de 2026. Esse trabalho documentou sistemas de deteção que o nosso especialista já descrevia, do ponto de vista de quem se defende, desde 2019.

A terceira fonte é um teste real.

O código pode mostrar o que uma extensão consegue fazer, mas não revela que endereço IP um serviço cloud atribui depois de a sua sessão chegar aos respetivos servidores. Para verificar essa parte, criámos contas em sete ferramentas de cloud, utilizando duas contas por ferramenta, todas do mesmo país: França.

Para cada conta, registámos o IP de saída, a reputação do IP no IPQualityScore (IPQS), o tipo de dispositivo, o sistema operativo (OS) apresentado pela cloud e se a extensão complementar constava da lista de deteção do LinkedIn. O IPQS é uma base de dados independente de informações sobre fraude e, no seu site, inclui o LinkedIn entre os seus clientes.

No final deste guia, terá três resultados práticos:

1. Um mapa de risco das principais arquiteturas de automatização
2. Uma lista de verificação ao nível do código para auditar qualquer extensão
3. benchmarks operacionais mais seguros para os casos em que os benchmarks continuam a ser aplicáveis

Porque a segurança da conta é a questão principal

As restrições de contas do LinkedIn continuam a ser uma grande preocupação para equipas comerciais, recrutadores, fundadores, agências e equipas de crescimento. Todos os meses, as pessoas procuram respostas sobre restrições, verificações de identidade, limites de pedidos de ligação e medidas súbitas aplicadas às contas.

A maioria dos conselhos limita-se aos limites de atividade diária e ao volume de mensagens. Estes fatores são importantes, mas representam apenas uma parte do quadro de risco. O LinkedIn também pode observar sinais técnicos, incluindo extensões do navegador, impressões digitais de dispositivos, ambientes de sessão na cloud e reputação de IPs.

Este relatório centra-se nessa camada técnica. Em vez de presumirmos o que o LinkedIn poderá detetar, analisamos como as ferramentas de automatização são construídas, que sinais expõem e como cada arquitetura pode afetar o risco para a conta.

1. As arquiteturas por detrás do risco da automatização de atividades no LinkedIn

Designações comerciais como «cloud», «AI», «extensão do Chrome» e «seguro» não explicam, por si só, o risco para a conta.

As verdadeiras perguntas são:

1. Como é que a ferramenta acede à sua conta?
2. Onde é executado o trabalho?
3. Para onde vão os seus dados?
4. Que vestígios deixa a configuração?

A maioria das ferramentas de automatização de atividades no LinkedIn pode ser associada aos componentes abaixo. Algumas ferramentas utilizam um modelo, enquanto outras combinam vários modelos no mesmo produto.

Fluxo de dados da extensão Dux-Soup para Chrome. Os nós vermelhos mostram a sua sessão ou os seus dados do LinkedIn a sair para a cloud de um fornecedor. Os nós cinzentos mostram os dados que permanecem no seu navegador.

1.1 Extensões do navegador executadas dentro do seu navegador

Uma extensão do navegador pode combinar vários padrões de automatização. A diferença entre esses padrões é importante, pois alguns mantêm a sessão local, enquanto outros transferem os dados da sessão para a cloud de um fornecedor.

a) Extração local através da sua própria sessão

Neste modelo, a sua sessão do LinkedIn permanece no seu computador. A extensão chama a API interna do LinkedIn, conhecida como Voyager, diretamente a partir do seu navegador e utiliza a sessão atualmente autenticada no navegador.

Tecnicamente, isto pode assemelhar-se a fetch(..., {credentials: "same-origin"}) com um cabeçalho CSRF token derivado do cookie JSESSIONID. Os tokens de Falsificação de Pedidos entre Sites (CSRF) ajudam a provar que um pedido pertence à sessão atualmente autenticada no navegador.

Apenas os resultados extraídos, como perfis ou emails, são carregados para o fornecedor. O token da sessão em si não é exportado.

Entre os exemplos confirmados pela nossa auditoria estão Octopus CRM, GetProspect, Findymail, Apollo e Dux-Soup nos planos Turbo, Pro e Free. O Octopus CRM tinha a implementação mais limpa deste grupo, pois não solicitava a permissão cookies do Chrome e utilizava chamadas locais ao Voyager, como fetch(voyager, {credentials:"same-origin", "CSRF-token": U()}).

A vantagem é que o seu IP, a sessão do navegador e a impressão digital do dispositivo permanecem coerentes. O token da sessão não sai do navegador.

• Um pedido simples ao Voyager sem o tráfego envolvente da página pode criar um padrão de pedidos anormal, que abordamos em §2.7.
• A extensão também pode continuar visível para os scanners de extensões do LinkedIn, que abordamos em §2.1 e §2.2.

Existe ainda um risco de manutenção.

Muitas extensões dependem de pressupostos codificados de forma rígida sobre a estrutura da API interna do LinkedIn, os formatos dos pedidos, os cabeçalhos e os parâmetros. Se o LinkedIn alterar esses requisitos, uma extensão desatualizada poderá começar a enviar pedidos malformados ou invulgares até o fornecedor detetar a alteração, disponibilizar uma correção e os utilizadores instalarem a atualização.

b) Extensões de ponte de cookies ou carregamento de sessões

Neste modelo, a sua sessão do LinkedIn sai do seu computador. A extensão lê o conjunto de cookies do LinkedIn através de chamadas como chrome.cookies.getAll(...), seleciona valores como li_at, JSESSIONID ou li_a e envia-os para o servidor do fornecedor.

Depois disso, a cloud do fornecedor pode agir em seu nome a partir do respetivo endereço IP. Como afirmou o nosso especialista sobre uma destas ferramentas: «a extensão funciona como uma ponte para extrair o cookie e não tem qualquer outra finalidade».

A tabela abaixo mostra o que encontrámos no código. Também distingue as ferramentas que exportam dados da sessão das que mantêm a sessão do LinkedIn local e enviam apenas resultados.

Expandi: o caso mais interessante do conjunto de dados

A Expandi (através da extensão de conector da Expandi) merece uma análise mais atenta porque demonstra várias técnicas utilizadas no mercado da automatização de atividades no LinkedIn. Essas técnicas podem reduzir alguns riscos, mas também podem deixar sinais observáveis pelos sistemas de deteção.

Compreender como funcionam essas técnicas e onde continuam a deixar sinais fornece uma estrutura útil para avaliar todas as outras ferramentas de automatização.

Fluxo de dados da extensão Expandi Connector para Chrome, reconstruído através da auditoria do código. Os nós vermelhos mostram a sua sessão ou os seus dados do LinkedIn a sair para a cloud de um fornecedor. Os nós cinzentos mostram os dados que permanecem no navegador.

Técnica 1: injetar um script no contexto da página do LinkedIn

Normalmente, um script de conteúdo existe num ambiente isolado e não consegue aceder ao XMLHttpRequest da página.

Para contornar essa limitação, a Expandi injeta um verdadeiro nó <script src="chrome-extension://ohcplcf…/linkedin/injected.js"> no DOM ativo (linkedin/content.js:2-7).

Esse nó contém um URL literal chrome-extension:// dentro da página. O scanner Spectroscopy do LinkedIn (§2.2) pode percorrer passivamente o DOM, procurar essa subcadeia, extrair o ID de 32 caracteres da extensão e comunicá-lo.

Este método de deteção não precisa de uma lista de alvos. Uma afirmação como «não estamos na lista AED» não resolve a questão se a extensão injetar um recurso chrome-extension:// visível. Nesse caso, a própria forma de injeção torna-se um vestígio detetável.

Confiança: encontrado no código. A injeção é explícita e o mecanismo Spectroscopy está documentado na análise do código de produção do BrowserGate.

Técnica 2: substituir XMLHttpRequest.prototype.send

O ficheiro injected.js:3-27 da Expandi substitui o método nativo send da página, permitindo copiar para a extensão todas as respostas da API Voyager obtidas pelo navegador. A substituição é executada no mesmo contexto global do JavaScript do próprio LinkedIn, que é precisamente a razão para injetar o script na página.

Um método send alterado deixa de ser nativo e qualquer script da página pode testá-lo. Por exemplo, Function.prototype.toString.call(XMLHttpRequest.prototype.send) devolve o código-fonte da função envolvente em vez de "function send() { [native code] }", e a Expandi não tenta disfarçar o toString.

Uma referência limpa proveniente de um novo <iframe> com a mesma origem também não corresponderia ao método send modificado da página. Isto cria uma diferença detetável entre a API original do navegador e o estado atual da página.

O LinkedIn já disponibiliza sondas desta categoria. O grupo interno de motores de impressão digital APFC/DNA abordado em §2.6 inclui verificações diretas contra bots e uma funcionalidade signals para detetar afirmações incoerentes do navegador. O LinkedIn também carrega o script externo HUMAN/PerimeterX a partir de li.protechts.net (§2.8a), concebido para detetar adulterações como protótipos modificados e alterações ao comportamento de toString.

Confiança: a substituição foi encontrada no código. O método de deteção decorre do funcionamento dessa substituição.

Não encontrámos bloqueio de telemetria neste percurso, pelo que qualquer resultado dessas sondas pode continuar a ser comunicado. Não afirmamos ter observado o LinkedIn a sinalizar um utilizador específico da Expandi. A afirmação mais restrita é que a capacidade de deteção existe e a substituição é suficientemente visível para poder ser detetada por esses mecanismos.

Técnica 3: enviar uma chamada separada ao Voyager GraphQL para obter o email

O ficheiro injected.js:34-44 da Expandi emite um pedido programático GET /voyager/api/graphql com withCredentials:true. Cria um CSRF-token a partir do seu JSESSIONID (injected.js:30-31) para obter dados de contacto ou email que uma visualização normal do perfil não carrega por predefinição.

O LinkedIn pode interpretar isto como uma anomalia no mapa de pedidos (§2.7). Trata-se de uma chamada à API sem uma ação correspondente do utilizador, efetuada após o carregamento em perfis nos quais o utilizador não abriu «Contact info».

Em grande escala, o padrão «cada perfil visualizado também obtém o respetivo email» torna-se característico de uma ferramenta de enriquecimento e extração. É visível nos registos do lado do servidor sem qualquer ajuda do navegador. A chamada utiliza a sua sessão real e inclui o cabeçalho encriptado da impressão digital, mas é o padrão de comportamento que a denuncia.

Confiança: encontrado no código. A chamada é explícita e a anomalia é, por definição, observável pelo servidor.

A conclusão mais grave: algumas extensões recolhem mais do que dados do LinkedIn

A variante mais grave consiste na recolha de todo o conjunto de cookies em todos os sites onde tem sessão iniciada, não apenas no LinkedIn. A extensão expandi.ai da Konnector, um fornecedor diferente da Expandi.io, devolve chrome.cookies.getAll({}) à respetiva aplicação Web em todos os domínios.

Até a troca de mensagens isInstalled, aparentemente banal, pode expor todo o conjunto de cookies (KonnectorContent.js:10-28, background.js:19). Isto leva o problema para além do risco da automatização de atividades no LinkedIn e coloca-o no âmbito mais amplo da segurança das contas.

Exemplo do PhantomBuster

O PhantomBuster insere-se numa categoria distinta. Preenche automaticamente o cookie li_at na respetiva página de configuração na cloud com um clique (contentscript.js:5265-5266). Não se trata de um POST silencioso, mas permite transferir a sessão com um único clique.

O PhantomBuster também consegue recolher cookies de sessão de 15 plataformas (background.js:5140-5230). É por isso que §1.2a considera a reutilização de cookies de sessão a pior categoria.

c) Automatização do DOM dentro da página do LinkedIn

Algumas extensões automatizam atividades no LinkedIn ao clicar em botões por si e ao injetar painéis, botões ou controlos próprios na página do LinkedIn.

Isto cria duas superfícies de deteção. Cada elemento injetado pode ter um seletor exclusivo que um scanner consegue procurar (§2.2), e cada clique programático tem isTrusted:false. Através da API normal de extensões, como afirmou o nosso especialista, «não é possível falsificá-lo — é sempre falso» (§2.5).

Na prática, poucas ferramentas injetam muitos elementos na página. No entanto, as que o fazem criam sinais que o LinkedIn pode inspecionar sem precisar de uma lista de alvos, pois o scanner pode observar diretamente o que mudou dentro da página (§2.2).

1.2 Serviços de cloud executados nos servidores dos fornecedores

Um serviço de cloud precisa de uma forma de entrar na sua conta do LinkedIn antes de poder automatizar qualquer atividade. Na prática, existem dois pontos de entrada principais.

a) Reutilização de cookies de sessão através de uma sessão sincronizada

Esta é a parte do modelo de ponte de cookies de §1.1b executada no servidor. É uma das configurações de maior risco, pois a sua sessão pode ser reutilizada fora do seu navegador.

O risco decorre da ocorrência simultânea de vários sinais:

• Uma sessão pode aparecer em dois IPs em paralelo. O seu, enquanto continua a navegar no LinkedIn, e o IP do centro de dados do fornecedor, enquanto a cloud executa a automatização. O nosso especialista chamou-lhe «um indício inequívoco».
• A reutilização de cookies de sessão não equivale a um início de sessão normal. Não cria uma entrada visível na página «Active sessions» do LinkedIn, pelo que não consegue vê-la nas definições da conta.
• O plano Cloud do Dux-Soup recolhe os cookies silenciosamente quando é ligado.
• Se a cloud reutilizar o cookie no seu próprio navegador, a impressão digital do dispositivo poderá não corresponder àquela que a sua sessão sempre utilizou (§2.6).
• Se a cloud não utilizar um navegador e fizer chamadas diretas à API, poderá criar um mapa de pedidos anormal (§2.7).

Depois de a sessão ser transferida para a cloud de um fornecedor, deixa de conseguir observar o ambiente que atua através da sua conta do LinkedIn.

b) Novo início de sessão do lado do fornecedor

O segundo percurso consiste num novo início de sessão a partir do ambiente do fornecedor. O serviço inicia um Servidor Privado Virtual (VPS) ou um emulador de navegador e inicia sessão com o seu nome de utilizador, palavra-passe, código de email e código de autenticação de dois fatores (2FA).

Alguns fornecedores descrevem esta abordagem em privado. Uma ferramenta de publicação em redes sociais disse-nos que inicia sessão através de um VPS com um navegador semelhante ao Multilogin e que depois faz tudo o resto através da API. Outro conjunto conhecido de ferramentas de prospeção descreveu «um navegador real para as ações raras e a API para o resto».

(Não vamos identificá-los, mas… em abono da verdade, o PhantomBuster documenta publicamente a sua arquitetura de navegador na cloud.)

O nosso especialista considera este percurso menos arriscado do que a reutilização de cookies de sessão. Um novo início de sessão a partir de um novo computador e local pode, pelo menos, assemelhar-se a algo que uma pessoa real faria. Ainda assim, associa à sua conta o IP, a localização geográfica, o fuso horário e a impressão digital da cloud, que abordamos em §2.9 e §2.10.

O que a cloud faz a seguir: apenas API ou navegador emulado

Após iniciar sessão, a cloud ainda tem de executar o trabalho. Pode utilizar um navegador emulado, chamar diretamente as APIs do LinkedIn ou combinar ambos.

O nosso especialista classifica a execução na cloud como uma estimativa, não como um facto diretamente comprovado. A sua avaliação é clara: «Penso que todos sobrecarregam diretamente a API com pedidos. Todos. Com 95 % de probabilidade».

Apresenta três razões para esta estimativa:

1. As chamadas à API são muito mais simples do que analisar páginas do LinkedIn que mudam constantemente.
2. O LinkedIn ainda não reforçou suficientemente a API para travar serviços que admitiram publicamente utilizá-la.
3. As funcionalidades de caixa de entrada em tempo real nos painéis destas ferramentas exigem normalmente acesso direto à API. Obter em tempo real uma conversa específica, sempre que o utilizador a pede, não é algo que um navegador dedicado à extração em segundo plano consiga fazer de forma fiável e com essa cadência.

O risco ao nível do sistema é que as clouds que utilizam apenas a API dependem de pedidos codificados de forma rígida. Basta o LinkedIn alterar a API com um cabeçalho especial, nomes de endpoints por utilizador ou uma modificação semelhante para todos os clientes que dependam de pedidos codificados de forma rígida deixarem de funcionar ou começarem a parecer invulgares.

A análise do BrowserGate concluiu que parte desta infraestrutura já existe. Um bloco encriptado com a impressão digital é injetado nos cabeçalhos do Protocolo de Transferência de Hipertexto (HTTP) de cada pedido à API efetuado por uma sessão real do navegador (§2.6 e §2.7). A infraestrutura para distinguir o tráfego de navegadores reais de clientes de API simples parece estar implementada. Passar da recolha destes sinais à imposição de restrições é uma decisão do LinkedIn.

Esta ressalva é importante em todo o relatório: do exterior, não é possível provar que método utiliza uma cloud — um cliente de API também pode imitar um início de sessão. Comunicamos o que vemos no código e classificamos o comportamento no servidor como «altamente provável».

O que medimos ao criar as contas (7 ferramentas, 2 contas em cada uma)

A análise do código termina na fronteira da extensão. A própria cloud é uma caixa negra para o utilizador, embora o LinkedIn possa ver mais.

Há dois elementos que essa caixa negra não consegue ocultar por completo: o IP de saída associado à sua conta e a impressão digital do dispositivo que apresenta. Para os testar, criámos contas em sete ferramentas de cloud, com duas contas por ferramenta, todas do mesmo país: França.

Em seguida, verificámos cada IP atribuído no IPQualityScore (IPQS). Testar duas contas por ferramenta é importante porque mostra se um fornecedor reutiliza a infraestrutura entre clientes.

O que é o IPQualityScore (IPQS)?

O IPQS é um serviço independente de prevenção de fraude com mais de 10 anos no mercado. Classifica endereços IP através de sinais da sua própria rede de honeypots, armadilhas, crawlers e fontes de informação sobre abusos.

Para cada IP, o IPQS devolve vários campos úteis:

• fraud_score, de 0 a 100.
• Indicadores de proxy, Rede Privada Virtual (VPN) e Tor.
• Tipo de ligação, como centro de dados, residencial ou móvel.
• Dados de geolocalização.
• Histórico recente de abusos.

Não existe um limite oficial que transforme um IP num veredito de segurança. Ainda assim, os próprios exemplos do IPQS consideram as pontuações superiores a 75 como de alto risco, e a empresa afirma ter cerca de 99,95 % de precisão na deteção de proxies e VPN.

Utilizamos o IPQS como ponto de referência independente para aquilo que um sistema moderno de combate à fraude poderá ver. Um IP alvo de muitos abusos, um endpoint de proxy conhecido ou um endereço de centro de dados partilhado por muitas contas não relacionadas podem tornar-se sinais normalmente avaliados pelos sistemas de risco.

Os IPs de centros de dados não são automaticamente maliciosos. São frequentemente menos fiáveis do que as ligações residenciais ou móveis, pois provêm de fornecedores de alojamento e não de redes de consumidores. No contexto do LinkedIn, podem tornar-se mais reveladores quando muitas contas aparecem na mesma infraestrutura de cloud.

O IPQS também foi útil porque os seus dados de geolocalização correspondiam frequentemente ao que o LinkedIn apresentava nas sessões de segurança das contas durante os nossos testes. Alguns fornecedores de proxies anunciavam localizações que não correspondiam ao país identificado pelo IPQS ou pelo LinkedIn, criando outro fator de risco: uma discrepância geográfica entre a localização declarada e a localização observada da ligação.

O IPQS não é o motor privado de risco do LinkedIn. A sua pontuação não constitui um veredito sobre a segurança da conta nem uma determinação jurídica. É um benchmark independente para comparar a qualidade e a reputação dos IPs que as ferramentas de automatização atribuíram às contas dos utilizadores.

Resultados do teste de criação de contas em serviços cloud

O que a tabela mostra

1. O Skylead é o exemplo de alerta mais evidente.

Foi atribuído exatamente o mesmo IP de centro de dados, 58.97.254.1, a ambas as contas de teste, com uma pontuação de fraude de 100 no IPQS. Dois perfis num único IP de centro de dados correspondem ao tipo de padrão de agrupamento de contas que a lógica de acesso paralelo do LinkedIn pode avaliar (§2.9).

2. A infraestrutura sinalizada era partilhada, e não apenas dentro de uma marca.

Dripify, Skylead e We Connect são todos encaminhados através do mesmo fornecedor a montante, HostRoyale Technologies (ASN 203020). Se um bloco desse fornecedor passar a ser menos fiável para o LinkedIn, várias ferramentas poderão ser afetadas em simultâneo.

3. O HeyReach acrescentou um problema de controlo distinto.

Os seus IPs tinham pontuações de fraude de 100 e a respetiva extensão bloqueava o fim de sessão de duas formas: através de uma interceção webNavigation (background.js:1-17) e de uma regra declarativeNetRequest (rules.json:1-14). Isto pode impedir o utilizador de invalidar a sessão depois de entregar todo o conjunto de cookies através de api.heyreach.io/.../CreateLinkedInAccountFromCookies.

4. O Meet Alfred foi o contraste positivo deste teste.

Foi a única ferramenta a atribuir IPs limpos, com pontuações de fraude de 0, a ambas as contas e simulou um Agente do Utilizador móvel. No entanto, um IP limpo resolve apenas um sinal. A ferramenta continua a colocar as credenciais na respetiva cloud e atua como o utilizador a partir de um computador diferente.

5. Nenhuma ferramenta verifica o IP que atribui ao utilizador.

Nenhuma das sete ferramentas incluía um verificador da qualidade do proxy. Uma ferramenta pode atribuir um endereço sinalizado, ou um utilizador pode adicionar um proxy fraco, sem receber um aviso claro. «Controlo de localização» também costuma significar controlo ao nível do país, e não do estado ou da cidade (§2.9).

Não conseguimos ver o que estes servidores fazem internamente e classificamos o modo de execução como «altamente provável». Contudo, o IP, a infraestrutura partilhada, a impressão digital e a presença na lista de deteção não são inferências: medimo-los (consulte a caixa sobre o IPQS acima).

1.3 Ferramentas baseadas no navegador que controlam um navegador completo

A automatização baseada no navegador utiliza um ambiente de navegador completo, em vez de apenas uma extensão leve ou um cliente de API simples. Esta categoria divide-se em dois modelos muito diferentes.

Ferramentas baseadas num navegador na cloud

Uma ferramenta baseada num navegador na cloud executa um navegador como o Chrome sem interface gráfica ou o Puppeteer no servidor do fornecedor. O PhantomBuster é o único fornecedor deste grupo que documenta publicamente esta arquitetura.

Este modelo continua a ter fragilidades.

O Puppeteer é detetável e existe toda uma indústria de combate aos bots dedicada a detetar a automatização de navegadores.

O alojamento de várias contas também cria risco de correlação quando muitos «utilizadores» partilham a unidade de processamento gráfico (GPU), a pilha de áudio e outras características da impressão digital de um único servidor.

Ferramentas autónomas para computador

Uma ferramenta autónoma para computador executa um navegador separado baseado em Chromium no computador do utilizador. A Linked Helper utiliza este modelo.

Isto cria uma superfície de deteção menor do que uma extensão do Chrome ou uma infraestrutura cloud que aloja várias contas. Não existe um ID da Chrome Web Store para o scanner Active Extension Detection do LinkedIn sondar (§2.1), não existe código de extensão injetado na página do LinkedIn (§2.2 e §2.3) e a conta conserva o IP local e a impressão digital do computador do utilizador.

Existe ainda uma vantagem estrutural. O LinkedIn pode analisar demoradamente qualquer extensão pública da Chrome Web Store e criar um detetor antes de implementar seja o que for. Perante uma aplicação autónoma para computador, os mecanismos de deteção têm de ser implementados em produção, onde podem ser observados.

O facto de uma ferramenta se basear no navegador não significa automaticamente que seja segura. Apenas reduz parte da exposição técnica. As escolhas do programador quanto à impressão digital, navegação, temporização e simulação de cliques continuam a afetar o risco.

Exemplo prático: o Dux-Soup utiliza vários padrões num único pacote

A maioria das ferramentas enquadra-se numa linha do mapa de arquiteturas. O Dux-Soup é diferente: o produto adota uma arquitetura distinta consoante o plano, conforme o valor devolvido por config.getEdition().

Isto torna o Dux-Soup um exemplo útil para este guia. Um único produto demonstra extração local, carregamento de sessões, exposição ao AED, bloqueio de telemetria e limites de grande volume em diferentes partes da configuração.

Fluxo de dados da extensão Dux-Soup para Chrome. Os nós vermelhos mostram a sua sessão ou os seus dados do LinkedIn a sair para a cloud de um fornecedor. Os nós cinzentos mostram os dados que permanecem no navegador.

• Os planos Free, Pro e Turbo utilizam extração local (§1.1a). O Voyager é chamado no navegador do utilizador com um CSRF-token derivado de JSESSIONID, pelo que a sessão permanece local. Nível de risco: médio.
• O plano Cloud utiliza carregamento da sessão (§1.1b e §1.2a). O service worker executa chrome.cookies.getAll({domain:"linkedin"}) e depois envia todo o conjunto de cookies, o localStorage e os dados de navigator para app.dux-soup.com através de PUT /api/{user}/sessions/{domain}. Em seguida, controla a conta através de um canal Socket.io (sw.js:1, libs/socket-io/socket.io.js:1562). Foi o pacote de sessão mais abrangente que encontrámos em qualquer ferramenta.
• Está confirmado que a extensão consta da lista AED do LinkedIn (§2.1). O ID de extensão ppdakpfeaodfophjplfdedpcodkdkbal e o ficheiro de sondagem fetchforwarder.js aparecem em detection_db.json. Em cada visita, o LinkedIn pode obter chrome-extension://…/fetchforwarder.js, e uma resposta bem-sucedida pode sinalizar que a extensão está instalada antes de o utilizador clicar em seja o que for.
• A configuração contra deteção cria o seu próprio sinal (§2.8). As regras declarativeNetRequest bloqueiam li/track, sensorcollect, protechts e merchantpool (rules.json; opção da interface killtracking). Essas regras estão num ficheiro JSON estático que qualquer pessoa pode ler, e o silêncio resultante da telemetria pode tornar-se uma anomalia.
• Os limites combinam definições conservadoras e agressivas (§6). Por predefinição, maxinvites tem um valor razoável de 20/dia. A mesma interface aumenta maxvisits para 500/dia e oferece uma análise «Turbo» de cerca de 10 páginas/minuto, muito para além do comportamento normal de navegação humana.

2. A superfície de deteção: o que o LinkedIn pode ver, recolher e comparar

Este é o núcleo técnico do guia. Durante anos, grande parte da lógica de deteção do LinkedIn só podia ser descrita com base na experiência de quem se defendia. A investigação BrowserGate mudou esta situação ao desmontar o JavaScript de produção do LinkedIn, incluindo um módulo com cerca de 2,7 MB.

Essa análise encontrou três sistemas a trabalhar em conjunto dentro das páginas do LinkedIn:

1. O sistema Active Extension Detection (AED) sonda ativamente o navegador à procura de extensões instaladas (§2.1).
2. O sistema Spectroscopy analisa passivamente o DOM à procura de vestígios deixados pelas extensões (§2.2).
3. O sistema APFC/DNA recolhe uma impressão digital do dispositivo com 48 características (§2.6).

Esses sinais alimentam o fluxo de telemetria do LinkedIn, incluindo o endpoint li/track (§2.4). A análise de extensões é executada em navegadores baseados em Chromium, incluindo Chrome, Edge, Brave, Opera e Arc. O BrowserGate encontrou no código uma verificação literal userAgent.indexOf("Chrome").

A lista de alvos também continua a crescer. Passou de 38 extensões em 2017 para cerca de 461 em 2024 e depois para 4 934 em junho de 2026. Isto representa um crescimento de cerca de 12 novas entradas por dia, demonstrando que a lista é mantida e não foi abandonada.

4 934 refere-se a IDs exclusivos de extensões do Chrome, enquanto 6 167 corresponde à lista mais ampla de alvos compostos por ID e ficheiro.

Segue-se cada vetor de deteção: mecanismo → o que chega aos servidores do LinkedIn → quem é detetado → como pode verificá-lo por conta própria.

2.1 O scanner de extensões (AED): estar instalado pode significar estar visível

O código da página do LinkedIn inclui uma matriz codificada de forma rígida com pares {extension id, file}. Estes podem incluir ficheiros como logótipos, popup.html, manifest.json ou qualquer recurso exposto pela extensão através de web_accessible_resources.

A página executa silenciosamente chamadas fetch() para caminhos como chrome-extension://<id>/<file>. Se o pedido for bem-sucedido, o LinkedIn consegue perceber que a extensão está instalada.

Os pormenores de produção são importantes, pois a análise foi concebida para permanecer discreta:

• Pode executar um lote de cerca de 6 200 pedidos em paralelo através de Promise.allSettled.
• Também pode analisar um a um com um atraso configurável staggerDetectionMs, o que torna o processo menos evidente no separador «Network».
• Pode aguardar por um período de inatividade do navegador através de requestIdleCallback, para que não sinta qualquer lentidão.
• Os erros são absorvidos por blocos catch vazios, mantendo a consola limpa.
• Os resultados são enviados como AedEvent {browserExtensionIds: [...]}.

Se a extensão constar da lista do LinkedIn, o facto de estar instalada pode ser registado em cada visita antes de o utilizador clicar em seja o que for.

Pode verificar isto em cerca de três minutos.

Abra linkedin.com, abra o «DevTools» e, depois, o separador «Sources», e procure o ID da extensão em todos os ficheiros carregados. Pode encontrar o ID em chrome://extensions.

Depois, abra o separador «Network», filtre por li/track e volte a carregar o LinkedIn. Poderá observar os POSTs de telemetria agrupados a sair da página. Para uma verificação mais aprofundada, procure AedEvent ou chrome-extension:// nos pacotes de JavaScript do LinkedIn.

2.2 O espectroscópio do DOM: o scanner que não precisa de uma lista

Um segundo sistema analisa a própria página ativa. Percorre recursivamente todo o DOM, incluindo nós de texto e valores de atributos, à procura da subcadeia chrome-extension://.

Quando encontra essa cadeia, extrai o ID de 32 caracteres da extensão e comunica um SpectroscopyEvent.

Isto difere do AED porque não precisa de uma lista de alvos. Uma nova extensão pode continuar a ser detetada se injetar um elemento, estilo, iframe ou script que aponte para os seus próprios recursos chrome-extension://.

Em conjunto, o AED e o sistema Spectroscopy abrangem dois estados comuns das extensões.

• O AED pode detetar uma extensão instalada, mas silenciosa.
• O sistema Spectroscopy pode detetar uma extensão que modifica ativamente a página do LinkedIn.

Este é o scanner aplicável ao modelo de automatização do DOM descrito em §1.1c.

2.3 Instantâneos da página provenientes de um Web Worker

Em momentos aleatórios, um worker em segundo plano pode recolher um instantâneo estrutural da página. O instantâneo inclui etiquetas sem o respetivo conteúdo textual, além de elementos script/style com conteúdo.

O instantâneo é encriptado e enviado para os servidores, onde é analisado à procura de vestígios. Não consegue ver o que o LinkedIn procura porque essa pesquisa não ocorre no seu navegador.

Conhecemos este mecanismo por experiência direta. Foi o algoritmo que detetou a primeira versão da extensão da Linked Helper para Chrome em agosto de 2019. A correção de curto prazo consistiu em tornar estruturalmente única a cópia da extensão de cada utilizador, o que permitiu ganhar tempo. Essa experiência é uma das razões pelas quais a Linked Helper saiu da Chrome Web Store e foi reconstruída como uma aplicação autónoma para computador.

Apresentamo-lo como um facto histórico. O LinkedIn já dispunha desta categoria de deteção da estrutura da página sete anos antes das atuais conclusões do BrowserGate.

2.4 O fluxo de telemetria: li/track

Os sistemas acima convergem em https://www.linkedin.com/li/track. O nome do método no código é fireTrackingPayload.

Este endpoint recebe eventos comportamentais, como movimentos do rato, cliques e introdução de texto, juntamente com resultados dos scanners, como AedEvent e SpectroscopyEvent.

O transporte foi concebido para ser fiável:

• Os eventos são agrupados até 29 por pedido.
• Os pedidos falhados são repetidos até 4 vezes.
• Os dados enviados são comprimidos com a compressão Lempel-Ziv (LZ) através de compressToBase64.

Endpoints relacionados processam dados de impressão digital, incluindo /platform-telemetry/li/apfcDf e /apfc/collect.

Importa reter estes nomes porque voltam a surgir em §2.8. As extensões que tentam bloquear a telemetria do LinkedIn têm de bloquear o conjunto completo. A omissão de um endpoint pode expor o próprio bloqueio.

2.5 isTrusted: o indicador de clique que um script de conteúdo normalmente não consegue alterar

Todos os eventos do DOM contêm um indicador só de leitura isTrusted. Um clique humano real devolve true.

Um evento criado pelo script de conteúdo de uma extensão devolve false. Isto inclui chamadas dispatchEvent, new MouseEvent e .click() programáticas. Através da API normal de extensões, o nosso especialista é claro: «não é possível falsificá-lo. É sempre falso».

Uma ressalva precisa, para que a afirmação resista a uma análise rigorosa: os eventos gerados através da API chrome.debugger podem devolver isTrusted:true. Contudo, o Chrome apresenta então uma barra amarela permanente com a mensagem «This browser is being debugged by an extension». A lacuna existe, mas não passa despercebida.

De acordo com o conhecimento direto mais recente do nosso especialista, o LinkedIn ainda não aplicava medidas em massa com base neste indicador. O seu comentário foi «é uma questão de tempo». Para o LinkedIn, basta uma instrução if.

2.6 A impressão digital composta por 48 sinais (APFC): o passaporte técnico do seu computador

O que é uma impressão digital do navegador?

Uma impressão digital do navegador é um instantâneo técnico do seu computador. Pode incluir a GPU que renderiza uma imagem de teste, a forma como a pilha de áudio processa um sinal, os tipos de letra instalados, o ecrã, os núcleos do CPU, a memória de acesso aleatório (RAM), o fuso horário e outras características.

Cada sinal pode parecer inofensivo quando considerado isoladamente. Em conjunto, podem tornar-se quase exclusivos. Também são difíceis de falsificar de forma convincente, pois isso exige reproduzir as particularidades de outro computador, e não apenas alterar uma cadeia do navegador.

O motor de impressão digital de produção do LinkedIn, denominado internamente APFC/DNA, recolhe 48 características. Os principais grupos são:

• Hardware e sistema operativo (OS): núcleos do CPU, RAM, 6 métricas do ecrã, toque, bateria e plataforma.
• Gráficos, áudio e tipos de letra: hash do canvas, fornecedor e processador WebGL, 65 parâmetros WebGL adicionais, resposta do oscilador e compressor AudioContext e tipos de letra instalados.
• Rede: IP local através de WebRTC, tipo de ligação, downlink e tempo de ida e volta (RTT).
• Ambiente: fuso horário medido de duas formas, idioma, plugins, tipos de Extensões Multiuso de Correio da Internet (MIME), câmaras, microfones, altifalantes através de enumerateDevices e particularidades do armazenamento.
• Sinais diretos contra bots: webdriver, deteção de frameworks de automatização, modo incógnito e uma funcionalidade denominada signals, capaz de sinalizar combinações simuladas de OS, navegador, resolução ou idioma.

Há um pormenor que merece destaque. A opção Do Not Track é recolhida, mas excluída do hash. Por outras palavras, o LinkedIn regista a preferência, mas esta não impede o processo mais amplo de impressão digital aqui descrito.

O instantâneo é encriptado com uma chave pública RSA através de apfcDfPK, guardado em globalThis.apfcDf e depois anexado como cabeçalho HTTP aos pedidos posteriores à API durante a sessão. O BrowserGate refere SyncCollectionHandler e o indicador de funcionalidade sync.apfc.headers relativamente a este comportamento.

Isto significa que a impressão digital não é enviada uma única vez e esquecida. Pode acompanhar as ações efetuadas pela sua sessão.

Isto cria dois grandes problemas para a automatização na cloud:

1. Um serviço de cloud que nunca recolheu a sua impressão digital real não consegue reproduzi-la. Como afirmou o nosso especialista: «para a simular, primeiro seria necessário recolhê-la».
2. Recolher alguns dados da impressão digital não é suficiente. Seria necessário recolhê-los exatamente da mesma forma que o LinkedIn («se desenharem um triângulo diferente, o hash será diferente»). E o detetor de mentiras signals existe precisamente porque a simulação rudimentar já é suficientemente comum para ser detetada.

2.7 O mapa de pedidos: uma ação cria muitos pedidos

Abra qualquer perfil do LinkedIn com o «DevTools» em execução e verá um conjunto de pedidos a ser efetuado em simultâneo. Uma visita normal à página pode incluir marcação, chamadas ao Voyager, telemetria, pré-carregamentos e outros pedidos de suporte.

Uma ferramenta que utilize apenas a API pode criar um padrão diferente. Os dados do perfil são acedidos, mas a visita à página do perfil envolvente não acontece. Como descreveu o nosso especialista: «o perfil é acedido, mas a página do perfil nunca é visitada e os pedidos que a acompanham nunca são enviados».

Isto é uma anomalia no mapa de pedidos. Pode ser visível apenas a partir dos registos do servidor.

O LinkedIn também dispõe de várias opções ativas: mudança dos nomes dos endpoints por utilizador, cabeçalhos especiais e pedidos de engodo apresentados a novas contas de teste. Como referido em §2.6, o cabeçalho especial da impressão digital já existe em produção.

Uma cloud que utilize apenas a API enfrenta duas escolhas difíceis. Pode tentar falsificar esse cabeçalho sem recolher efetivamente a impressão digital correspondente ou pode enviar pedidos sem o mesmo contexto suportado pelo navegador. Ambas as opções podem deixar um padrão.

2.8 Bloqueio da telemetria: a configuração contra deteção que pode expor-se a si própria

Algumas extensões tentam ocultar-se bloqueando os endpoints de deteção e telemetria do LinkedIn através da API webRequest. A fragilidade está no facto de a lista de bloqueio ter de estar completa.

Se a extensão omitir um endpoint, o endpoint que não foi bloqueado pode comunicar que os restantes canais de telemetria estão a ser bloqueados. O nosso especialista chamou-lhe «um sinal inequívoco que pode levar ao bloqueio da conta».

Com base no código de produção, a lista atual que um bloqueador teria de abranger inclui:

• li/track
• /platform-telemetry/li/apfcDf
• /apfc/collect
• /sensorCollect
• o iframe li.protechts.net
• o script merchantpool1.linkedin.com

Quanto mais longa for esta lista, mais fácil será para o LinkedIn adicionar um novo endpoint antes do lançamento seguinte da extensão.

O Manifest V3 acrescenta um pormenor importante. Os listeners de webRequest com capacidade de bloqueio deixaram de estar disponíveis para extensões públicas, mas o bloqueio declarativo através de declarativeNetRequest continua a funcionar.

Para os auditores, isto facilita a inspeção, pois a lista de bloqueio está agora num ficheiro JSON estático dentro do pacote da extensão.

2.8a A infraestrutura externa do LinkedIn contra bots

O LinkedIn não depende apenas do seu próprio JavaScript. Também carrega sistemas externos contra bots e de pontuação.

A análise do BrowserGate identificou três elementos importantes:

• HUMAN Security, anteriormente PerimeterX: um iframe 0×0 oculto proveniente de li.protechts.net, posicionado em left: -9999px com aria-hidden e carregado com uc=scraping no URL. Os cookies relacionados incluem _px3 e _pxvid.
• Merchant Pool: um segundo script de impressão digital proveniente de merchantpool1.linkedin.com, associado ao cookie da sessão do utilizador.
• Google reCAPTCHA v3 Enterprise: pontuação invisível no carregamento da página.

Estes sistemas são ativados através de indicadores internos de funcionalidades, como pemberly.tracking.*. Isto significa que o LinkedIn pode testar a deteção em segmentos de utilizadores e aumentar a cobertura sem alterar o fluxo do produto que os utilizadores veem.

Esta é a confirmação ao nível do código do antigo aviso do especialista: «Nada os impede de o implementar a qualquer momento».

2.9 IP, geolocalização e sessões paralelas

Um cookie ativo em dois IPs ao mesmo tempo (§1.2a) é um dos sinais mais evidentes ao nível da rede.

A geolocalização por IP é suficientemente fiável para criar sinais de risco. Tem cerca de 80 % de precisão ao nível do estado e identifica corretamente a cidade em cerca de dois terços dos casos. Por conseguinte, um utilizador que aparece em dois estados ao mesmo tempo pode criar uma anomalia com pouco ruído.

Os controlos de proxies na cloud normalmente não resolvem por completo este problema. Muitas ferramentas permitem aos utilizadores escolher um país, mas não um estado ou uma cidade. Trabalhar em paralelo — por exemplo, o utilizador navegar localmente enquanto a cloud opera a mesma conta a partir de outra região — acrescenta o mesmo tipo de sinal.

O nosso relatório de criação de contas em §1.2 demonstrou o problema prático. O IP atribuído pela cloud era normalmente um endereço de centro de dados que uma base de dados independente de fraude já classificara como de alto risco. Em cinco das seis ferramentas executadas no servidor, as pontuações de fraude do IPQS eram iguais ou superiores a 94.

A infraestrutura também era partilhada. Dripify, Skylead e We Connect são todos encaminhados através da HostRoyale Technologies, ASN 203020, e o Skylead atribuiu a ambas as nossas contas de teste o mesmo IP no mesmo /24.

Assim, «um IP dedicado no seu país» pode parecer mais seguro do que realmente é. No nosso teste, medimos frequentemente um IP de centro de dados sinalizado numa infraestrutura partilhada, e nenhuma das ferramentas testadas verificou a reputação do IP antes de o atribuir.

2.10 Fuso horário e configuração regional

O fuso horário e a configuração regional são sinais menores, mas continuam a acrescentar contexto. Como afirmou o nosso especialista: «um fuso horário incorreto é mais um ponto».

A impressão digital recolhe o fuso horário duas vezes, através de dois métodos. Por isso, uma simulação parcial pode expor-se se os valores não coincidirem. Também recolhe os idiomas do sistema.

Uma sessão «baseada nos EUA» executada num computador configurado para UTC+5 e com uma configuração regional incompatível é o tipo de incoerência que a funcionalidade signals foi concebida para sinalizar.

2.11 A camada comportamental: os utilizadores manuais também podem ativá-la

As secções anteriores centram-se na deteção de ferramentas. Esta camada centra-se no comportamento, razão pela qual os utilizadores manuais do LinkedIn também podem enfrentar restrições.

Os principais riscos comportamentais são fáceis de compreender:

• Volume: as observações históricas da equipa de suporte do nosso especialista mostraram que cerca de 500 pedidos de ligação por dia podiam provocar uma restrição em aproximadamente duas semanas. O envio de um pedido de ligação a cada 5 segundos podia causar o fim da sessão. Atualmente, o limite é inferior porque o LinkedIn utiliza um limite contínuo de cerca de 100 pedidos de ligação por semana para a maioria das contas, que pode chegar a cerca de 200 para perfis antigos com um Índice de Vendas Sociais (SSI) elevado e a cerca de 250 com o Sales Navigator.
• Forma de abertura dos perfis: colar URLs de perfis em massa pode assemelhar-se a um padrão de extração. Chegar aos perfis através da pesquisa por nome assemelha-se mais ao fluxo normal de um utilizador. A abertura de URLs em massa é um fator de restrição documentado, mesmo quando efetuada manualmente por uma pessoa.
• Reações dos destinatários: a taxa de aceitação é importante, tal como as denúncias de «Não conheço esta pessoa». Mesmo com uma taxa de aceitação de 80 %, 400 pedidos de ligação por dia deixam diariamente 80 pessoas a decidir se devem ignorar, rejeitar ou denunciar o pedido.
• Acesso paralelo a partir de países diferentes: isto remete para §2.9. Utilizar a conta localmente enquanto um serviço de cloud atua a partir de outro país pode acrescentar sinais de risco ao nível da rede.

A arquitetura e o comportamento são camadas distintas. Uma configuração mais limpa pode continuar a criar risco se a conta se comportar de forma irrealista, e o trabalho manual pode continuar a provocar restrições quando o volume ou os padrões parecem automatizados.

3. É um modelo de pontuação: como as sanções do LinkedIn se agravam

Nenhum dos sinais de deteção em §2 deve ser tratado como um mecanismo binário. O enquadramento do especialista corresponde ao que encontrámos no código, nos testes na cloud e nos padrões comportamentais: «Tudo funciona como um modelo de pontuação; cada elemento acrescenta pontos que aproximam a conta de um bloqueio».

Isto significa que o LinkedIn não precisa de um único sinal perfeito. Pode comparar muitos sinais menores no seu navegador, no comportamento da extensão, no endereço IP, no histórico da sessão e nos padrões de prospeção.

A progressão das sanções é bem conhecida entre os utilizadores que já foram alvo de restrições:

1. Aviso: o LinkedIn pode apresentar a mensagem «you may be using automation tools».
2. Restrição temporária: a conta pode ser limitada até concluir a verificação de identidade, como a verificação por SMS ou o carregamento de um documento de identificação.
3. Bloqueio permanente: quando o LinkedIn apresenta «LinkedIn Member» em vez de um nome, normalmente significa que a conta deixou de existir.

O risco acumula-se em várias camadas. Uma extensão instalada pode acrescentar um sinal (§2.1), os vestígios no código podem acrescentar mais (§2.2–§2.8), as anomalias de rede podem acrescentar outro grupo (§2.9–§2.10) e o comportamento da conta pode elevar ainda mais a pontuação (§2.11).

Uma arquitetura de menor risco não protege contra comportamentos imprudentes. Se enviar demasiados pedidos de ligação, abrir perfis em massa através de URLs ou provocar demasiadas denúncias de «Não conheço esta pessoa», o comportamento por si só pode criar risco de restrição.

O caso inverso é ainda mais importante para a escolha da ferramenta. Um comportamento cuidadoso não corrige uma arquitetura arriscada. Enviar 15 pedidos de ligação por dia não elimina os sinais técnicos criados quando o cookie da sua sessão é reutilizado a partir de um centro de dados noutro país.

4. Lista de verificação para uma auditoria do código em 5 minutos

Não precisa de ser investigador de segurança para fazer uma primeira auditoria a uma extensão do Chrome. Pode descompactar a extensão com um visualizador de pacotes de extensões do Chrome (CRX) ou instalá-la e inspecionar os ficheiros locais da extensão.

No macOS, as extensões instaladas do Chrome são normalmente guardadas em ~/Library/Application Support/Google/Chrome/Default/Extensions/. Quando tiver os ficheiros, procure os padrões abaixo.

Esta é a mesma lógica de auditoria subjacente às afirmações sobre o código neste relatório. Não avalie apenas uma permissão. Siga o que acontece ao valor e para onde este é enviado.

Ao redigir o veredito de uma auditoria, associe a afirmação às provas. Se o código mostrar que um cookie é enviado para o domínio de um fornecedor, diga-o diretamente. Se não for possível observar externamente o comportamento do servidor, classifique-o como «altamente provável» e explique o percurso do risco.

Um modelo útil para redigir vereditos, baseado no especialista, é: «A extensão funciona como uma ponte para extrair cookies e não tem qualquer outra finalidade» ou, no caso das clouds: «É altamente provável que o serviço funcione através de chamadas diretas à API; os riscos são A, B e C».

Toda a acusação deve corresponder a um ponto concreto do código. Tudo o resto deve ser classificado como «altamente provável».

5. A tabela geral de riscos

Esta tabela apresenta as conclusões em linguagem simples. Mostra o problema, o que está em risco e onde o encontrámos ou medimos.

Quanto ao comportamento do servidor, classificamos a afirmação como «altamente provável», pois não é possível provar integralmente a execução interna de um servidor na cloud a partir do exterior. Apenas apresentamos como factos aquilo que encontrámos no código ou medimos diretamente durante a criação das contas.

6. Como automatizar de forma mais segura

Estes benchmarks só fazem sentido quando a arquitetura já é limpa. Se a sua ferramenta utilizar carregamento de sessões, infraestrutura de cloud partilhada ou configurações de proxy sem controlo, os limites diários por si só não eliminam o risco técnico acima descrito.

Faça estas verificações antes de executar qualquer automatização de atividades no LinkedIn:

• Mantenha os pedidos de ligação entre 15 e 20 por dia. Isto corresponde ao que permite o limite contínuo do LinkedIn de cerca de 100 pedidos de ligação por semana. O antigo conselho de «50–70 por dia» é anterior ao limite semanal.
• Cancele os pedidos de ligação pendentes aproximadamente a cada 3 semanas. Uma grande acumulação de pedidos ignorados pode tornar-se um sinal negativo por si só.
• Acompanhe a sua taxa de aceitação. Se a aceitação diminuir, normalmente o problema está na segmentação ou na adequação da mensagem, e não apenas no limite diário.
• Crie um histórico normal de atividade antes de automatizar uma conta. Mantenha cerca de um mês de atividade manual normal, uma fotografia real e um empregador verdadeiro antes de automatizar uma conta recente ou pouco ativa.
• Abra os perfis através da pesquisa por nome, e não colando URLs em massa. Como referido em §2.11, a abertura de URLs em massa também pode restringir utilizadores manuais.
• Utilize um IP por conta, com uma localização geográfica coerente. Mantenha a mesma cidade ou o mesmo estado sempre que possível e alinhe o fuso horário e a configuração regional com a localização habitual da conta (§2.9–§2.10).
• Não execute sessões paralelas. Evite utilizar a conta localmente enquanto uma ferramenta a opera a partir da cloud. Evite também dois dispositivos, duas regiões ou atividade local e na cloud em simultâneo.

Uma abordagem de menor risco combina uma arquitetura mais limpa, uma origem de sessão estável, um ritmo realista e um comportamento semelhante ao de um membro normal do LinkedIn que utiliza a conta.

7. Porque a Linked Helper utiliza uma aplicação para computador

Divulgação completa

Este relatório é publicado pela Linked Helper, pelo que devemos ser claros quanto à nossa própria posição. A nossa arquitetura resulta das lições que aprendemos quando a primeira versão da Linked Helper ainda era uma extensão do Chrome.

Essa experiência demonstrou-nos algo importante: todas as extensões têm superfícies de deteção que o software autónomo para computador não precisa de ter. Decidimos não continuar a ajustar uma extensão em função desses sinais.

Veja como essa escolha se relaciona com os riscos abordados neste relatório.

Sem vestígios de extensão

A Linked Helper não é uma extensão do navegador. Não existe um ID da Chrome Web Store, um pacote de extensão instalado no Chrome nem um recurso de extensão que o scanner AED do LinkedIn possa sondar (§2.1).

Também não existe código injetado nas páginas do LinkedIn. As interfaces de extensões, os scripts de conteúdo, os botões e os painéis injetados podem tornar-se visíveis para o sistema Spectroscopy e para a análise de instantâneos da página (§2.2–§2.3).

A Linked Helper mantém os controlos das campanhas, as filas e os painéis dentro da aplicação para computador. A página do LinkedIn não é modificada com painéis ou scripts de extensão da Linked Helper.

Sem transferência da sessão para a cloud

A sua sessão do LinkedIn permanece no seu computador. A Linked Helper não carrega li_at, li_a, conjuntos de cookies, armazenamento do navegador ou pacotes de sessões para a cloud de um fornecedor.

Isto elimina vários padrões de risco abordados anteriormente no relatório:

• Nenhum navegador remoto atua em seu nome
• Nenhuma infraestrutura cloud com várias contas executa a sua sessão
• Nenhuma infraestrutura de rede partilhada do fornecedor é associada à sua conta
• Não é necessária qualquer reutilização oculta da sua sessão do LinkedIn na cloud

A Linked Helper também não automatiza atividades no LinkedIn através de uma camada separada de reprodução de chamadas à API. Muitos produtos de cloud dependem da reprodução do tráfego da API do LinkedIn, o que pode criar um padrão de pedidos diferente do de uma sessão normal do navegador.

Em vez disso, a Linked Helper funciona através do seu próprio motor local de navegador. As ações ocorrem num ambiente de navegador no seu computador, utilizando a sua sessão autenticada do LinkedIn e o seu endereço IP, ou o proxy que atribuir.

Uma identidade separada para cada conta

A Linked Helper separa a identidade do navegador por conta. Executar várias contas do LinkedIn através de um único perfil do navegador pode criar sinais de correlação, pelo que cada instância da Linked Helper utiliza cookies, armazenamento e caches separados.

Cada instância também pode gerar as suas próprias características de impressão digital do navegador. Isto reduz a probabilidade de várias contas parecerem vir exatamente da mesma configuração de dispositivo.

Existe ainda proteção contra a utilização da conta errada. Se tentar iniciar sessão noutra conta do LinkedIn numa instância existente, a Linked Helper termina a sessão da conta atual em vez de misturar silenciosamente as sessões.

Para equipas ou utilizadores que gerem várias contas, o controlo do proxy também é importante. A Linked Helper permite atribuir um proxy a cada instância, para que controle a identidade de rede associada a cada conta.

Isto difere de muitas ferramentas de cloud, nas quais o fornecedor escolhe o IP de saída por si. A Linked Helper também inclui um verificador integrado da reputação de IP baseado em dados do IPQualityScore (IPQS), para que possa avaliar a qualidade do proxy antes de executar campanhas.

Os controlos comportamentais continuam a ser importantes

A arquitetura apenas reduz alguns sinais de risco técnico. O LinkedIn também pode avaliar o comportamento da conta, pelo que este continua a ser importante.

A Linked Helper inclui controlos que ajudam a evitar padrões claramente mecânicos:

• Navegação na página: a Linked Helper pode pesquisar e clicar através da própria interface do LinkedIn, em vez de aceder diretamente através de URLs de perfis.
• Limites de ações diárias: as predefinições conservadoras ajudam a reduzir picos de atividade irrealistas.
• Limites contínuos de 24 horas: os limites são medidos em períodos contínuos, e não apenas por dias de calendário.
• Atrasos aleatorizados: o tempo entre ações varia em vez de repetir sempre o mesmo intervalo.
• Volumes e horários diários aleatorizados: a atividade das campanhas pode variar de dia para dia, em vez de repetir números idênticos.
• Variações das mensagens: pode alternar entre várias versões das mensagens para que a prospeção não pareça a repetição da mesma mensagem-modelo.

Estes controlos não eliminam o risco da automatização; ajudam a fazer com que a atividade da conta se aproxime do comportamento normal no LinkedIn.

A ressalva honesta

Nenhum fornecedor pode prometer segurança total, incluindo a Linked Helper. A camada comportamental descrita neste relatório avalia tanto a atividade manual como a atividade automatizada.

Uma prospeção deficiente, um volume excessivo, taxas de aceitação baixas, atividade invulgar na conta e uma segmentação fraca podem criar risco, independentemente do software utilizado. Uma arquitetura mais limpa reduz alguns sinais técnicos, mas não torna seguro um comportamento imprudente na conta.

A pergunta útil não é «seguro ou inseguro». A pergunta útil é quantos sinais detetáveis a arquitetura expõe antes de o seu comportamento sequer ser considerado.

A Linked Helper foi concebida para manter a sessão local, evitar sinais de extensão e de transferência de sessões para a cloud, isolar as identidades das contas, dar-lhe controlo sobre a configuração do IP e permitir um ritmo mais realista.

Nota metodológica

A análise estática foi efetuada em pacotes de extensões distribuídos publicamente em maio–junho de 2026. A auditoria de criação de contas na cloud testou sete ferramentas, com duas contas em cada uma, em junho de 2026.

As versões mudam e os fornecedores disponibilizam atualizações. As classificações deste relatório refletem o código que lemos e os IPs que nos foram atribuídos durante os testes. As referências a ficheiros e linhas, os IPs de saída, a reputação dos IPs e a presença das extensões complementares na lista de deteção estão disponíveis nos casos em que esses elementos foram recolhidos ou medidos.

O comportamento interno dos servidores é classificado como «altamente provável» em todo o relatório, pois não conseguimos provar externamente todos os métodos de execução no servidor. Apenas apresentamos como factos aquilo que podemos demonstrar no código ou medir diretamente.

Este guia é o mapa. Cada análise detalhada por marca fornece provas mais aprofundadas, e o exemplo do Dux-Soup em §1 demonstra como um produto pode combinar vários padrões arquiteturais em diferentes planos. A Linked Helper não está afiliada ao LinkedIn, não é apoiada por este nem é um parceiro oficial do LinkedIn.