O que é impressão digital do navegador (e o que ela não é)

A impressão digital do navegador não é um número secreto gravado no hardware. É um retrato estatístico: a página pergunta dezenas de coisas ao ambiente — tela, fuso, GPU, áudio, fontes, User-Agent, Client Hints, a forma como o Canvas pinta um pixel — e junta as respostas num perfil. Sozinho, quase nenhum sinal identifica ninguém. Juntos, separam “Chrome compartilhado da agência com quarenta logins” de “notebook de uma pessoa, no mesmo fuso, no mesmo IP, todo dia”.

Isso importa para quem opera BM, MCC, Instagram de cliente e Google Ads no mesmo computador. A plataforma não precisa “provar” que você é a mesma pessoa. Precisa de evidência para correlacionar sessões. Fingerprint é uma. Cookie, IP, cartão, pixel e grafo de admin são outras. Tratar fingerprint como vilão único faz o time comprar ferramenta e não mudar o Chrome compartilhado.

O que segue: o que a impressão digital é e não é, os grupos de sinais, User-Agent versus Client Hints, Canvas/WebGL/áudio, por que randomizar falha, e a regra de uma identidade, um ambiente.

O que a impressão digital é — e o que ela não é

Impressão digital, neste contexto, é medição de ambiente. O site executa JavaScript, lê headers, às vezes pede Client Hints de alta entropia, e monta um vetor: sistema, browser, hardware aparente, idioma, geometria, mídia. Não é CPF. Não é MAC. Não substitui login. Não “prova” fraude sozinho. É um sinal no mesmo andar que cookie e IP — só que, ao contrário do cookie, você não apaga com um clique.

O que ela não é importa tanto quanto o que ela é. Não é um ID mágico. Não é sentença. Não é o motivo único de BM desativada, MCC suspenso ou Instagram de cliente em sombra. Criativo furado, landing quebrada, volume de contas no mesmo cartão e admin em dez BMs continuam fora do browser. Isolar ambiente reduz correlação de sessão. Não reescreve Termos de Serviço.

Times de tráfego pago confundem as duas coisas porque o sintoma é o mesmo: a conta caiu. A causa é um mix. Fingerprint entra quando o Chrome da agência abre BM A, BM B, MCC do cliente C e o Instagram pessoal do gestor. Mesmo dispositivo, mesmo IP, cookies vazando de aba. Correlação. Não magia. Não se resolve randomizando User-Agent. Fingerprint descreve como o ambiente se apresenta, não quem você é no contrato.

Os grupos de sinais que o site realmente mede

Ninguém mede “a impressão digital” como um campo único. Mede grupos. O que importa na operação: quais brigam entre si e quais permanecem estáveis de um dia para o outro.

Quatro blocos cobrem o que a agência precisa vigiar:

• Identidade HTTP: User-Agent, Client Hints (Sec-CH-UA, plataforma, mobile, versões), Accept-Language. UA de Windows com Client Hints de macOS, ou idioma japonês com IP de São Paulo, já nasce torto.
• Geometria e sessão: resolução, devicePixelRatio, fuso, hardwareConcurrency, deviceMemory. Notebook de 14" não vira 4K entre o almoço e a reunião. MCC às 10h em Brasília não acorda em Los Angeles porque o proxy mudou de cidade.
• GPU e mídia: renderer WebGL, vendor, hash de Canvas, AudioContext, fontes. Checkers pintam de vermelho. Gerador também.
• Rede: IP do HTTP, IP do WebRTC, DNS, IPv6. Tela bonita não salva perfil que entrega o IP da agência no STUN.

Nada disso é crime. É telemetria de produto que virou telemetria de risco. Checker quer espetáculo; plataforma quer grafo. Na operação, o grupo de rede costuma valer mais do que a lista de fontes.

User-Agent versus Client Hints

User-Agent é a string antiga: header User-Agent e navigator.userAgent. Diz qual browser, sistema e versão o cliente alega ser. Durante anos o time “spoofava” essa string e achava que tinha mudado de máquina. Chrome moderno trata o UA como legado. A fonte nova é Client Hints: headers e navigator.userAgentData, com marca, versão, plataforma, mobile, arquitetura, modelo. O servidor pede; o Chrome responde. A página vê. Você, na barra de endereço, não.

O problema operacional é simples: os dois precisam contar a mesma história. UA de Windows 10 e Chrome 128 não combina com Client Hints de macOS nem com outra versão. Extensão que só reescreve navigator.userAgent e esquece userAgentData e Sec-CH-* produz esse Frankenstein. Sites de login e de anúncio pedem hints de alta entropia. A briga aparece ali, não no chrome://version.

