Android 17 esconde os sites da operadora? O que ECH, rede local e bloqueio de 2G realmente fazem

Resposta curta: o Android 17 pode esconder da operadora e de outros observadores da rede o domínio específico que um app acessa, mas isso não acontece em toda conexão nem transforma o celular em anônimo. O ECH depende do app usar uma pilha de rede compatível, do servidor aceitar ECH e de o app estar no novo alvo de API; além disso, DNS criptografado continua importante para evitar que o nome do domínio apareça antes mesmo da conexão TLS.

As outras novidades seguem lógicas diferentes. A proteção de rede local passa a exigir permissão para apps que miram a API 37; a transparência de certificados fica ligada por padrão para esses apps; e a desativação automática de 2G só acontece quando a operadora participa e o aparelho oferece o suporte necessário. Ou seja: não existe um único “modo privado do Android 17” que cubra tudo.

O que muda na prática

Proteção	Ameaça principal	Quando funciona	Ação do usuário	Limitação importante
ECH	Exposição do domínio no início da conexão HTTPS/TLS	Android 17/API 37, app e biblioteca compatíveis, servidor com ECH e configuração adequada	Em geral, nenhuma; o suporte é definido pelo app e pelo servidor	Não esconde IP, volume de tráfego nem garante ECH em sites sem suporte
Proteção de rede local	Apps varrendo TVs, câmeras, PCs e outros dispositivos da mesma LAN	Obrigatória para apps que miram Android 17/API 37	Conceder acesso quando a função realmente exigir, ou usar seletor mediado pelo sistema	Apps legados que ainda miram SDK 36 ou anterior mantêm acesso implícito temporariamente
Certificate Transparency	Certificados fraudulentos ou emitidos indevidamente sem visibilidade pública	Ligada por padrão para apps que miram Android 17/API 37	Nenhuma na maior parte dos casos	Pode ser desativada pelo app e não é uma tecnologia para esconder sites visitados
Proteção 2G	Downgrade para 2G e uso de estações-base falsas/SMS blasters	Automaticamente apenas com operadoras participantes; manualmente em aparelhos compatíveis	Nenhuma se a operadora aplicar o padrão; caso contrário, procurar a proteção 2G nas configurações	Pode reduzir conectividade em locais ou roaming que ainda dependem de 2G

ECH esconde o domínio, não a conexão inteira

Mesmo com HTTPS, há dois momentos diferentes em que o nome de um site pode ficar exposto para quem transporta o tráfego. Primeiro vem a consulta de DNS, usada para descobrir o endereço IP. Depois, no handshake TLS tradicional, o campo SNI indica qual domínio o cliente quer alcançar. O Google explica que o ECH trabalha em conjunto com DNS privado: o DNS criptografado protege a consulta de nome, enquanto o Encrypted Client Hello protege o nome do servidor dentro do início da conexão TLS.

Isso significa que ECH não substitui DNS privado e DNS privado não substitui ECH. Se a consulta DNS estiver em claro, a operadora pode descobrir o domínio por esse caminho mesmo que o handshake use ECH. E, se apenas o DNS estiver criptografado, o SNI de uma conexão TLS sem ECH ainda pode revelar o domínio.

Também não é correto dizer que a operadora “não vê mais nada”. O endereço IP do servidor continua visível, assim como horário, duração e quantidade aproximada de dados transferidos. Em grandes CDNs, um mesmo IP pode hospedar muitos domínios e entregar pouca informação específica; em servidores dedicados a um único serviço, o IP ainda pode dar pistas. ECH reduz um vazamento importante de metadados, mas não é uma VPN nem uma promessa de anonimato.

Por que o ECH não funciona automaticamente em todo app do Android 17

A documentação de mudanças de comportamento do Android 17, atualizada em 28 de agosto de 2026, diz que o ECH é usado em conexões TLS de apps destinados ao Android 17, nível 37 da API, apenas quando a biblioteca de rede do app integrou o protocolo e o servidor remoto também o suporta. O desenvolvedor ainda pode alterar esse comportamento por domínio usando a configuração de segurança de rede.

Esse detalhe do targetSdkVersion é importante: instalar Android 17 no telefone não força todos os aplicativos antigos a adotar a nova proteção no mesmo dia. A plataforma oferece os recursos, mas o app precisa migrar para o alvo de API 37 e usar uma pilha que saiba aproveitar ECH.

Quais bibliotecas já entram nessa história

A página mais recente de mudanças do Android cita HttpEngine, WebView e OkHttp como exemplos de pilhas em que o suporte da biblioteca determina se ECH entra em ação. Para OkHttp há confirmação independente no próprio changelog: a versão OkHttp 5.5.0, lançada em 16 de agosto de 2026, adicionou suporte opt-in a ECH no Android 17.

Há uma pequena defasagem entre páginas oficiais: o guia dedicado “Adopting Encrypted Client Hello”, atualizado em 6 de agosto, ainda afirma que o suporte em OkHttp e HttpEngine “chegará em breve”. Já o changelog do OkHttp de 16 de agosto e o post do Google de 27 de agosto recomendam a versão 5.5.0 e a ativação do recurso. Para o estado atual, as fontes mais novas indicam que o OkHttp 5.5.0 já tem suporte opt-in.

