Três modos de WebRTC e o que cada um mostra a um site

Pontos principais

• Uma página pode abrir uma tentativa de conexão WebRTC sem pedir permissão de câmera ou microfone, e a lista de candidatos que ela coleta pode conter um IP público real mesmo com o navegador atrás de um proxy.
• A Agilelogin oferece uma configuração por Perfil, webrtc.mode. O editor oferece três modos: privacy, replace e disable. O kernel mantém dois valores legados, forward_stun e allow, para Perfis existentes e depuração; um Perfil novo não pode selecioná-los.
• privacy é o padrão do produto desde 2026-07-27: nenhum candidato host ou server-reflexive vaza, o que corresponde ao que a própria política corporativa do Chrome chama de disable_non_proxied_udp.
• O editor recusa replace num proxy rotativo, e o legado forward_stun é recusado num Perfil com proxy, porque ambas dariam uma lista de candidatos que a atribuição de rede real não sustenta.
• O modo é lido uma vez na inicialização e permanece assim durante toda a sessão; ele não cobre todo caminho de WebRTC que uma página pode usar, e nenhum modo esconde o endereço real de um site que roda seu próprio servidor STUN.

O que um site aprende antes mesmo de pedir permissão

O WebRTC foi criado para que dois navegadores trocassem áudio, vídeo ou dados diretamente, sem que cada pacote passasse por um servidor. Para tornar essa conexão direta possível, cada lado precisa dizer ao outro como alcançá-lo, e essa negociação — o Interactive Connectivity Establishment, ou ICE — roda no momento em que uma página abre uma RTCPeerConnection, antes mesmo de qualquer prompt de permissão de câmera ou microfone aparecer. Uma RTCPeerConnection com um único canal de dados já é suficiente para disparar isso, e o site não precisa que o usuário aceite nada.

O ICE reúne o que chama de candidatos, e uma página que escuta eventos icecandidate pode coletar todos eles. Um candidato host descreve um endereço na própria interface de rede da máquina; o Chromium moderno esconde o endereço real atrás de um nome mDNS .local gerado aleatoriamente, em vez de expor diretamente um IP de rede local. Um candidato server-reflexive (srflx) é o que um servidor STUN diz ao navegador sobre como seu endereço parece de fora — normalmente o IP público real, descoberto independentemente de o restante do tráfego estar ou não atrás de um proxy, porque o tráfego STUN não precisa passar por um proxy HTTP da mesma forma que as requisições de página passam. Um candidato relay, quando o TURN entra em jogo, é um endereço num servidor de retransmissão pelo qual o tráfego realmente passa. Juntando tudo, esse é o conhecido caminho de “vazamento de WebRTC”: um navegador pode estar roteando seu tráfego HTTP por um proxy enquanto seus candidatos ICE ainda entregam ao site o IP público por trás disso.

Três modos e dois valores legados, lado a lado

A Agilelogin expõe exatamente uma configuração que governa tudo isso, webrtc.mode, definida por Perfil. O editor oferece três dos seus valores: Privacy (privacy), Replace IP (replace) e Block connections (disable). Os outros dois, allow e forward_stun, são valores legados que o kernel mantém para Perfis existentes e depuração. O editor só mostra um deles num Perfil que já o usa, então um Perfil novo não pode selecionar nenhum dos dois. A tabela lista os cinco valores do kernel:

allow é o comportamento nativo do Chromium, sem qualquer alteração: nada na coleta de candidatos é tocado. disable vai o mais longe possível na direção oposta — nenhum candidato de qualquer tipo chega à página, e nenhuma conexão TURN chega a ser aberta, embora o próprio objeto RTCPeerConnection continue existindo e um script ainda possa construí-lo; a página não tem como perceber, pela forma como chama a API, que ela está sendo deliberadamente contida. forward_stun e replace visam especificamente o candidato srflx: o primeiro deixa passar o endereço real, o segundo o reescreve para o IP de saída do proxy daquele Perfil antes que a página o veja.

Por que privacy é o padrão

