Teste de Impressão Digital do Navegador: Analise Canvas, WebGL e Unicidade

Modificar apenas a cadeia User-Agent não oculta sua identidade e frequentemente cria "contradições entre camadas" evidentes que acionam motores avançados de detecção de fraudes: primeiro, conflito entre camada de aplicação e camada de transporte — se você alterar o UA no Windows para fingir ser um iPhone Safari, os cabeçalhos HTTP declararão Apple, mas os pacotes TCP SYN apresentarão a assinatura do kernel do Windows (sem opção TS, ordem MSS, NOP, WS, NOP, NOP, SACK_PERM), contradizendo diretamente a ordem canônica de 8 opções da Apple. Segundo, invariantes de protocolo em HTTP/3 e HTTP/2 — os motores Chromium, WebKit e Gecko possuem comportamentos intrínsecos difíceis de forjar, como o mapeamento de fluxos unidirecionais HTTP/3 (Chromium: 2:control,10:encoder vs WebKit: 2:control,6:encoder) e a ordem de pseudo-cabeçalhos HTTP/2 (Chromium: m,a,s,p vs não-Chromium: m,s,a,p). Mudar o cabeçalho superficial expõe imediatamente a discrepância com a rede inferior.

💡 Confira os detalhes da sua assinatura na camada de transporte na Análise de Anonimato de Proxy.

Navegadores anti-detect modificam o Chromium ou injetam hooks em JavaScript para sobrescrever propriedades do objeto navigator, adicionar ruído às saídas de Canvas/WebGL e simular resoluções de tela e áudio. No entanto, sistemas avançados detectam anomalias facilmente: primeiro, vestígios de hooking em protótipos e funções nativas — modificações em JS costumam alterar o comportamento de Function.prototype.toString, descritores de propriedade ou a cadeia de protótipos nativa. Segundo, invariantes de GPU e sombreadores — embora o ruído altere o hash da imagem, a precisão de ponto flutuante da GPU física e as características de rasterização permanecem inalteradas, e o padrão do ruído adicionado pode ser identificado. Terceiro, pilha de rede inalterada — a maioria das ferramentas foca apenas na camada JS do navegador, deixando a pilha TCP/TLS do sistema operacional subjacente exposta e contraditória.

Não, não impede. O modo anônimo foi projetado exclusivamente para impedir que o histórico de navegação, cookies e dados de formulários fiquem salvos no dispositivo local após o fechamento da janela; ele não protege contra o rastreamento remoto por servidores. O fingerprinting do navegador é obtido por scripts JavaScript que consultam características físicas de hardware e renderização (como desempenho da GPU, precisão de shaders WebGL, fontes instaladas, resposta de osciladores de áudio, núcleos de CPU e profundidade de cor). Como o hardware físico, os drivers e o motor do navegador permanecem exatamente os mesmos no modo anônimo, o hash de fingerprint calculado pelo servidor remoto é idêntico ao da navegação normal.

Não se trata de um falso positivo, mas de uma característica fundamental da plataforma iOS: primeiro, diretrizes da Apple App Store — a Apple exige que todos os navegadores web no iOS/iPadOS (incluindo Google Chrome, Microsoft Edge, Mozilla Firefox e Opera) utilizem obrigatoriamente o motor de renderização WebKit / WKWebView fornecido pelo sistema, proibindo o uso dos motores Chromium Blink ou Gecko. Segundo, validação em nível de protocolo — o Chrome no iOS (CriOS), ao negociar conexões HTTP/3, emite o mapeamento de fluxos unidirecionais característico do WebKit (2:control,6:encoder), e não o padrão do Chromium (2:control,10:encoder). Portanto, o Chrome no iOS é essencialmente um navegador WebKit com interface do Google, tornando a identificação como WebKit tecnicamente precisa.

Sim, mas sob condições estritas e limites claros, e isso não tem qualquer relação com uma autenticação de usuário. A recuperação de identidade neste site utiliza um modelo ponderado em quatro camadas: 1) Camada de ancoragem de hardware (identificação do modelo da GPU, latência base do áudio, contagem de dispositivos de mídia); 2) Camada de alta entropia do sistema (lista de fontes instaladas, vozes de síntese de fala); 3) Camada mutável do navegador (hash de renderização Canvas, hash de cálculo do AudioContext); 4) Camada do ambiente de exibição (resolução de tela, fuso horário). Após a soma das quatro camadas, ambas as seguintes condições precisam ser satisfeitas em simultâneo para validar uma identidade: pontuação total acima do limiar e correspondência de pelo menos uma característica essencial de alta entropia (fontes, vozes, Canvas ou Audio). Esta segunda condição foi adicionada deliberadamente: atributos públicos de baixa entropia como modelo de GPU, fuso horário e resolução repetem-se em larga escala em aparelhos semelhantes e sob hipótese alguma podem formar uma identidade por si sós; versões anteriores sem essa trava poderiam associar equivocadamente dois usuários desconhecidos. Além disso, a camada de ancoragem de hardware impõe um veto absoluto: núcleos lógicos de CPU divergentes, memória RAM com diferença superior a 4GB, latência base de áudio com variação acima de 0.005 segundos ou divergência de toques simultâneos máximos desqualificam o candidato de imediato sem cálculo de pontuação.

