Se o ambiente de impressão digital é “real” não depende da pontuação dada por um site de detecção qualquer, e sim de os sinais de rede, navegador, sistema, hardware e permissões serem coerentes entre si e permanecerem estáveis após várias inicializações. Este artigo apresenta um método de verificação em camadas, uma tabela de anomalias comuns e sugestões para solucionar os problemas passo a passo em um navegador de impressão digital.
Para saber se o ambiente de um navegador de impressão digital é real, não basta olhar para os 90 ou 100 pontos dados por um site de detecção qualquer. Um critério mais significativo é: não haver contradições evidentes entre os sinais de rede, navegador, sistema operacional, hardware e permissões; o mesmo ambiente permanecer estável após várias inicializações; e as funções necessárias nos sites de negócio funcionarem normalmente.
A ferramenta de detecção mostrar verde não significa que qualquer plataforma vai aceitar esse ambiente; aparecer vermelho também não quer dizer, necessariamente, que o ambiente esteja inutilizável. Os sites de detecção usam suas próprias regras, bancos de dados e modelos de pontuação; a decisão final deve combinar os campos específicos, os sites-alvo e o cenário real de uso.
O que é um ambiente de navegador “real”
Um ambiente razoável normalmente atende a quatro condições:
- Consistência interna: o núcleo do navegador, o User-Agent, o sistema operacional, a GPU, o idioma, o fuso horário e a região de rede conseguem se explicar mutuamente;
- Estabilidade ao longo do tempo: após reiniciar, os parâmetros-chave não sofrem grandes alterações irregulares;
- Funcionalidade disponível: funções como login, upload, videochamada, pagamento ou painel de anúncios funcionam normalmente;
- Origem rastreável: a equipe sabe a qual conta, proxy e responsável esse ambiente está vinculado, e as mudanças de configuração ficam registradas.
“Ser idêntico ao computador físico em todos os parâmetros” não é uma condição necessária. O próprio navegador reduz a precisão dos dados para proteger a privacidade. Por exemplo, a documentação da MDN sobre deviceMemory aponta que essa propriedade retorna apenas um valor aproximado de memória, arredondado e limitado entre um mínimo e um máximo; o hardwareConcurrency também pode ser menor do que a quantidade real de processadores lógicos do dispositivo. Portanto, o valor detectado não equivale a um relatório de verificação de hardware.
Estabeleça uma linha de base antes de testar
Não fique alterando os parâmetros repetidamente no ambiente de uma conta importante já em produção. Crie primeiro um ambiente de teste que não faça login em contas de negócio e registre:
- versão do navegador de impressão digital e núcleo Chromium;
- sistema operacional, User-Agent e resolução;
- tipo de proxy, IP de saída, país e cidade;
- configurações de idioma, fuso horário e geolocalização;
- políticas de WebRTC, DNS, Canvas, WebGL e fontes;
- extensões instaladas e parâmetros de inicialização.
Use duas ou três ferramentas de detecção ao mesmo tempo para uma verificação cruzada e salve capturas de tela ou exporte os resultados. Depois, altere apenas uma variável por vez e compare com a linha de base. Só assim é possível saber se a anormalidade vem do proxy, da configuração do navegador, das extensões ou do próprio site de detecção.
Primeira camada: verificar a saída de rede
Primeiro, confirme se o IP público exibido pelas requisições HTTP é o IP do proxy vinculado ao ambiente; em seguida, verifique DNS, WebRTC e IPv6.
IP e DNS
Registre o IP de saída, o ASN, o ISP, o país, a cidade e o fuso horário. Bancos de dados diferentes podem divergir quanto à cidade e ao tipo de proxy; conflitos de país ou de ASN merecem mais atenção do que desvios de cidade isolados.
Se as requisições de DNS passam pela rede local enquanto o acesso às páginas passa pelo proxy, o site de detecção pode mostrar uma região de DNS diferente da região de saída. Verifique prioritariamente se o proxy suporta DNS remoto, se existem configurações de DNS independentes no navegador ou no sistema e se as extensões estão reescrevendo as requisições de rede.
WebRTC
Para estabelecer conexões ponto a ponto, o WebRTC coleta endereços candidatos do ICE. O RFC 8828 explica que ele pode expor endereços públicos e privados adicionais ou, quando o proxy permite conexão direta, contornar o proxy e revelar o IP público real.
Detectar um endereço privado não equivale necessariamente a um vazamento do IP público real; 192.168.x.x, 10.x.x.x etc. são apenas endereços de rede local. O que realmente importa é se aparece, entre os candidatos WebRTC, um outro IP público sem relação com o proxy de saída.
Ao tratar do assunto, não desative o WebRTC de forma mecânica e generalizada. Videoconferência, voz e comunicação em tempo real podem depender dele. A escolha deve seguir o uso: deixar o WebRTC seguir a rota padrão do proxy, usar um proxy com suporte a UDP ou TURN, limitar a exposição de endereços locais ou desativá-lo quando não houver comunicação em tempo real. Após a mudança, teste tanto os resultados de privacidade quanto as funções de negócio.
Geolocalização
As coordenadas da API de Geolocation do navegador podem vir de GPS, Wi-Fi, IP, rede celular ou de dados inseridos pelo usuário. A especificação da W3C para Geolocation deixa claro que a API não garante retornar a localização real do dispositivo.
Portanto, uma pequena diferença entre a cidade do IP e as coordenadas de Geolocation não é necessariamente uma anormalidade. O mais importante é verificar conflitos inexplicáveis entre país, fuso horário, idioma e região de negócio, bem como se o site já obteve permissão de localização.
Segunda camada: verificar o navegador e o sistema operacional
Concentre-se em comparar as seguintes combinações:
- versão do núcleo Chromium e versão principal do navegador indicada no User-Agent;
- sistema operacional informado no User-Agent,
platform, UA Client Hints e conjunto de fontes; - idioma da interface do navegador,
Accept-Language, fuso horário e formatos regionais; - resolução, proporção de pixels do dispositivo, tamanho da janela e capacidade de toque;
- identificadores de dispositivo móvel com tamanho de tela, tipo de ponteiro e características de hardware.
Uma anormalidade comum é ter modificado manualmente o User-Agent sem sincronizar o núcleo ou os client hints; ou ter configurado um ambiente Windows como se fosse macOS, mantendo ainda fontes, GPU e características de interação claramente do Windows.
A forma mais segura não é inventar cada item individualmente, mas usar presets de sistema validados, de modo que núcleo, UA, plataforma e parâmetros relacionados sejam atualizados como um conjunto. Após uma atualização do núcleo, regenere ou verifique o User-Agent; não mantenha bloqueada por muito tempo uma versão claramente desatualizada.
Terceira camada: verificar hardware e sinais de renderização
Canvas, WebGL, AudioContext, fontes, CPU, memória, dispositivos de mídia e ClientRects podem participar da identificação do ambiente. Ao verificar, avalie se “a combinação faz sentido” e se “é estável”, em vez de perseguir um hash único.
WebGL e GPU
Se o ambiente afirma ser um determinado tipo de sistema operacional ou dispositivo, mas o fabricante do WebGL, o renderer e o estado da aceleração de hardware tornam essa combinação claramente impossível, volte ao preset de sistema para verificar. Não troque o nome do fabricante por outra marca apenas para passar em um site de detecção; combinações erradas costumam gerar ainda mais contradições.
CPU e memória
hardwareConcurrency representa a quantidade de processadores lógicos disponíveis para o navegador, que pode reportar voluntariamente um número menor; deviceMemory é um valor aproximado e arredondado. Ver 4 núcleos ou 8 GB não permite deduzir o hardware real, nem deve levar a uma alteração imediata só porque difere do computador físico.
O que se deve verificar é: se os valores estão dentro da faixa suportada pelo navegador, se contradizem claramente o tipo de dispositivo (móvel ou desktop) e se permanecem razoavelmente estáveis após reiniciar o mesmo ambiente.
Canvas e Audio
Políticas de proteção de privacidade ou de ruído podem fazer o mesmo dispositivo físico produzir resultados diferentes em ambientes diferentes. Mas se o hash muda a cada atualização no mesmo ambiente, isso pode indicar randomização excessiva, o que prejudica a estabilidade de sessões de longo prazo.
Teste o mesmo ambiente com atualizações consecutivas, com fechar e reabrir, e com inicializações em dias diferentes. Se a política for desenhada como “ruído estável no nível do ambiente”, o mesmo ambiente deve apresentar uma persistência explicável.
Quarta camada: verificar armazenamento, extensões e parâmetros de inicialização
O isolamento de ambientes não envolve apenas parâmetros de impressão digital, mas também Cookie, Local Storage, IndexedDB, cache, Service Worker, extensões e histórico de downloads.
Use dois ambientes de teste para entrar em sites de teste diferentes e confirme que cookies e armazenamento local não se misturam entre eles; em seguida, verifique se, após limpar o cache, importar cookies ou restaurar o ambiente, os dados ficam como o esperado.
Extensões são uma fonte comum de interferência. Elas podem modificar User-Agent, proxy, cabeçalhos de requisição, Canvas, WebRTC ou scripts da página. Ao encontrar uma anormalidade, desative primeiro todas as extensões não essenciais em uma cópia de teste e depois habilite uma a uma. Parâmetros personalizados de inicialização também devem ser descartados um a um, para evitar que várias ferramentas alterem o mesmo sinal ao mesmo tempo.
Anomalias comuns e como tratá-las
| Sintoma | Possível causa | Tratamento recomendado |
|---|---|---|
| País do IP inconsistente com o fuso horário | Fuso fixado em um valor local, ou identificação incorreta da região do proxy | Confira primeiro o país do proxy; depois, faça o fuso horário seguir o IP ou defina-o conforme a região real de negócio |
| IP de saída HTTP diferente do IP público do WebRTC | Conexão direta via WebRTC, proxy sem suporte a UDP ou roteamento dividido | Ajuste a política de roteamento do WebRTC; teste UDP/TURN e as funções de negócio |
| Versão da UA inconsistente com o núcleo | UA manual desatualizada ou núcleo atualizado sem sincronização | Use um preset correspondente, regenere a UA e reteste os UA Client Hints |
| Identificador macOS com fontes/GPU do Windows | Apenas os campos superficiais foram alterados | Volte ao preset de nível de sistema; evite a montagem manual entre sistemas |
| Canvas muda a cada atualização | Ruído aleatório forte demais ou conflito de extensões | Fixe uma política no nível do ambiente; desative as extensões conflitantes e reteste |
| CPU ou memória marcados em vermelho | O site de detecção interpretou valores aproximados como hardware físico | Verifique primeiro o critério da API do navegador; depois avalie se existe um conflito de combinação de fato |
| Dois sites de detecção com conclusões opostas | Bancos de dados, regras e ritmos de atualização diferentes | Compare os campos brutos, não apenas a pontuação total; use o teste no site de negócio alvo como referência |
| Campos-chave mudam após reiniciar o ambiente | Configuração aleatória não persistida ou ambiente recriado | Verifique as políticas de salvamento, sincronização e impressão digital aleatória; fixe os parâmetros no nível do ambiente |
Como investigar camada por camada no PurpleMark
Se as conclusões anteriores parecerem normais, mas algumas plataformas ainda sinalizarem anormalidades, você pode levar a investigação para o ambiente concreto correspondente no PurpleMark.
O primeiro passo é confirmar a saída. No gerenciamento de proxies do PurpleMark, veja o proxy vinculado ao ambiente atual, confirme o IP de saída, a região e o fuso horário, compare com o IP público exibido pelo site de detecção e verifique se o WebRTC apresenta outro endereço público sem relação com a saída.
O segundo passo é tratar os parâmetros como um conjunto, em vez de alterá-los um a um manualmente. Ao criar um ambiente no PurpleMark, é possível definir de uma só vez o sistema operacional, o núcleo Chromium, o User-Agent, o idioma, o fuso horário e a geolocalização, além de configurar parâmetros de impressão digital como WebGL, WebRTC, CPU, memória e Canvas. Fazer o núcleo, a UA, o sistema operacional e as fontes seguirem o mesmo preset evita resultados contraditórios como “fontes do Windows com identificador macOS”; antes de criar, veja a pré-visualização do ambiente para confirmar que a combinação de campos é razoável e só então salve e use.
O terceiro passo é experimentar com segurança. Duplique o ambiente com problema como cópia de teste e não faça alterações repetidas no ambiente em produção. Ajuste apenas uma variável por vez — por exemplo, mude primeiro o proxy ou o roteamento do WebRTC e depois a política de ruído do Canvas — e salve o resultado da detecção a cada mudança; depois de reiniciar duas vezes seguidas e confirmar a estabilidade, execute o fluxo real de negócio do site-alvo. Se houver suspeita de interferência das extensões, habilite uma a uma na cópia para investigar.
Essas ações ajudam a conferir, dentro de uma mesma configuração, a saída, a combinação de parâmetros e a estabilidade, tornando mais fácil localizar “de qual camada vem o resultado da detecção”. Vale esclarecer que o PurpleMark é responsável por manter os parâmetros consistentes e preservar ambientes reproduzíveis; a conclusão final da detecção ainda depende da qualidade do proxy, da versão do navegador, das extensões, do roteamento de rede e da própria lógica de julgamento do site-alvo.
Não crie novas anormalidades em busca da nota máxima
A pontuação dos sites de detecção serve para encontrar pistas e não deve ser o único objetivo. Trocar UA, GPU, Canvas, fontes e fuso horário com frequência pode deixar o ambiente mais instável do que antes; copiar os “parâmetros nota máxima” de outra pessoa também não copia a rede, o hardware e o histórico de uso dela.
A abordagem correta é partir dos campos brutos, corrigir primeiro as contradições evidentes e depois validar a estabilidade de longo prazo e as funções de negócio. Um ambiente que não tem a pontuação mais alta, mas tem uma combinação coerente e estabilidade contínua, costuma ser mais fácil de gerenciar do que um “ambiente nota máxima” que muda a cada detecção.
