Olá a todos!
Disclaimer habitual antes de começar: não uso o Chrome. Isto não é mais um hit piece anti-Google nem estou aqui a evangelizar para largarem tudo e irem para o Lynx. Há comportamentos que não se podem desculpar, e o que vou descrever aqui é um deles.
Há duas semanas, escrevi aqui no blog sobre o caso da Anthropic — o ClaudeGate — onde o Claude Desktop instalava silenciosamente Native Messaging bridges em sete browsers Chromium sem pedir autorização a ninguém. Esse artigo era baseado no trabalho do Alexander Hanff, do That Privacy Guy, que é provavelmente uma das vozes mais rigorosas em privacidade e conformidade legal na Europa neste momento. Pois bem, o Hanff voltou a publicar. E desta vez o alvo é maior. Muito maior.
O artigo chama-se “Google Chrome silently installs a 4 GB AI model on your device without consent” e foi publicado a 4 de maio de 2026. E se o caso da Anthropic era preocupante, este é francamente assustador — não só pela escala, mas pelo que implica em termos ambientais.
Vamos a isto.
O que é que está a acontecer, concretamente?
O Google Chrome, nas versões recentes, está a descarregar silenciosamente um ficheiro de aproximadamente 4 GB para o disco dos utilizadores. O ficheiro chama-se weights.bin, está guardado numa pasta chamada OptGuideOnDeviceModel, e é nada mais nada menos do que os pesos do Gemini Nano — o modelo de linguagem on-device da Google.
Sem janela de confirmação. Sem checkbox nos Settings. Sem nenhum tipo de aviso. O Chrome decide que o teu hardware é elegível, faz download do modelo, e despeja-o no teu perfil de utilizador. E se tentares apagar o ficheiro? O Chrome volta a descarregá-lo. E se apagares outra vez? Volta a descarregar outra vez. O ciclo só pára se fores às chrome://flags e desactivares manualmente as funcionalidades de IA, ou se usares ferramentas de enterprise policy que um utilizador doméstico normal nunca viu na vida — ou, claro, se desinstalares o Chrome.
Isto não é teoria. Não é especulação. Há múltiplos relatos documentados de utilizadores Windows que descobriram o ficheiro quando o disco começou a ficar cheio. E o Hanff foi mais longe: verificou o comportamento numa máquina Apple Silicon, num perfil de Chrome criado de raiz, sem qualquer interação humana.
A verificação forense: como o Hanff provou o que aconteceu
E esta é a parte que me fez parar o que estava a fazer e ler o artigo inteiro de uma ponta à outra.
O Hanff criou um perfil Chrome no dia 23 de abril de 2026 para correr uma auditoria automatizada com o WebSentinel — a plataforma de auditoria forense dele. O driver da auditoria funciona inteiramente via Chrome DevTools Protocol: abre páginas, espera cinco minutos sem qualquer input, captura eventos, fecha o Chrome entre sites. Zero interação humana. Nenhuma funcionalidade de IA do Chrome foi tocada. Nenhuma superfície de UI foi acedida. O perfil era virgem em todos os sentidos.
Seis dias depois, ao fazer um du -sh de rotina no diretório do perfil, encontrou 4 GB de OptGuideOnDeviceModel.
Mas o Hanff não ficou por aí. Porque o macOS mantém um log de eventos do filesystem ao nível do kernel — o .fseventsd — que regista cada criação, modificação e eliminação de ficheiros, independentemente de qualquer aplicação. O Chrome não o pode editar, a Google não lhe pode aceder remotamente, e os registos sobrevivem à eliminação dos ficheiros que referenciam.
E os logs contam uma história muito clara:
No dia 24 de abril, às 16h38, o Chrome criou o diretório OptGuideOnDeviceModel. Às 16h47, três subprocessos de descompactação arrancaram em simultâneo — e um deles escreveu o weights.bin, o manifest.json e os ficheiros de configuração do modelo. O detalhe arrepiante é que o Chrome empacotou a instalação do modelo de IA juntamente com uma atualização de Certificate Revocation List e um preload de dados do browser — como se instalar 4 GB de um LLM no disco do utilizador fosse equivalente a uma atualização de segurança de rotina. Às 16h53, o ficheiro foi movido para a localização final.
Tempo total de instalação: 14 minutos e 28 segundos. Ação humana durante esse período: zero. O driver de auditoria estava literalmente a esperar que um timer de cinco minutos expirasse numa tab qualquer.
E há mais evidência. O ficheiro Local State do Chrome para aquele perfil contém um bloco optimization_guide.on_device com o resultado da validação do modelo, a versão do componente (que bate com o que o .fseventsd registou), e — atenção a isto — performance_class: 6, vram_mb: "36864". O Chrome fez profiling ao hardware antes de decidir se deveria fazer push do modelo. Leu a GPU e a memória unificada total para determinar elegibilidade. Antes de qualquer funcionalidade de IA ser visível ao utilizador.
Os flags internos do Chrome confirmam o resto: OnDeviceModelBackgroundDownload e ShowOnDeviceAiSettings são activados pelo mesmo rollout. O que significa que o download começa antes de existir sequer uma página de settings onde possas recusar. O UI que te permitiria dizer “não” aparece ao mesmo tempo que a instalação. Por design, não por acidente.
O paralelo com o caso Anthropic
Quando escrevi sobre o ClaudeGate, listei uma série de padrões de design que considerava problemáticos. Agora, lendo o artigo do Hanff sobre o Chrome, é impossível não ver que os padrões são exactamente os mesmos. Ponto por ponto.
Bundling forçado entre fronteiras de confiança? A Anthropic instalou o Claude Desktop e escreveu em sete browsers diferentes. A Google instala o Chrome e escreve um modelo de IA de 4 GB no perfil do utilizador sem autorização. O binário não é o Chrome — é um modelo de machine learning treinado separadamente, com um propósito separado e um perfil de proteção de dados separado.
Default invisível, sem opt-in? Exactamente o mesmo. Nenhum diálogo no primeiro arranque. Nenhuma checkbox nos Settings. O utilizador descobre meses depois quando o disco enche.
Mais difícil de remover do que de instalar? Instalar levou zero cliques. Remover exige descobrir que o ficheiro existe, perceber o que é, navegar até um caminho escondido no perfil de utilizador, apagar o ficheiro (e no Windows, limpar primeiro o atributo read-only), e aceitar que o Chrome vai voltar a descarregá-lo na próxima janela elegível a menos que também navegues até chrome://flags ou uses ferramentas de enterprise policy. Nenhum destes passos está documentado onde um utilizador normal procuraria.
Reinstalação automática a cada execução? O mesmo que o Claude Desktop. Apaga o ficheiro, o Chrome recria-o. A tua eliminação é tratada como um estado transitório a ser corrigido, não como uma diretiva a ser respeitada.
Naming ofuscado? OptGuideOnDeviceModel é jargão interno do Chrome para “OptimizationGuide on-device model storage”. Um utilizador a olhar para o disco não faria a associação a “pesos do LLM Gemini Nano”. Um nome honesto seria GeminiNanoLLM/weights.bin. A Google optou por obscurecer.
A lista continua, mas acho que o ponto está feito. É o mesmo playbook. Empresa diferente, escala diferente, mas a mesma atitude fundamental: a tua máquina é uma superfície de deployment para o roadmap do vendor, não um dispositivo pessoal cujo dono decide o que lá corre.
O “AI Mode” — a cereja podre no topo do bolo
E agora a parte que, para mim, é a mais ofensiva de todo o artigo.
Quando o Chrome 147 arranca num perfil elegível, a omnibox — a barra de endereços, o pedaço de real estate mais visível do browser inteiro — mostra um botão “AI Mode” à direita do URL. Um utilizador razoável, em 2026, ao ver “AI Mode” no browser que acabou de instalar silenciosamente 4 GB de um modelo de IA local, vai fazer uma inferência natural: que o AI Mode usa o modelo local. Que as queries ficam no dispositivo. Que o modelo local é o que alimenta aquela superfície local.
Cada parte dessa inferência está errada.
O AI Mode na omnibox do Chrome 147 é uma superfície cloud-backed — uma Search Generative Experience. Cada query que escreves ali é enviada para os servidores da Google para processamento pelos modelos hospedados. O modelo Nano local não é invocado pelo fluxo de AI Mode. São code paths completamente separados. A funcionalidade de IA mais visível do browser não usa o modelo local que te foi silenciosamente impingido.
As funcionalidades que realmente usam o modelo local — Help Me Write em <textarea>, sugestões de IA para tab groups, smart paste, resumo de páginas — estão enterradas em menus de contexto de textarea e menus de right-click de tab groups que o utilizador médio vai descobrir, em média, nunca.
Pensa no que isto significa. O utilizador paga o custo de armazenamento da instalação silenciosa (4 GB em disco, mais a largura de banda do download silencioso). A experiência de IA mais visível — a que ele realmente vê e clica — não oferece nenhum benefício on-device porque encaminha tudo para os servidores da Google de qualquer forma. O modelo on-device é um custo afundado imposto ao utilizador, sem nenhum benefício de transparência na superfície onde a transparência importaria mais.
Se o modelo on-device desse ao utilizador a propriedade clara de “as tuas queries de AI Mode ficam no teu dispositivo”, a instalação teria um enquadramento de privacidade defensável (pior em armazenamento, melhor em fluxo de dados). Mas não dá. A instalação dá à Google um recurso de opções futuras posicionado no dispositivo do utilizador, às custas do disco e da largura de banda do utilizador, enquanto a superfície de IA principal continua a enviar as queries para a Google como dantes.
O Hanff enquadra isto dentro de pelo menos três das famílias de dark patterns catalogadas nas Guidelines 03/2022 do EDPB. Informação enganosa, porque o label “AI Mode” cria uma impressão falsa sobre onde o processamento ocorre. Skipping, porque o utilizador não tem momento de escolha entre IA local e cloud-backed. E hindering, porque desligar o AI Mode não remove o modelo local, e remover o modelo local não desliga o AI Mode — os dois são controlados separadamente, e descobrir ambos os controlos requer saber sobre chrome://flags e chrome://settings/ai, nenhum dos quais é óbvio no Chrome por defeito.
O problema legal: ePrivacy, GDPR, e o elefante na sala
A análise legal do Hanff é directa e, na minha opinião, irrefutável.
O Artigo 5(3) da Diretiva ePrivacy proíbe o armazenamento de informação no equipamento terminal de um utilizador sem consentimento prévio, livre, específico, informado e inequívoco, excepto quando estritamente necessário para a prestação de um serviço da sociedade de informação explicitamente solicitado pelo utilizador. O ficheiro de 4 GB do Gemini Nano é informação armazenada no equipamento terminal do utilizador. O utilizador não consentiu. O utilizador não solicitou nenhum serviço que requeira estritamente um LLM on-device de 4 GB. O Chrome funciona sem o ficheiro. A violação do Artigo 5(3) é directa.
O Artigo 5(1) do GDPR exige que o tratamento de dados pessoais seja lícito, leal e transparente. Quando o hardware do utilizador é perfilado para determinar elegibilidade para o push do modelo, quando os eventos de instalação são registados nos servidores da Google, e quando as funcionalidades on-device que o modelo alimenta processam prompts do utilizador, a licitude, lealdade e transparência dependem de o utilizador ser informado, em linguagem clara, do que está a acontecer. Não é.
E depois há o Artigo 25 do GDPR — data protection by design and by default. Pré-instalar um modelo de IA de 4 GB no disco de um utilizador, contra a contingência de que ele possa no futuro invocar uma funcionalidade de IA, é o oposto arquitectónico da minimização por defeito.
O custo ambiental: os números que me tiraram o sono
E agora chegamos à parte do artigo que é genuinamente nova e, para mim, a mais perturbadora. Porque o caso da Anthropic envolvia um ficheiro JSON de 350 bytes a ser escrito em sete diretórios. O custo ambiental disso era negligível. Mas o caso do Chrome envolve 4 GB a serem empurrados para centenas de milhões de dispositivos. E isso tem uma pegada ambiental mensurável, quantificável, e francamente alarmante.
O Hanff fez as contas usando a mesma metodologia que a plataforma WebSentinel aplica a análise ambiental de websites: intensidade energética de transferência de dados de rede de 0.06 kWh por GB (o ponto médio de Pärssinen et al., 2018) e um fator de emissões de rede de 0.25 kg CO2e por kWh (o composto EEA/IEA EU-27 para 2024).
Por dispositivo, por push: 4 GB × 0.06 = 0.24 kWh de energia. 0.24 × 0.25 = 0.06 kg CO2e. Parece pouco? Multiplica pela escala do Chrome.
A Google não publica quantos dispositivos recebem o push do Nano. Mas o Chrome tem mais de 64% de quota de mercado global e entre 3.45 e 3.83 mil milhões de utilizadores. Os critérios de elegibilidade (performance class baseada em CPU, GPU, RAM e VRAM — tipicamente 16 GB de memória unificada ou superior em Apple Silicon, 16 GB de RAM e GPU com VRAM suficiente em Windows e Linux) excluem a gama mais baixa, mas a população elegível é ainda assim enorme.
Aqui estão os três cenários que o Hanff apresenta:
Na banda baixa — 100 milhões de dispositivos, cerca de 3% dos utilizadores Chrome — estamos a falar de 400 petabytes transferidos, 24 GWh de energia, e 6.000 toneladas de CO2e. Para contexto, 24 GWh é aproximadamente o consumo anual de electricidade de 7.000 residências no Reino Unido. 6.000 toneladas de CO2e são as emissões anuais de cerca de 1.300 automóveis de passageiros na UE.
Na banda média — 500 milhões de dispositivos, cerca de 15% dos utilizadores — salta para 2 exabytes, 120 GWh, e 30.000 toneladas de CO2e. É o consumo anual de 36.000 residências, ou a produção anual de uma turbina eólica de 14 MW.
Na banda alta — 1 milhar de milhão de dispositivos, 30% dos utilizadores — são 4 exabytes, 240 GWh, e 60.000 toneladas de CO2e. É o consumo de 72.000 residências. As emissões anuais de 13.000 carros.
E estes são apenas os números de entrega. Não incluem os re-downloads provocados por utilizadores que tentam apagar o ficheiro e o Chrome volta a descarregar. Não incluem futuras atualizações do modelo. Não incluem a energia de inferência on-device quando o modelo é efetivamente usado. E não incluem o custo de carbono embodied dos SSDs — que é aproximadamente 0.16 kg CO2e por GB de NAND fabricado. Para mil milhões de dispositivos × 4 GB, isso são cerca de 640.000 toneladas de CO2e de impacto de carbono embodied de fabrico, alocadas a um caso de uso que o utilizador não consentiu.
Estamos a falar de um push de modelo que, na estimativa conservadora, equivale a colocar mais de mil carros na estrada durante um ano. Na estimativa mais realista, estamos nos 6.500 carros. E tudo isto para um ficheiro que a maioria dos utilizadores nem sabe que está no disco.
O que a Google devia ter feito
Isto não é rocket science. O Hanff lista as soluções, e são exactamente as mesmas que listou para a Anthropic:
Perguntar. Ponto final. A primeira vez que o Chrome está prestes a descarregar o modelo Nano, mostra um diálogo. “O Chrome gostaria de descarregar um modelo de IA de 4 GB para o teu dispositivo para alimentar as seguintes funcionalidades. Permitir, ou saltar e decidir depois.” Dois botões. Feito.
Pull, não push. Desencadear o download como consequência do utilizador invocar uma funcionalidade de IA pela primeira vez. Deixar que a própria funcionalidade seja o evento de consentimento. Não pré-instalar por contingência.
Dar visibilidade. Em chrome://settings/, listar os ficheiros de modelo de IA que o Chrome descarregou, o seu tamanho, as funcionalidades que alimentam, e um botão “Remover e parar de descarregar” por modelo. Tornar a remoção persistente, não um estado transitório que o Chrome corrige no próximo arranque.
Documentar. Dizer ao utilizador, claramente, na descrição do Chrome na Microsoft Store, no instalador, na página de download do Google Chrome, que o Chrome vai descarregar ficheiros de modelo adicionais de tamanho substancial em hardware suportado.
Respeitar a eliminação. Se o utilizador apaga o weights.bin, não o recriar. Se o utilizador tem uma preferência forte sobre o que está no seu disco, a aplicação não está em posição de sobrepor essa preferência porque acha que sabe melhor.
Divulgar a escala. Publicar, no relatório ESG anual da Google, a pegada agregada de largura de banda e carbono de todos os pushes de modelo de funcionalidades de IA para dispositivos de utilizadores, desagregada por região. Tratá-la como a emissão Scope 3 Category 11 que é.
A minha opinião pessoal
Sabem, quando escrevi sobre o ClaudeGate, fiz questão de dizer que usava o Claude e que o considerava uma ferramenta excelente. Fiz isso porque queria que fosse claro que a crítica não vinha de um lugar de hostilidade, mas de preocupação genuína. Estou a fazer a mesma coisa aqui com o Chrome.
Mas há um padrão que se está a formar e que me preocupa profundamente. A Anthropic fez uma coisa parecida há semanas. A Google está a fazer agora, numa escala incomparavelmente maior. E nos dois casos, o raciocínio de engenharia por trás da decisão é o mesmo: “a máquina do utilizador é uma superfície de deployment que podemos usar para pré-posicionar os nossos assets, e o consentimento do utilizador é uma formalidade que pode ser tratada depois.”
Não pode. Não deve. E no espaço jurídico europeu, já não pode mesmo — a legislação existe desde 2002.
O Hanff fecha o artigo dele com uma pergunta que eu subscrevo inteiramente: quando é que os reguladores e procuradores públicos vão começar a aplicar a lei que está em vigor há mais de duas décadas? Ou será que as grandes tecnológicas globais estão isentas dos estatutos criminais e civis?
É uma boa pergunta. E não é retórica.
Fonte e leitura obrigatória: Chrome Silent Nano Install — That Privacy Guy
Até à próxima.