Proteção de rede local: o app não deveria mapear sua casa sem necessidade

Antes dessa mudança, a permissão comum de internet podia permitir que um app conversasse com endereços da rede local. Isso abre usos legítimos, como encontrar uma TV para transmitir vídeo ou configurar um dispositivo de casa inteligente, mas também permite observar quais equipamentos existem na LAN e usar esse conjunto como sinal de identificação.

No Android 17, apps destinados à API 37 passam a ter a rede local bloqueada por padrão e precisam da permissão de execução ACCESS_LOCAL_NETWORK para comunicação ampla. A documentação da permissão de rede local esclarece que a restrição vale em baixo nível para conexões TCP, UDP, multicast e outras APIs construídas sobre a pilha de rede.

Para funções pontuais, o Android oferece uma alternativa melhor do que liberar toda a LAN: seletores mediados pelo sistema. Em um caso de transmissão, por exemplo, o usuário pode escolher uma TV específica sem dar ao app liberdade para vasculhar todos os dispositivos da casa.

O principal limite está nos apps antigos. Se um aplicativo ainda mirar SDK 36 ou anterior, o acesso local continua sendo concedido implicitamente por enquanto. Portanto, a atualização do sistema operacional não fecha de uma vez o acesso de todos os apps instalados.

Certificate Transparency não esconde a navegação

A transparência de certificados, ou CT, resolve outro problema. Quando um app abre uma conexão HTTPS, ele precisa confiar no certificado apresentado pelo servidor. Se uma autoridade certificadora for comprometida ou emitir algo indevido, um certificado fraudulento pode facilitar interceptação.

CT exige que certificados públicos sejam registrados em logs verificáveis, aumentando a chance de emissões suspeitas serem detectadas. No Android 17, a verificação de CT fica ativada por padrão para apps destinados à API 37. No Android 16, o recurso existia, mas precisava ser ativado pelo desenvolvedor.

Ela não registra “quais sites você visitou” em nome do usuário e não serve para esconder domínio da operadora. É uma camada de autenticidade e auditoria de certificados. O app também pode desativar CT globalmente ou por domínio; conexões com âncoras de confiança personalizadas têm tratamento próprio e podem não passar pela verificação padrão de CT.

Bloqueio de 2G: automático só se a operadora participar

O Android já oferece desde a versão 12 uma forma de desativar 2G no nível do rádio em aparelhos compatíveis. O objetivo é impedir que uma estação-base falsa force o telefone a abandonar 4G ou 5G e cair em uma rede 2G, cuja arquitetura tem proteções mais fracas.

A novidade do Android 17 é o caminho “zero clique”: segundo o anúncio de segurança do Google, operadoras participantes podem configurar o 2G como desativado por padrão para seus assinantes. Isso não significa que toda operadora do mundo, nem necessariamente toda linha brasileira, passará a bloquear 2G automaticamente. O anúncio não apresenta uma lista de operadoras participantes.

Quando o bloqueio automático não estiver aplicado, o usuário ainda pode procurar por Proteção de rede 2G nas configurações do SIM ou de segurança da rede móvel, se o aparelho implementar o recurso. A documentação do Android Open Source Project ressalta que a função depende de suporte do rádio, que chamadas de emergência continuam podendo usar 2G e que desativar a tecnologia pode causar perda de conectividade em locais ou situações de roaming que ainda dependam dela.

O que vale fazer como usuário

• Não trate Android 17 como garantia de ECH em toda navegação. A proteção depende do app, da biblioteca usada, do servidor e da configuração de DNS.
• Ao receber pedido de acesso à rede local, pense na função. Casting, automação residencial e configuração de IoT podem precisar; um app sem motivo claro para enxergar a LAN merece cautela.
• Não confunda CT com privacidade de destino. CT melhora a confiança nos certificados; ECH é que reduz a exposição do hostname no handshake.
• Confira a proteção 2G se o aparelho oferecer o controle. Em regiões onde 2G ainda é necessário para cobertura ou roaming, o custo pode ser ficar sem serviço até reativá-lo.

Então, o Android 17 esconde os sites da operadora?

Em conexões compatíveis, ele reduz de forma importante a capacidade da operadora de ver o domínio específico, mas não de forma universal. O melhor cenário combina DNS criptografado com ECH, app atualizado para a API 37, biblioteca de rede compatível e servidor com suporte ao protocolo. Mesmo nesse cenário, o IP e outros metadados da conexão continuam visíveis.

A leitura prática das quatro novidades é esta: ECH e CT são proteções da conexão que dependem do app e de sua pilha; a rede local passa a exigir consentimento amplo apenas para apps que migram ao novo alvo de API; e o bloqueio automático de 2G depende da operadora. A atualização do Android cria uma base mais segura, mas a adoção real continua distribuída entre sistema, desenvolvedor, servidor, hardware e operadora.