Fugas WebRTC
Teste de fugas WebRTC: o que uma chamada no browser revela sobre o seu endereço IP
Faz parte de: As chamadas VoIP são seguras? O que uma chamada no browser protege e o que expõe
Adicionar o callfrombrowser.org como fonte preferida no Google
Em resumo
Um teste de fugas WebRTC lista todos os endereços IP que o browser entrega a uma página web através do WebRTC, para que possa detetar algum que queria esconder, normalmente o endereço do seu fornecedor de internet com uma VPN ativa [1]. Uma chamada no browser para um número de telefone mostra o seu IP ao serviço de chamadas, não à pessoa para quem liga, que recebe uma identificação de chamada [2]. O teste é uma das verificações de privacidade e segurança que sugiro antes de fazer chamadas a partir do browser.
Factos principais
- As regras do IETF para o WebRTC dizem que uma VPN com split tunneling pode deixar o WebRTC descobrir o endereço público do seu fornecedor de internet, além do da VPN [1]. Verificado em .
- Na minha verificação local no Chrome 156, uma página sem permissão de microfone só via o meu computador como um nome .local aleatório; com o microfone autorizado, obteve o meu endereço local real [3][1]. Verificado em .
- O Messenger diz que as chamadas individuais partilham o seu endereço IP com o dispositivo da outra pessoa [4]; a opção «Proteger endereço IP nas chamadas» do WhatsApp faz passar as chamadas pelos servidores do WhatsApp [5]. Verificado em .
O que é uma fuga WebRTC?
Antes de uma chamada WebRTC, o browser recolhe as rotas de rede possíveis, chamadas candidatos ICE, e entrega-as à página web para que as passe ao outro lado. Cada uma traz um endereço IP, ou um nome .local aleatório em vez de um endereço local escondido. Um site comum só vê o endereço público de onde veio o pedido; através do WebRTC, uma página pode ficar a saber mais [1]. Uma fuga é qualquer endereço dessa lista que não queria partilhar.
O resto do percurso de uma chamada está em WebRTC, SIP e a rede telefónica; para as fugas, só interessa a lista de candidatos. A MDN nota que os endereços dessa lista ficam sempre expostos à página [6].
| Tipo de candidato | Endereço que mostra | Risco para a privacidade |
|---|---|---|
| host | O endereço do seu dispositivo na rede local, ou um nome aleatório terminado em .local se o browser o esconder [7][3] | Menor do que um endereço público, mas o IETF considera os endereços IPv4 privados uma superfície de fingerprinting bastante significativa [1] |
| srflx (server reflexive) | O endereço público que o seu router ou a sua VPN mostra a um servidor STUN [7] | Alto, se for o endereço do seu fornecedor com uma VPN ativa [1] |
| relay | Um endereço num servidor TURN que retransmite o áudio e o vídeo [7] | Baixo: o outro lado vê o endereço do relay, não o seu [6]; o operador do relay continua a vê-lo a si |
O IETF considera o caso da VPN o mais significativo, porque há quem use uma VPN para se manter anónimo [1]. Os outros dois casos são o seu endereço privado e um proxy que as verificações do WebRTC contornam, o que revela o seu verdadeiro endereço público [1].
Uma chamada no browser expõe o seu endereço IP?
Ao serviço de chamadas, sim: todos os sites veem o seu endereço público [1], e uma chamada acrescenta uma ligação multimédia aos servidores do serviço. A quem atende num telefone fixo ou num telemóvel, não: a chamada sai da internet no gateway do fornecedor [8], e a rede telefónica transmite o número de quem liga, não um endereço IP [2]. As chamadas entre apps podem ligar dois dispositivos diretamente.
| Tipo de chamada | O serviço | A pessoa para quem liga |
|---|---|---|
| Do browser para um número de telefone (Google Voice, TwinPhone, Yolla) | Sim: gere a ligação multimédia | Não: vê uma identificação de chamada [2] |
| Marcadores web grátis (Call2Friends, Globfone) | Sim: o Call2Friends limita as chamadas grátis por endereço IP, e a política de privacidade do Globfone inclui os endereços IP entre os dados técnicos e registos que trata [9][10] | Não: vê uma identificação de chamada |
| Messenger, chamada individual | Sim | Sim: a Meta diz que o seu IP é partilhado com o outro dispositivo [4] |
| Sim | Pode ver, a menos que a opção «Proteger endereço IP nas chamadas» esteja ativa; as chamadas de grupo passam sempre por um relay [5] | |
| Telegram | Sim | Pode ver: o anúncio do Telegram de 2017 diz que as chamadas são peer-to-peer sempre que possível [11] |
Nas chamadas para números reais, a questão é o que o serviço fica a saber e guarda; o que a pessoa para quem liga vê está explicado em que número aparece quando liga a partir do browser.
Como fazer um teste de fugas WebRTC
Uma página de teste de fugas faz o mesmo que um marcador antes de uma chamada: abre uma ligação WebRTC, pergunta a um servidor STUN que endereço público vê e mostra cada candidato ao lado do endereço que ela própria vê por HTTP simples. Faça o teste em cada browser que usa para ligar, primeiro com a VPN desativada e depois com ela ativa.
- VPN desativada: abra uma página de teste de fugas, como o WebRTC Leak Test do BrowserLeaks. «Your Remote IP», no topo, e «Public IP Address», em «Your WebRTC IP», devem coincidir.
- VPN ativa: recarregue a página. «Your Remote IP» deve agora mostrar o endereço da VPN.
- Se a secção WebRTC continuar a listar o endereço do seu fornecedor, o WebRTC está a contornar o túnel [1].
- Uma entrada local terminada em .local significa que o endereço está escondido [3]; uma entrada em bruto a começar por 192.168. ou 10. não está.
- Se a página oferecer uma verificação do microfone, autorize-a e volte a testar: um marcador precisa de acesso ao microfone, e essa permissão pode desbloquear mais endereços [1]. Depois, retire a permissão nas definições do site [12].
O que mudou no Chrome depois de autorizar o microfone
Em , carreguei uma página de teste local no Chrome 156 num Mac, sem servidor STUN, por isso nenhum endereço foi enviado para um servidor externo. Sem permissão de microfone, a página viu um único candidato host, com um nome formado por uma sequência aleatória terminada em .local [3]. Com o microfone autorizado, recebeu o meu endereço IPv4 local real.
Isto segue a norma, que só permite a lista completa de endereços com consentimento, como a permissão de microfone [1]; o WebKit, o motor do Safari, descreveu a mesma regra em 2017 [13]. Assim, um marcador que autorize pode ver o seu endereço local: um risco menor do que o do seu endereço público [1].
Definições do browser que limitam as fugas WebRTC
O Brave documenta uma definição de IP do WebRTC para os utilizadores. A Google documenta os controlos do Chrome para extensões e administradores, e a Microsoft documenta os do Edge como política de administrador. O Firefox esconde os endereços locais por predefinição e mantém um interruptor para o desativar em about:config. Há uma regra que vale para todos: desativar o WebRTC também impede os marcadores no browser de funcionar, porque é o WebRTC que transporta a chamada [14].
| Browser | Controlo | O que muda | Efeito nas chamadas no browser |
|---|---|---|---|
| Brave | WebRTC IP handling policy nas definições de privacidade, segundo a wiki do Brave (editada pela última vez em 2018) [15] | A opção Default Public Interface Only não expõe nenhum endereço local [15] | O áudio e o vídeo podem passar a ir por um servidor relay [1] |
| Chrome | As extensões podem definir uma política de tratamento de IP do WebRTC [16]; os administradores podem definir a política WebRtcIPHandling [17] | Consoante o valor, deixa de usar endereços privados ou só envia o áudio e o vídeo através de um proxy [17] | Os valores só com proxy podem passar o áudio para TCP, o que, segundo o IETF, reduz a qualidade [1] |
| Edge | Política de administrador WebRtcLocalhostIpHandling [18] | Dois dos seus valores deixam de expor o endereço IP local [18] | Como no Chrome |
| Firefox | Endereços locais escondidos por predefinição [19]; media.peerconnection.enabled em about:config [20] | Definir essa preferência como false desativa o WebRTC | Os marcadores no browser deixam de funcionar |
| Safari | Regra integrada | As páginas sem acesso ao microfone ou à câmara não recebem endereços host, tal como o WebKit o descreveu em 2017 [13] | Nenhum |
O que uma VPN muda nas chamadas no browser
Uma VPN que envia todo o tráfego pelo seu túnel, incluindo o WebRTC, mostra ao serviço de chamadas o endereço da VPN em vez do seu. Uma VPN com split tunneling pode também deixar o WebRTC encontrar o endereço do seu fornecedor [1], daí o teste de fugas com a VPN ativa. E uma VPN também tem efeitos secundários nas chamadas.
- Alguns serviços restringem as VPN: os termos do TextNow dizem que pode limitar ou restringir a sua utilização [21].
- Alguns marcadores grátis racionam as chamadas grátis por endereço IP, como faz o Call2Friends [9], por isso, numa VPN, pode partilhar essa quota com outros utilizadores do mesmo endereço de saída.
- Forçar o áudio e o vídeo a passar por um proxy que não transporta UDP leva o áudio para TCP, o que, segundo o IETF, reduz a qualidade [1].
- O serviço continua a ver a sua conta e os registos de chamadas; a Google, por exemplo, pode registar os números, a hora e a duração das chamadas [22].
Como manter o seu endereço IP privado nas chamadas
Escolha a solução conforme a chamada. Nas chamadas para números de telefone, a pessoa para quem liga não recebe o seu IP, por isso escolha um serviço a quem confie esse dado e verifique a VPN. Nas chamadas entre apps, o outro dispositivo pode ligar-se diretamente ao seu, por isso use a opção de relay da app, se existir.
- Chamadas no browser: faça o teste de fugas com a VPN ativa; no Brave, escolha Default Public Interface Only [15].
- Microfone: nos marcadores que usa uma única vez, dê a permissão com «Permitir desta vez» [12]; na minha verificação no Chrome, uma página com essa permissão conseguia ver o endereço local.
- WhatsApp: ative «Proteger endereço IP nas chamadas». A página de ajuda abrange Android, iOS e Mac, não a versão web, e avisa que as chamadas retransmitidas podem perder alguma qualidade [5].
Perguntas frequentes
O que é um teste de fugas WebRTC?
Um teste de fugas WebRTC é uma página web que executa a mesma configuração de ligação de uma chamada no browser e lista todos os endereços IP que o browser oferece, ao lado do endereço que a página vê por HTTP comum. Se o endereço do seu fornecedor aparecer nessa lista com uma VPN ativa, o WebRTC está a contornar o túnel [1]; um nome .local aleatório significa que o seu endereço local está escondido [3].
A pessoa para quem ligo a partir do browser consegue ver o meu endereço IP?
Não, numa chamada para um telefone fixo ou um telemóvel. O fornecedor transforma o áudio do browser numa chamada telefónica no seu gateway [23], e a rede telefónica transmite o número de quem liga, não um endereço IP [2]. As chamadas entre apps são diferentes: o Messenger diz que as chamadas individuais partilham o seu IP com o dispositivo da outra pessoa [4].
Uma VPN impede as fugas WebRTC?
Uma VPN que encaminha todo o tráfego pelo seu túnel, incluindo o WebRTC, impede. Uma VPN com split tunneling pode não impedir, porque o WebRTC consegue descobrir o endereço público do seu fornecedor ao lado do da VPN [1]. A única forma de saber é um teste de fugas com a VPN ativa, em cada browser que usa, repetido depois de cada atualização.
Uma fuga do endereço IP local é perigosa?
Menos do que uma fuga do endereço público. Um endereço privado como 192.168.1.20 não diz onde está, mas o IETF considera os endereços IPv4 privados uma superfície de fingerprinting bastante significativa, capaz de associar sessões normais e de navegação privada no mesmo dispositivo [1]. O Firefox esconde os endereços locais por predefinição [19], o Safari esconde-os das páginas sem acesso ao microfone ou à câmara [13], e o Chrome também o fez na minha verificação.
A navegação anónima ou privada impede as fugas WebRTC?
Não. O IETF nota que um endereço privado revelado através do WebRTC pode funcionar como identificador e mostrar a um site que uma janela normal e uma janela de navegação privada estão no mesmo dispositivo [1], por isso o modo privado, por si só, não o esconde. Use as definições do browser indicadas acima e faça também um teste de fugas numa janela privada.
As extensões contra fugas WebRTC funcionam?
Em parte. No Chrome, uma extensão pode definir a política de tratamento de IP do WebRTC do browser, que a Google descreve como um compromisso entre o desempenho multimédia e a quantidade de informação sobre endereços locais exposta [16]. Consoante o valor, isso esconde os endereços locais ou obriga o áudio e o vídeo a passar por um proxy, o que pode levar o áudio para TCP e reduzir a qualidade [1]. Depois de instalar uma, faça um teste de fugas para confirmar a alteração.
Como desativo o WebRTC no Firefox?
Escreva about:config na barra de endereço, procure media.peerconnection.enabled e defina-o como false. O código-fonte da Mozilla descreve essa preferência como o interruptor do RTCPeerConnection, e desativá-la também retira às páginas o acesso à API do microfone [20]. Todos os marcadores no browser deixam então de funcionar, por isso a maioria das pessoas fica melhor servida com a predefinição do Firefox, que já esconde os endereços locais [19].
Como evitar fugas de WebRTC no Chrome?
Através de uma extensão ou de uma política, porque a Google documenta os controlos de endereços WebRTC do Chrome para essas duas vias. Uma extensão pode definir a política de tratamento de IP do WebRTC [16], e os administradores podem definir WebRtcIPHandling, cujo valor default_public_interface_only impede o WebRTC de usar endereços privados [17]. Na minha verificação no Chrome, uma página sem permissão de microfone já só via um nome .local aleatório [3]. Atrás de uma VPN, a verdadeira solução é um túnel que transporte todo o tráfego [1]. Qualquer coisa que bloqueie o WebRTC por completo também impede as chamadas no browser [14].
Um site pode ver o meu IP através do WebRTC sem pedir autorização?
O seu endereço público, sim, mas os sites veem-no de qualquer forma: o Safari, por exemplo, só dá às páginas sem acesso ao microfone endereços que um site já poderia obter [13]. O problema é um proxy no browser. Se o acesso direto à internet for permitido, as verificações STUN do WebRTC podem contornar o proxy e revelar o seu verdadeiro endereço público [1]. Os endereços locais estão mais protegidos: a norma associa a lista completa a um consentimento como a permissão de microfone [1], e na minha verificação no Chrome uma página sem essa permissão só via um nome .local aleatório [3].
Pergunte à IA sobre esta análise
Cada botão abre o assistente num novo separador e pede-lhe que resuma esta página, com uma ligação para ela como fonte.
Fontes
- RFC 8828: WebRTC IP Address Handling Requirements · IETF (RFC Editor) · verificado a 1 de novembro de 2026
- 47 CFR 64.1601 -- Delivery requirements and privacy restrictions | eCFR · US Code of Federal Regulations (eCFR) · verificado a 1 de novembro de 2026
- Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-mmusic-mdns-ice-candidates) · IETF (Internet-Draft, work in progress) · verificado a 1 de novembro de 2026
- Voice call someone or a group on Messenger - Messenger Help Center (Computer) · verificado a 1 de novembro de 2026
- How to protect your IP address on WhatsApp calls | WhatsApp Help Center · WhatsApp · verificado a 1 de novembro de 2026
- RTCIceCandidate: address property - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado a 1 de novembro de 2026
- RTCIceCandidate: type property - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado a 1 de novembro de 2026
- Make calls | Sonetel help · verificado a 1 de novembro de 2026
- Free call | Call2Friends - Online call · verificado a 1 de novembro de 2026
- Privacy Policy | Globfone · verificado a 1 de novembro de 2026
- Voice Calls: Secure, Crystal-Clear, AI-Powered | Telegram Blog (30 March 2017) · Telegram · verificado a 1 de novembro de 2026
- Use your camera and microphone in Chrome - Computer - Google Chrome Help · Google · verificado a 1 de novembro de 2026
- A Closer Look Into WebRTC | WebKit (3 July 2017) · WebKit (Apple) · verificado a 1 de novembro de 2026
- WebRTC API - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado a 1 de novembro de 2026
- WebRTC Custom Settings · brave/brave-browser Wiki · Brave Software (official GitHub wiki) · verificado a 1 de novembro de 2026
- chrome.privacy | API | Chrome for Developers · Google (Chrome for Developers) · verificado a 1 de novembro de 2026
- Chrome Enterprise policy list: WebRtcIPHandling (WebRTC IP handling) · Google (Chrome Enterprise) · verificado a 1 de novembro de 2026
- Microsoft Edge Browser Policy Documentation WebRtcLocalhostIpHandling | Microsoft Learn · Microsoft · verificado a 1 de novembro de 2026
- Firefox source: modules/libpref/init/all.js (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · verificado a 1 de novembro de 2026
- Firefox source: modules/libpref/init/StaticPrefList.yaml (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · verificado a 1 de novembro de 2026
- Terms of Use – TextNow · verificado a 1 de novembro de 2026
- Privacy Policy – Privacy & Terms – Google · Google · verificado a 1 de novembro de 2026
- Call From Your Browser Without a SIM Card - TwinPhone · verificado a 1 de novembro de 2026