O GrapheneOS, sistema Android voltado à privacidade e conhecido por eliminar serviços do Google, mantém conexões de fundo ao domínio gstatic.com da empresa. A descoberta, detalhada pelo pesquisador Mike Kuketz em 26 de junho de 2026, revela que o tráfego serve para baixar listas de Certificate Transparency — uma camada de segurança de TLS — e não para rastreamento.
Conexão ao Google confirmada
Nas últimas semanas, usuários do GrapheneOS relataram em fóruns de tecnologia e em ferramentas de monitoramento como o RethinkDNS conexões inesperadas a gstatic.com, infraestrutura controlada pelo Google. O fenômeno ocorre sobretudo durante a inicialização do aparelho e ao iniciar o carregamento, levantando dúvidas entre quem migrou para o sistema justamente para evitar o ecossistema da companhia.
O pesquisador de segurança Mike Kuketz, do Kuketz IT-Security Blog, investigou o caso e publicou suas conclusões em 26 de junho de 2026. Segundo Kuketz, o tráfego não envolve telemetria, publicidade, Google Play Services nem sincronização oculta de dados. A origem é técnica: o Android, base do GrapheneOS, busca listas atualizadas de Certificate Transparency nos servidores do Google.
A própria equipe do GrapheneOS confirmou a explicação em seu fórum oficial e em publicações nas redes sociais. “Determinamos que as conexões servem para buscar listas assinadas de logs de certificate transparency para apps com o recurso ativado”, afirmou o projeto.
Como funciona a verificação
Certificate Transparency (CT) é um padrão aberto de segurança para certificados TLS, aqueles que protegem conexões HTTPS. O mecanismo cria logs públicos e verificáveis de todos os certificados emitidos por autoridades certificadoras, dificultando a emissão fraudulenta ou secreta de certificados — um vetor clássico de ataques de intermediário (man-in-the-middle).
Para validar certificados em conexões TLS, o Android precisa de listas atualizadas de logs de CT considerados confiáveis. É esse o motivo das requisições: o sistema baixa arquivos estáticos hospedados em gstatic.com. A documentação oficial do Android descreve a política de CT e os estados dos logs que determinam se um certificado é considerado compatível.
De acordo com a análise de Kuketz e as notas do GrapheneOS, o sistema recorre a cinco arquivos específicos hospedados no domínio do Google.
Arquivos baixados do gstatic
O tráfego observado corresponde a downloads de listas assinadas de logs de Certificate Transparency. A tabela abaixo lista os arquivos identificados pelo GrapheneOS:
| Arquivo em gstatic.com | Função |
|---|---|
| certificate_transparency/v2/log_list.json | Lista de logs de CT válidos (formato JSON, versão 2) |
| certificate_transparency/v2/log_list.sig | Assinatura criptográfica da lista v2 |
| certificate_transparency/v3/log_list.ctfb | Lista de logs de CT no formato ctfb (versão 3) |
| certificate_transparency/v3/log_list.sig | Assinatura criptográfica da lista v3 |
| certificate_transparency/log_list.pub | Chave pública usada na verificação das assinaturas |
Por que o IP vaza
Embora nenhum dado de aplicativo seja transmitido — as requisições são do tipo GET, estáticas, com User-Agent padrão e sem parâmetros de consulta —, toda conexão HTTPS revela inevitavelmente o endereço IP de origem e o momento exato da requisição. Para um sistema apresentado como blindagem contra o Google, essa exposição de metadados gera apreensão justificada entre os usuários.
Kuketz alerta ainda para um equívoco comum de interpretação. Ferramentas como o RethinkDNS costumam atribuir a conexão ao “Download Manager” ou ao “MTP Host”. O pesquisador explica que o Download Manager compartilha um identificador de usuário (UID) com vários componentes de mídia, o que provoca atribuições incorretas. A ligação ao gstatic.com, nesse caso, deriva da atualização das listas de CT, não de transferências de arquivos do próprio usuário.
Bloquear não é recomendado
A reação instintiva de muitos usuários é bloquear gstatic.com no firewall. Kuketz e o GrapheneOS desaconselham a medida. Após mais de 70 dias com listas desatualizadas, o Android deixa de impor a verificação de Certificate Transparency. O aparelho continua funcionando, mas perde uma camada extra de validação de certificados TLS.
Com a chegada do Android 17 — para o qual o GrapheneOS já prepara versão oficial, segundo o próprio projeto —, mais aplicativos devem adotar a checagem de CT por padrão. Bloquear o acesso, portanto, tende a enfraquecer a segurança justamente quando a função se torna mais relevante.
Solução própria já planejada
O GrapheneOS já estuda contornar a dependência. O plano é hospedar os cinco arquivos estáticos de CT em um domínio próprio, gstatic.grapheneos.org, funcionando como cache intermediário. Assim, os aparelhos deixarão de consultar diretamente a infraestrutura do Google para obter as listas.
A iniciativa segue a filosofia do projeto: sempre que o Android depende de endpoints estáticos do Google, o GrapheneOS os substitui por servidores próprios quando possível. O projeto avalia que o acesso direto não configura um problema prático de privacidade, mas opta por rotear o tráfego por sua própria rede.
Na avaliação de Kuketz, a explicação do GrapheneOS é coerente e transparente. Para o pesquisador, a vigilância dos usuários é legítima: quem escolhe um sistema centrado em privacidade deve exigir que toda conexão a infraestrutura do Google seja documentada e, sempre que possível, eliminada.
Leia também: Zero-day Android ativo: Google corrige 124 vulnerabilidades e falha no Teams Android permite leitura remota de memória.
Fontes
- Mike Kuketz, Kuketz IT-Security Blog — “GrapheneOS: Warum Android eine Verbindung zu gstatic.com aufbaut” (26 jun. 2026): kuketz-blog.de
- GrapheneOS — Documentação oficial sobre conexões padrão: grapheneos.org
- GrapheneOS Discussion Forum — Posicionamento sobre Certificate Transparency: discuss.grapheneos.org
- Google / Android Developers — Android Certificate Transparency Policy: developer.android.com