- O checker é um demo, não um KPI
- Olhe primeiro: IP, WebRTC, fuso e idioma
- Depois: UA, Client Hints, OS e webdriver
- Extensões: o jeito educado de quebrar o isolamento
- Canvas e WebGL como sinal de leitura — não como nota
- O que ignorar (na maior parte dos casos)
- Ritual de aceite de um perfil
- Quando refazer o perfil — e os falsos alarmes
Ferramentas tipo CreepJS, BrowserLeaks e primos existem para demonstrar o quanto um browser vaza em laboratório. Elas não existem para ser o KPI da agência. Tratar o score como nota de vestibular é o jeito mais rápido de gastar a tarde em toggle que não muda o risco de BM, enquanto o HTTP e o WebRTC continuam brigando. O teste serve para ler contradições. Não serve para perseguir 100/100.
Este texto é um guia de leitura. Se você ainda não sabe o que entra no retrato, volte em o que é impressão digital do navegador. Se o problema na tela é IP, vá direto ao vazamento WebRTC. Aqui o trabalho é outro: abrir o checker, respirar, e decidir o que é aceite de perfil e o que é teatro.
O checker é um demo, não um KPI
CreepJS e afins foram feitos para um público de pesquisa e de paranoia útil: mostrar que “modo anônimo” não esconde GPU, que canvas identifica, que um Chrome recém-instalado ainda é classificável. Isso é verdade e é irrelevante como meta de mídia. A plataforma de anúncio não abre o mesmo dashboard colorido. Ela soma IP, cookie, pagamento, velocidade de campanha e um modelo de risco que você não calibra com um site de score.
O número grande no topo (trust, uniqueness, “bot like”) é um produto de comunicação. Ele assume, no fundo, que qualquer distância de um Chrome vanilla de laboratório é culpa. O Chrome vanilla da sua agência, com 40 logins, Meta Pixel Helper e a extensão da senha, também seria um cluster. Perseguir a nota é otimizar para o professor errado.
Use o checker como lanterna. Ele ilumina blocos: rede, tempo, língua, UA, WebGL, canvas, automação, extensões. Você lê bloco a bloco, na ordem deste artigo, e para quando os blocos que importam para anúncio estiverem coerentes. O resto fica no backlog. Agência que opera dezenas de contas precisa de um padrão de aceite, não de um ranking interno de quem “zerou o CreepJS”.
Olhe primeiro: IP, WebRTC, fuso e idioma
A primeira tela que importa não é canvas. É rede versus relógio versus língua. IP HTTP contra IP público do WebRTC. Fuso do sistema contra o país do IP. Idioma do browser e do sistema contra a história que aquele perfil conta. Se esses quatro brigam, o resto é enfeite. Uma conta de Google Ads não cai porque a lista de fontes tem dois itens a menos. Cai porque o ambiente parece fazenda, porque a política de anúncio foi violada, ou porque o grafo de pagamento já estava sujo.
IP HTTP é o “onde esta conexão web diz que está”. WebRTC é o “quais outros endereços este browser ainda entrega”. Os dois precisam ser o mesmo lugar — o proxy da operação, não a fibra do escritório. Se você só olhou o ipinfo e pulou o bloco WebRTC, você não leu o teste. O artigo de vazamento cobre o ritual; aqui basta a regra de leitura: desacordo entre HTTP e STUN é bloqueio de aceite, não um “warning amarelo” para negociar.
Fuso e idioma são a história. Proxy residencial em Lisboa com Windows em America/Sao_Paulo e pt-BR só é coerente se a identidade é um brasileiro viajando — e viajar todo dia, em toda conta, é um padrão de fazenda. Proxy em São Paulo com en-US e fuso de Nova York denuncia perfil copiado de preset gringo. Você não precisa de um mapa perfeito de cidade. Precisa de um país, um fuso e uma língua que um humano naquele IP teria. Se o cliente é loja brasileira, o default honesto é Brasil, America/Sao_Paulo (ou o fuso real da praça) e pt-BR. Exceção se documenta. Exceção sem documento é bug.
Faça essa leitura em voz alta no aceite. “HTTP SP, WebRTC SP, fuso São Paulo, pt-BR.” Se a frase não fecha, não avance para User-Agent. Times perdem hora em Client Hints com o IP real ainda no STUN. Isso não é perfeccionismo. É ordem errada.
Depois: UA, Client Hints, OS e webdriver
User-Agent e Client Hints contam o mesmo filme do sistema. Chrome 126 em Windows 10 no UA, com Client Hints de macOS, é contradição. Chrome “Android” em um perfil que roda num desktop com WebGL de NVIDIA de escritório é contradição. O objetivo não é o UA mais popular do mundo. É UA, hints, plataforma e GPU no mesmo dispositivo plausível. Se o perfil diz Mac e o renderer WebGL diz Direct3D, você não tem Mac. Tem fantasia.
Leia Client Hints como o Chrome moderno fala de si: marca, modelo, versão, plataforma, bits. Sites grandes já olham isso há anos. Mentir só no UA e deixar hints nativos do host é um clássico de 2018 que ainda aparece em perfil mal congelado. No aceite, compare três linhas: UA, sec-ch-ua-platform (ou o bloco equivalente do checker), e o OS que o WebGL/renderer sugere. Duas iguais e uma diferente: a diferente manda.
navigator.webdriver true não é nuance. É automação. Selenium, Playwright, Puppeteer e primos acendem isso quando ninguém apagou. Perfil de anúncio com webdriver true não entra em BM. Não “só para testar o pixel”. Você está apresentando um robô para um sistema que já desconfia de robô. Se o checker mostra webdriver true, a ação é recusar o perfil, não maquiar o resto dos scores.
Outros sinais de automação entram na mesma gaveta: leftovers cdc_, HeadlessChrome no UA, Lighthouse. Não precisa memorizar a lista da moda. Se o checker grita automação de forma clara, o perfil não é de gestor. É de pipeline. Scrap e Ads Manager não compartilham aceite.
Extensões: o jeito educado de quebrar o isolamento
Checker de fingerprint adora listar extensões, porque extensão é identidade. Cada uma injeta script, altera DOM, expõe chrome.runtime, às vezes adiciona CSS único. O time instala “só o essencial” e o essencial vira um código de barras. Pixel Helper, Translate, Grammarly, Dark Reader, gerenciador de senha, seletor de proxy, bloqueador de anúncio, “WebRTC Leak Prevent”: todas mudam a página de um jeito que um Chrome limpo muitas vezes não muda.
O problema não é moral. É estatístico. Cinco contas “isoladas” com a mesma tríade Grammarly + Pixel Helper + 1Password formam um cluster. A plataforma não precisa saber o nome da extensão. Basta o mesmo padrão de objetos, o mesmo timing de inject, o mesmo conjunto de recursos. Extensão de proxy no Chrome vanilla ainda é pior: ela “resolve” HTTP e deixa WebRTC e DNS no host, além de se anunciar como plugin.
No aceite, a lista de extensões do perfil deveria ser curta e igual ao checklist do time. Zero é um default honesto para identidade de anúncio. Se o time precisa de um bloqueador, ele entra no padrão de todos os perfis daquele job — não no gosto do gestor. Extensão “mágica de anonimato” é quase sempre regressão: ela tenta esconder um sinal e cria três. Leia o bloco de extensões do checker como inventário, não como score. Se apareceu algo que ninguém documentou, o perfil não está congelado. Está habitado.
Isso vale para permissões. Câmera e microfone liberados num perfil que só abre Ads Manager é estranho. Você não precisa zerar permissão de tudo. Precisa de uma história: este dispositivo é um computador de trabalho que acessa o gerenciador de anúncios — não um laboratório de privacidade.
Canvas e WebGL como sinal de leitura — não como nota
Canvas e WebGL entram no checker com hashes, “lies” e uniqueness. A leitura útil para operação é outra: o desenho é estável? Você recarrega a página três vezes no mesmo perfil. O hash de canvas permanece. O renderer WebGL permanece. A GPU não troca de marca. Isso parece um dispositivo. Se a cada F5 o canvas muda, você não parece um humano com placa de vídeo. Parece um gerador.
Estabilidade não é o mesmo que “igual ao Chrome do laboratório do site”. Dois notebooks reais já desenham canvas diferente. O que a plataforma usa, na prática, é persistência: o mesmo ambiente volta amanhã parecido. Randomizar canvas a cada request foi moda de ferramenta e continua sendo um jeito de gritar “estou me escondendo”. No aceite, anote o hash uma vez. Amanhã, no mesmo perfil, sem mudança de máquina, ele deve estar no mesmo bairro. Mudou sozinho: o perfil não existe. Existe um sorteio.
WebGL renderer e vendor precisam conversar com o OS do UA. ANGLE (NVIDIA ... Direct3D11) em um perfil Windows é banal. O mesmo renderer num UA de iPhone não é banal. “Google Inc. (NVIDIA)” no vendor, no Windows, também é prosa do Chrome, não prova de fraude. Muitos checkers marcam isso como anomalia porque comparam com um baseline estreito. Trate como falso alarme até o trio UA / OS / GPU brigar de verdade.
Áudio (AudioContext) segue a mesma lógica: estabilidade vale mais que unicidade. Hash único no laboratório assusta. Hash que dança a cada reload denuncia. Se o áudio estiver vermelho e IP, WebRTC e fuso estiverem limpos, anote e siga. Desmonte se áudio, canvas e GPU mudarem juntos a cada visita — aí não há dispositivo, há ruído.
O que ignorar (na maior parte dos casos)
Ignore a nota geral. Ignore ranking de “bot”. Ignore a cor vermelha em plugins vazios: Chrome não é mais o zoo de NPAPI de 2012. Ignore diferença pequena na lista de fontes entre dois Windows 11 reais. Ignore “lies” em APIs que o próprio Chrome passou a reduzir por privacidade — Client Hints enxutos, navigator.vendor, certos hardwareConcurrency arredondados. O checker foi escrito para achar distância. Distância pequena de um Chrome atual não é fazenda.
Ignore também o pânico de “uniqueness 100%”. Em amostra de um site de teste, quase todo browser é único. O seu Mac de trabalho é único. O Chrome da recepção é único. Unicidade no demo não traduz “vamos banir”. O que traduz risco operacional é coerência interna e vazamento de rede. Um perfil único e estável, com IP limpo, é um notebook. Um perfil único e instável, com STUN do escritório, é um problema.
Não ignore, em compensação, contradição grosseira. Webdriver. UA versus OS. HTTP versus WebRTC. Extensão que ninguém pediu. Canvas que não se repete. Esses não são teatro. São o motivo de o teste existir na mesa da agência. A arte é não deixar o teatro tapar esses cinco.
Se o time gosta de comparar ferramentas, use o mesmo critério: a boa é a que deixa o aceite repetível, não a que promete score de laboratório. Preset com cinquenta toggles vira arma nas mãos de quem está entediado. Checklist escrito muda risco. Leaderboard de CreepJS não muda.
Ritual de aceite de um perfil
Aceite é uma sequência, não um feeling. Crie o perfil no padrão da agência — OS, idioma, fuso combinados com o proxy do cliente. Aplique o proxy sticky. Não cole cookie. Não logue BM. Abra o checker em uma aba. Leia na ordem: HTTP, WebRTC, DNS se o checker tiver, fuso, idioma. Só se essa frase fechar, leia UA, Client Hints, OS, webdriver. Depois extensões. Depois canvas/WebGL em três reloads.
Se o time usa Lauth, o valor está em ninguém inventar um Frankenstein diferente por gestor: um padrão de perfil, um jeito de testar, um print. O nome da ferramenta não substitui a leitura. O padrão substitui a criatividade destrutiva. O mesmo ritual vale se a mesa tiver outro antidetect. Ferramenta sem procedimento vira Chrome da agência com mais botão.
Tire um print da tela inteira, não do score. Salve no diretório do cliente com data, nome do perfil, proxy, quem testou. Congele: sem extensão nova, sem mudar de host, sem “testar um toggle de GPU”. Só então cole a sessão ou faça o login. Se no meio do caminho o webdriver acender, ou o WebRTC mostrar a operadora do escritório, o aceite falhou. Não negociar. Não “depois a gente vê”. Perfil novo ou perfil consertado, teste de novo.
Quando refazer o perfil — e os falsos alarmes
Refaça quando a rede vazou de verdade: IP real no WebRTC, IPv6 da operadora com HTTP só no proxy, DNS do escritório misturado com residencial. Refaça quando o país do proxy mudou e o fuso/idioma ficaram no preset velho. Refaça quando alguém instalou extensão “para melhorar o teste”. Refaça quando a máquina host mudou de Windows para Mac (ou o contrário) e o perfil ainda conta a história antiga. Refaça quando webdriver apareceu depois de uma atualização. Esses são eventos. Evento pede perfil novo ou reaceite completo, não um toggle.
Não refaça porque o score caiu quatro pontos, nem por um “lie” de Client Hint, nem por uma fonte a menos depois do Windows Update. Não refaça porque o criativo foi recusado — isso é política e pagamento, não hash de canvas. Não refaça porque o Instagram caiu alcance: o caminho é conteúdo e comportamento da conta, não um F5 no CreepJS. Mexer por tédio é regressão. Perfil estável que passa no aceite deve envelhecer como um notebook.
Falsos alarmes recorrentes, para o procedimento ter nome: WebGL vendor “Google Inc.” no Windows com ANGLE; plugins vazios; uniqueness alta; audio hash único; hardwareConcurrency 8; deviceMemory 8; tela 1920×1080. Nada disso, sozinho, é fazenda. Fazenda é muitos perfis com a mesma combinação impossível, a mesma extensão rara, ou o mesmo IP real no STUN.
A leitura madura cabe numa frase: coerência primeiro, score nunca, canvas estável como prova de que o perfil existe, extensão como inventário, webdriver como veto. O checker continua útil. Deixa de ser um jogo de terror. O aceite vira cinco minutos chatos — os que separam operação de superstição.
FAQ
Perguntas frequentes
Não. Nota de laboratório paranoico é comum até em notebook limpo. Ban de anúncio mistura política, pagamento e ambiente.
Não. Precisa de coerência entre IP, WebRTC, fuso e idioma, e de não vazar o IP real. O resto é prioridade, não obsessão.
Sim, como sinal de leitura. Dispositivo de gente não troca de GPU a cada F5. Estabilidade importa mais que o hash ser ‘bonito’.
Costuma piorar. Extensão injeta script, altera o DOM e vira um sinal a mais. Proxy e WebRTC se resolvem no perfil, não na loja de extensão.
Para perfil de anúncio, sim. Não é um Chrome de gestor: é automação fantasiada. Não cole sessão nesse estado.
Vazou IP real, mudou país do proxy sem mudar fuso, alguém instalou extensão ‘mágica’, ou o OS do host não bate mais com o UA. Fora isso, mexer por tédio é regressão.
Continue lendo