privacy fica entre os dois extremos por design — está escrito explicitamente em todo modelo de Perfil desde 2026-07-27. Ele suprime totalmente tanto os candidatos host quanto os server-reflexive — sem nome mDNS, sem IP real via STUN — enquanto ainda permite que um candidato relay se forme se o servidor TURN do próprio site rodar sobre TCP ou TLS, caso em que o endereço que a página vê é o IP de saída do proxy, não o da máquina. Esse não é um comportamento inventado: é exatamente o efeito que a política corporativa do Chrome documenta sob WebRTCIPHandlingPolicy quando definida como disable_non_proxied_udp — o padrão da Agilelogin corresponde a um modo que o próprio Chrome já oferece para implantações gerenciadas, só que aplicado por Perfil em vez de por máquina.

O raciocínio por trás de torná-lo padrão é consistência, não ocultação. Um Perfil que já tem um proxy atribuído para seu tráfego HTTP e sua fingerprint de navegador deveria mostrar ao site a mesma identidade de rede em todo lugar onde essa identidade é checada, WebRTC incluído — um operador rodando vários Perfis lado a lado quer que cada um pareça um ambiente coerente e autoconsistente, não um em que a barra de endereço diz um país e o candidato WebRTC diz outro. Essa consistência importa igualmente quando um Perfil é conduzido por um fluxo de automação em vez de uma pessoa clicando manualmente, já que um script não tem como perceber sozinho que um sinal está discretamente em desacordo com o resto.

Duas combinações que o editor recusa

Os dois valores que mexem no candidato server-reflexive vêm, cada um, com uma trava. forward_stun expõe o IP público real de propósito; um Perfil novo não pode selecioná-lo, e o editor de Perfil o recusa num Perfil com proxy atribuído; forçar a saída do IP real via WebRTC enquanto todo outro sinal vem de um proxy simplesmente recriaria o próprio vazamento que o resto da configuração existe para fechar.

A trava do replace é mais estreita: ele é recusado num Perfil que usa proxy rotativo. Reescrever o candidato srflx para “o IP de saída do proxy” só faz sentido se esse IP de saída for um valor fixo e conhecido ao qual toda a sessão possa se ancorar; um proxy rotativo não tem esse valor. E mesmo num proxy estático, se o kernel ainda não souber o IP de saída daquele proxy no momento em que o ICE coleta os candidatos, replace recua para se comportar como privacy, em vez de entregar um endereço desatualizado ou errado — um palpite não reescrito é pior do que nenhum candidato.

O que esses modos não cobrem

webrtc.mode é lido uma única vez, por um canal stdin privado, quando o kernel inicializa um Perfil — ele não pode ser alterado enquanto essa instância do navegador continua rodando, então um Perfil que precisa de um modo diferente precisa de um reinício, não de uma troca em tempo real. Para replace e forward_stun, os valores reescritos ou encaminhados permanecem consistentes em todo lugar onde uma página poderia tentar checá-los — RTCPeerConnection.getConfiguration(), icecandidateerror.url, e as URLs de candidatos expostas em getStats() e eventos de iceTransport concordam com o que de fato saiu. Isso fecha a checagem cruzada óbvia que uma página poderia tentar fazer, mas tem um limite rígido: um site que roda seu próprio servidor STUN vê o endereço de onde cada requisição de fato chegou, e pode compará-lo com o candidato entregue à página. replace não consegue mudar o que esse servidor observa. É um controle de privacidade e consistência para a visão do lado da página, nada mais.

Vale nomear diretamente mais dois limites em vez de deixar por isso mesmo. O comportamento de candidatos IPv6 não foi verificado separadamente para nenhum valor de webrtc.mode, então este texto não afirma nada sobre isso em qualquer direção. E esses modos não governam toda superfície relacionada a WebRTC que o Chromium expõe — existe no kernel uma API RtcTransport mais nova, totalmente fora do alcance do webrtc.mode, embora ela não esteja exposta nas versões de release atuais, então hoje não é um caminho que uma página consiga alcançar. Tudo isso é comportamento documentado do kernel Polychrome, medido no build M150; ainda não existe um download público do aplicativo desktop, então trate este texto como uma descrição do que o kernel faz hoje, não como um recurso para experimentar numa versão já lançada.