Descompasso comum: o perfil “é Windows”, o proxy é residencial brasileiro, e alguém cola um UA de iPhone “para parecer mobile”. Client Hints de desktop, viewport de 1920, maxTouchPoints zero, WebGL de notebook. Instagram de cliente não trata isso como celular. Trata como mentira. Mobile é um ambiente, não uma string. Versão também precisa bater: UA de dois anos atrás numa versão nova do navegador — ou o inverso — o checker pega, e a plataforma também, mesmo sem painel vermelho para o gestor.

Regra prática: não edite User-Agent na mão. Não instale “UA switcher” no perfil de anúncio. Escolha um preset de sistema e deixe UA e Client Hints nascerem juntos, estáveis, iguais amanhã. Briga entre os dois: perfil errado — não “um pouco personalizado”.

Canvas, WebGL e áudio: o retrato da GPU

Canvas fingerprint: a página desenha fora da vista, lê os pixels e reduz a um hash. O hash muda com GPU, driver, sistema, anti-aliasing, às vezes com a versão do browser. No mesmo dispositivo, no mesmo perfil, tende a repetir. É o que o site quer: reconhecer o ambiente de novo, sem ser um cookie.

WebGL entra com mais metadados: vendor, renderer, extensões, às vezes o nome da placa. Perfil macOS com renderer Intel de PC mente em voz alta; Windows com strings de Apple Silicon mente do outro lado. O time não precisa saber o nome de cada GPU. Precisa saber que renderer e sistema declarado não podem brigar. Áudio (AudioContext) é o primo: oscilador, analisador, hash. Às vezes menos estável que o Canvas; ainda soma entropia. Randomizar áudio ou Canvas a cada página não te faz anônimo. Te faz único de um jeito que dispositivo real não é. Dispositivo real não ganha hash novo a cada F5.

O erro clássico é tratar esses hashes como nota. Checker pinta Canvas de vermelho, alguém liga ruído, o hash muda o tempo todo, o time comemora. Para o classificador, você saiu de “notebook comum de agência” para “ambiente que não existe duas vezes”. Único demais também denuncia. O objetivo não é zerar o teste. É um dispositivo plausível e repetível.

Estabilidade importa mais que beleza do hash. Segunda: anote Canvas, renderer, áudio. Terça, mesmo proxy, mesmo perfil. Se mudou sozinho, você não tem perfil — tem gerador. BM e MCC precisam de repetição. Surpresa é para criativo, não para GPU.

Por que randomizar tudo falha

A tentação é mecânica: se o site mede sinais, mude os sinais. Tela nova, GPU sorteada, fuso pulando, UA de um país e idioma de outro. O resultado não é um humano viajando. É um script. O notebook da gestora não troca de placa no Uber de volta do cliente. Randomizar dentro de uma sessão é pior: a página mede no primeiro paint, de novo num iframe, de novo no login. Hash que muda no meio do fluxo não confunde o detector. Assina o spoof. Classificadores olham consistência temporal, não só o valor absoluto.

Randomizar entre sessões da mesma identidade também quebra o modelo. A conta de Ads da loja X mora num dispositivo. Segunda: Windows 11 Full HD, GPU A. Terça: Mac retina, GPU B. Mesmo login, mesmo MCC. A história é de quem troca de máquina o tempo todo — ou fabrica máquinas. Não é a de um gestor sentado no mesmo lugar.

Há um medo razoável: “se todos os perfis forem iguais, a plataforma agrupa”. Dezenas de BMs no mesmo Chrome compartilhado é um cluster. A resposta não é floco de neve com entropia de laboratório. É isolamento: cada identidade num ambiente estável, proxy coerente, cookie que não viaja. Dois Windows 11 parecidos, IPs diferentes, cookies diferentes — o mundo real também produz isso. GPU impossível e UA que não bate com Client Hints, não. Coerência vence aleatoriedade: país do proxy, fuso, idioma, UA/Hints, geometria e GPU no mesmo parágrafo.

Cookies, IP e grafo de pagamento: o fingerprint não trabalha sozinho

Plataformas de anúncio não têm botão “banir por Canvas”. Têm modelo de risco em camadas. Fingerprint é uma. Cookie e storage são outra — ver cookies vs fingerprint. IP é outra; qualidade de IP pesa mais que hash de fonte. Pagamento, pixel, admins da BM e velocidade de campanha são outras.

Na prática da agência, a correlação mais barata continua sendo o Chrome compartilhado. Gestor A loga na BM do cliente 1. Sem deslogar de verdade, abre o Ads do cliente 2. Cookie do Google, IP do escritório, fingerprint do notebook: tudo fica. A plataforma não precisa de laboratório. Precisa do que o time entregou na mesma sessão. Fingerprint coerente com datacenter barato e WebRTC vazando o IP do escritório é o teatro inverso: mente na rede, acerta na GPU. O classificador olha a rede primeiro.