⚠ O propósito deste mecanismo é alinhar com estabilidade observações repetidas do mesmo dispositivo, e não atestar a identidade civil de quem o opera — não constitui autenticação e jamais deve ser empregado para tal finalidade.

Ambas pertencem às «características de alta entropia do sistema», não demandam autorizações e processam-se de forma imperceptível e silenciosa. Impressão digital de AudioContext: conecta um oscilador (Oscillator) a um compressor dinâmico (DynamicsCompressor) em um OfflineAudioContext para processar um sinal de áudio em segundo plano, extraindo valores de ponto flutuante para geração de hash. O mesmo gráfico de áudio gera minúsculas discrepâncias no bit menos significativo entre implementações de navegadores, bibliotecas matemáticas e arquiteturas de ponto flutuante, sem reproduzir qualquer som. Totalmente à parte e independente está o AudioContext.baseLatency: expressa o tamanho do buffer de saída determinado pela placa de som e drivers; nós o adotamos como âncora de hardware (uma diferença superior a 0.005 segundos desclassifica a correspondência) e não como hash de identidade. Impressão digital de enumeração de fontes: afere sistematicamente a largura e a altura de um texto renderizado com cada fonte da lista em comparação com as fontes de contingência; variações comprovam que a fonte está presente no sistema. O catálogo tipográfico reflete os programas instalados no computador (Office, softwares Adobe, ferramentas de desenvolvimento, métodos de entrada), tornando a relação de fontes o dado individual com maior poder de distinção de todo o conjunto de características.

💡 A discrepância na estabilidade decorre da origem das modificações: os hashes de Canvas e Audio oscilam a cada atualização de versão do navegador (os motores de renderização e módulos matemáticos mudam continuamente), ao passo que a lista de fontes só é alterada quando você instala ou remove programas — razão pela qual possui o maior peso.

O MSS (Maximum Segment Size) corresponde à carga útil máxima por segmento TCP informada durante o handshake. Nosso servidor obtém essa métrica diretamente do seu pacote SYN sem exigir qualquer instalação ou ajuste de software. O acréscimo das sobrecargas dos cabeçalhos IP e TCP permite reconstituir o MTU do circuito: adicionar 40 bytes para IPv4, adicionar 60 bytes para IPv6. Os números usuais possuem significado técnico exato: 1500 indica conexões Ethernet padrão ou servidores em nuvem dedicados; 1492 refere-se ao tráfego PPPoE (banda larga residencial DSL / FTTH), onde os 8 bytes do cabeçalho PPPoE reduzem a carga útil; menor ou igual a 1420 evidencia uma camada extra de encapsulamento, comum em túneis VPN como WireGuard / Tailscale ou em encaminhamentos por CDN.

⚠ O fator crucial é: o MSS caracteriza a rota de conexão, não o dispositivo. Ele apenas acusa que existe encapsulamento no trajeto e isoladamente não confirma o uso de proxy (uma rede residencial PPPoE também não opera em 1500). O valor diagnóstico real repousa nas contradições: quando a localização informada na camada de aplicação diverge permanentemente do comportamento da camada de transporte (por exemplo, alegar conexão direta nativa enquanto o MSS permanece fixo na faixa típica de túneis). Consulte nossa Análise de Anonimato de Proxy para saber mais.

Este é o tipo de equívoco que combatemos com maior rigor (fusão indevida), e dispomos de três linhas sucessivas de contenção — se qualquer uma for acionada, a associação é descartada. A primeira é o isolamento estrito por compartimentos: os perfis são agrupados rigorosamente pela plataforma do sistema operacional e pelo motor do navegador, sem cruzamento entre grupos distintos. Dois navegadores com motores diferentes na mesma máquina física jamais serão agrupados em uma única identidade. A segunda é o veto da ancoragem de hardware: núcleos lógicos de CPU, capacidade de memória RAM (tolerância de 4GB), latência base de áudio (tolerância de 0.005 segundos) e número máximo de toques na tela excluem sumariamente o candidato antes da contagem de pontos se houver divergência além da margem. A terceira é o portão de admissão de características centrais: mesmo com pontuação composta elevada, se não houver confirmação de nenhuma característica central de alta entropia (fontes, vozes, Canvas, Audio), a associação é bloqueada — impedindo que dados comuns de baixa entropia atinjam pontuações indevidas.

⚠ Esclarecimento transparente: no momento não possuímos uma taxa de falsas fusões apurada sobre tráfego orgânico para divulgação pública. Esse indicador requer volumetria longitudinal de acessos reais; publicar estimativas antes de alcançar uma amostragem adequada configuraria conduta desprovida de rigor.