Se o proxy deixa ver o seu endereço real
O proxy muda o endereço a partir do qual o navegador acede aos sites. O WebRTC é um canal à parte para chamadas e vídeo, e consegue ligar-se diretamente, sem passar pelo proxy. Nesse caso o site obtém o seu endereço real a partir de JavaScript, num segundo e sem pedir licença.
Abra esta página no perfil que está a verificar e clique no botão.
Aqui é preciso um servidor de terceiros, e dizemo-lo sem rodeios. Na verificação da impressão digital, tudo era calculado no seu navegador. Aqui isso não é possível: o navegador só conhece o seu próprio endereço externo através de um servidor STUN — é exatamente essa a fuga que se está a verificar. O pedido vai para stun.cloudflare.com e stun.l.google.com; eles veem exatamente o que qualquer site com chamadas veria. Não guardamos o resultado.
Resultados
O que o navegador encontrou
| O que é | Endereço |
|---|
Como ler o resultado
Aqui há só uma comparação, mas é a que decide: o endereço a partir do qual o servidor STUN o vê, contra o endereço de onde sai o resto do tráfego.
Coincidem — o WebRTC segue o mesmo caminho que tudo o resto e não revela nada de novo. Não coincidem — o proxy foi contornado: o site fica a conhecer o seu endereço real, por mais que configure o proxy no perfil.
Mostramos à parte os endereços da sua rede doméstica. Por predefinição o Chrome esconde-os atrás de nomes aleatórios do tipo ….local — é a sua própria proteção, e funciona. Por si só esses endereços não o denunciam: 192.168.1.5 tem-no milhões de máquinas. Mas dizem ao site como está construída a sua rede, e isso é mais uma linha desnecessária no conjunto de dados.
Por que isto não se resolve com um parâmetro
É fácil perder tempo aqui, por isso dizemo-lo sem rodeios: a fuga só se resolve ajustando a política de WebRTC no próprio navegador. Um parâmetro de linha de comandos ao iniciar o Chrome não a fecha — nessa parte o navegador simplesmente não lhe dá ouvidos. Verificámos isto em perfis reais.
O ajuste existe, é próprio do navegador, mas chegar até ele à mão em cada perfil é um trabalho que ninguém vai repetir cem vezes seguidas.
Por isso no Morfiade isto liga-se sozinho assim que o perfil tem um proxy definido: se há proxy, o endereço deve estar escondido, e deixar o WebRTC contorná-lo não faria sentido. Não é preciso procurar uma opção à parte.
O que fazer se a verificação mostrar uma fuga
- Perfil sem proxy. Nesse caso está tudo bem: não há nada para esconder, o endereço já é seu. Isto só se torna uma fuga junto com um proxy.
- Há proxy, mas os endereços não coincidem. Significa que a política de WebRTC não está definida nesse perfil. No Morfiade basta atribuir um proxy ao perfil — o resto acontece sozinho.
- Extensão bloqueadora de WebRTC. Fecha a fuga, mas de forma abrupta: alguns sites com chamadas e vídeo deixam de funcionar, e o próprio facto de o «WebRTC estar desligado por completo» também é um indício, e bastante raro.
O que esta verificação não mostra
A fuga de DNS. É outro canal: os pedidos de nomes podem ir sem passar pelo proxy mesmo quando o próprio tráfego passa por ele. Aqui não a medimos, e não vamos fingir que medimos.
Se o país coincide com o fuso horário e o idioma. Isso está na verificação da impressão digital — na mesma página estão as três comparações que mais frequentemente levam a um captcha.
Mais uma vez: nesta página, «não há fuga» significa exatamente uma coisa — o WebRTC não informou um endereço diferente do endereço de saída. Não é uma avaliação geral do anonimato, e não desenhamos percentagens.
Verificação da impressão digital do navegador · O que é este programa · Abrir o bot