O grafo de pagamento o browser não isola. Mesmo cartão, documento e e-mail de recuperação sobrevivem a perfil novo, cookie limpo e fingerprint bonito. Quem trata BM desativada como problema de Canvas olha o andar errado. Recurso, política e pagamento primeiro. Ambiente depois. Três das quatro camadas no mesmo cluster da agência: a quarta não salva.

Dispositivo plausível versus floco de neve

Existe um alvo errado em grupo de Telegram: ser único. “Nenhum outro browser no mundo tem este vetor.” É o oposto do que um notebook real produz. Windows 11, Chrome atual, Full HD, GPU de escritório, fuso de Brasília, pt-BR: perfil popular. Popular é bom. É o que milhões de pessoas usam para anunciar.

Floco de neve mistura GPU que não existe naquele OS, hardwareConcurrency 3, memória 0,25, UA móvel, Client Hints de desktop, Canvas com ruído. Nenhum comprador de mídia vive nisso. O detector não precisa do seu nome: marca “isto não parece um dispositivo”. Plausível: um humano poderia ter comprado essa máquina, nesse fuso, nesse tipo de IP. Repetível: amanhã o perfil ainda conta a mesma história. Os dois critérios matam a maior parte das “otimizações” de tédio depois do checker.

Não busque 100/100 em teste paranoico. Busque ausência de contradição e estabilidade. O que importa versus teatro está em como ler testes de fingerprint. Dois perfis da agência podem parecer parecidos se ambos são Windows de trabalho. Não é falha. É o parque. O que separa identidades não é GPU inventada. É cookie isolado, IP dedicado quando o risco pede, e não logar a BM do cliente B no perfil do cliente A.

Como plataformas de anúncio usam isso na prática

Google não publica “banimos por WebGL”. Meta tampouco. O que o time observa: sessões no mesmo dispositivo, mesmo IP, mesmo cookie de login, andam juntas. MCC com dez contas no Chrome da agência não cai “por fingerprint”. Cai porque a identidade Google do gestor, o cookie, o IP e o ambiente são um objeto só. Isolar múltiplas contas Google começa por não tratar o Chrome como sala de espera.

No Ads, o login do Google é o ímã. Perfil “limpo” que loga o Chrome com a conta pessoal do gestor puxa o grafo inteiro. Client Hints e Canvas descrevem o notebook certo; o cookie descreve a pessoa errada. A regra não é só “um fingerprint por conta”. É um ambiente que não mistura logins. Google Ads com MCC de cliente não mora na mesma sessão do Gmail pessoal.

Na Meta, a BM é um grafo de pessoas, páginas, pixels e cartões. O browser vê o login. A plataforma vê o admin de uma BM morta reaparecer em outra, no mesmo dispositivo. Fingerprint liga a sessão nova à antiga quando o cookie já foi limpo. Pagamento e pixel costumam ser fios mais grossos; este é o que sobrevive ao “limpei o Chrome e abri outra”. Perfil novo depois de política quebrada, no mesmo cartão e pixel, é otimismo.

Instagram de cliente no Chrome da agência: três contas no switcher, mesmo IP, mesmo fingerprint. Isolar cookie reduz postar no perfil errado. Isolar ambiente reduz a história de que três negócios moram no telefone do estagiário. Plataforma não precisa do hash de Canvas para aplicar Termos. Precisa dele para juntar o que o time só separa na planilha.

Uma identidade de anúncio, um ambiente

Identidade de anúncio não é “cliente”. Um cliente pode ter BM própria, MCC e Instagram da loja. Três identidades, três ambientes. Ambiente é o pacote que se repete: perfil, fingerprint estável, proxy alinhado, cookie que nasce ali e não viaja. Não é extensão, modo anônimo, nem “a gente desloga com cuidado”.

• Inventarie: cliente, plataforma, identidade, perfil, proxy, dono, último acesso.
• Crie o ambiente vazio. Proxy primeiro. Teste de leak (IP HTTP versus WebRTC, fuso, idioma, UA versus Client Hints) antes do login.
• Congele. Não mexa em GPU, tela e UA por tédio. Se o teste mudou sozinho, descarte o perfil.
• Só então cole sessão ou faça login. Cookie importado em ambiente diferente do original é sequestro aparente, não atalho.
• Uma identidade não viaja de perfil. Estagiário não “entra um minutinho” no Chrome da BM. Na saída, revogue acesso; não espere o colaborador deslogar.

Essa ordem existe porque o inverso é o cotidiano: login primeiro, proxy depois, teste nunca. Ferramenta sem essa ordem vira placebo. A escolha de navegador vem no fim. Teste honesto: anote IP, WebRTC, fuso, UA, Client Hints, renderer, Canvas; abra amanhã. História igual: ambiente. História nova: sorteio. Fingerprint só faz sentido quando o mesmo gestor, a mesma BM e o mesmo MCC moram no mesmo aparelho aparente de propósito — não por acidente do Chrome compartilhado.