Recurso · WebRTC e identidade de rede
Um proxy decide por onde o tráfego de um Profile sai. O resto da identidade de rede é decidido pelo kernel: quais candidatos WebRTC uma página consegue ler, onde o DNS é resolvido e quais user agent e idiomas cada requisição carrega.
Identidade de rede é tudo o que um servidor pode aprender sobre um visitante pela conexão em vez de pela página: o IP que um candidato WebRTC revela, o resolvedor que responde ao DNS, os cabeçalhos user-agent e Accept-Language, e as requisições em segundo plano que um navegador faz por conta própria. Em um Profile lançado pela Agilelogin, cada um deles segue a configuração do Profile.
Quatro decisões tomadas por Profile.
Privacy, o padrão, só deixa o WebRTC sair pelo proxy, então uma página não recebe nem os endereços locais da máquina nem o IP público real. Replace IP reescreve o endereço que um site lê para o IP de saída fixo do proxy. Block connections interrompe o WebRTC por completo. O kernel mantém dois valores legados, Forward STUN e Allow, para Profiles existentes e depuração; um Profile novo não pode selecioná-los.
Com um proxy vinculado, o kernel desliga e trava o DNS-over-HTTPS, então as consultas de nome não vão para um resolvedor público fora da rota do Profile.
O user agent, seus Client Hints e a lista Accept-Language do fingerprint são enviados em cada requisição, inclusive nas do próprio kernel em segundo plano, e a lista de idiomas não é reduzida a uma única entrada.
Um Profile lançado pela Agilelogin não busca a lista de contas do Google, sugestões nem conteúdo de nova aba ao iniciar, não tem login no navegador e envia pelo proxy uma requisição mínima de atualização de componentes.
O editor recusa as combinações que contradiriam o proxy; o resto é julgamento do operador.
| Assunto | Fronteira da Agilelogin | Ação do operador |
|---|---|---|
| Replace IP em um proxy rotativo | Recusado: o endereço reescrito ficaria obsoleto assim que a saída mudasse | Mantenha Privacy, ou marque o proxy como saída fixa só se ele realmente for. |
| Forward STUN ou Allow em um Profile antigo | Valores legados: aparecem só em um Profile que já usa um deles; os dois expõem o endereço da própria máquina | Mude o Profile para Privacy e salve; depois disso, o valor legado não é mais oferecido. |
| Um site que roda o próprio servidor STUN ou TURN | Consegue distinguir o Replace IP; o Privacy não expõe nenhum endereço a ele | Prefira Privacy para sites que você não controla. |
A maioria dos Profiles nunca sai do padrão.
Para um Profile com proxy, Privacy não expõe nenhum endereço local ou público e ainda conecta pelo relay TURN TCP ou TLS de um site, que informa o IP de saída do proxy.
Se um site insiste em ler um endereço server-reflexive, vincule um proxy marcado como saída fixa e rode a verificação de saúde; o editor grava o IP de saída no lançamento.
A API continua chamável, mas nenhum candidato é produzido e nenhuma conexão TURN é aberta. Chamadas de vídeo não funcionarão.
O modo e o endereço de saída são lidos no lançamento e valem pela sessão; relance o Profile depois de mudar qualquer um dos dois.
O que o kernel não promete.
Privacy, que é o padrão. Ele produz o mesmo tratamento da política disable_non_proxied_udp do próprio Chrome: nenhum endereço local ou público é exposto, e sites que oferecem um relay TURN TCP ou TLS continuam conectando.
Com um proxy vinculado, o DNS-over-HTTPS é desligado e travado, então a resolução de nomes segue a rota do proxy em vez de um resolvedor público.
Não. O login no navegador é removido dos Profiles lançados pela Agilelogin, porque a reconciliação de contas que ele inicia contataria o Google a cada lançamento. Entrar em sites não é afetado.
Veja como um proxy é vinculado a um Profile e depois escolha o modo de WebRTC no editor de fingerprint.