Google vs. Mozilla: a controvérsia por trás da IA no browser
Google vs. Mozilla: a controvérsia por trás da IA no browser
A Prompt API do Chrome não é só uma feature técnica. É o epicentro de uma briga sobre padrões web que não se via desde as guerras dos browsers, lá nos anos 2000. E olha — eu pensei que aqueles tempos tinham ficado para trás.
TL;DR
- Google lançou a Prompt API no Chrome 148 apesar da oposição formal de Mozilla, Apple, W3C TAG e Microsoft
- Críticos apontam quebra de interoperabilidade, download sem consentimento de 4.27GB e termos de uso numa API web
- O debate definirá como IA é integrada à plataforma web pelos próximos 10 anos
O Google mandou a API para produção no Chrome 148 (maio de 2026) ignorando a oposição formal de Mozilla, Apple WebKit, W3C TAG e Microsoft. Leia de novo: todos os outros vendors de navegador relevantes disseram “não” — e o Google fez assim mesmo. É a primeira vez que uma API de plataforma web nasce contra a vontade explícita de todo mundo que não é o Google. O que segue aqui é a cronologia, os argumentos de cada lado e o que isso muda na prática pra quem escreve código.
A decisão unilateral
Em 16 de maio de 2026, o Chrome 148 começou a pingar nos dispositivos com a Prompt API ligada por padrão. De uma tacada só, qualquer website no browser mais usado do planeta — coisa de 4,16 bilhões de usuários — ganhou a possibilidade de rodar inferência de IA no dispositivo. Usando um modelo de 4,27 GB que o Google já tinha empurrado sem pedir licença.
Quando li isso pela primeira vez, fiquei genuinamente dividido. A tecnologia impressiona, ninguém discute. Mas enfiar 4 GB no computador das pessoas sem perguntar? Isso é pesado. Literalmente.
Quem se opõe e por quê
Mozilla Firefox
A oposição da Mozilla é a mais articulada. Jake Archibald, líder de relações com desenvolvedores web da Mozilla, publicou em abril de 2026 na discussão do GitHub:
“Continuamos a nos opor a esta API, e sentimos que ela tem consequências negativas severas para a interoperabilidade, atualizabilidade e neutralidade da plataforma web.”
Os argumentos centrais da Mozilla se resumem a quatro pontos:
Interoperabilidade quebrada. Prompts são acoplados ao modelo. Desenvolvedores inevitavelmente ajustam seu código para as idiossincrasias do Gemini Nano, criando caminhos de código específicos para o modelo do Chrome.
O fantasma do “Best viewed in IE”. Isso recria o cenário dos anos 2000 onde sites funcionam apenas em um navegador. Quem é velho o suficiente para lembrar, sabe o estrago que isso causou.
Termos de uso numa API de plataforma. Usar a API exige aceitar a Google Generative AI Prohibited Uses Policy, que proíbe coisas que nem são ilegais (como conteúdo “perturbador”). Uma API web com EULA de vendor é precedente perigoso.
Demanda “fabricada”. O Google citou posts de redes sociais como evidência de demanda. Archibald chamou de “evidência que não parece corresponder à afirmação.” Duro.
Em entrevista ao The Register, Archibald expandiu:
“O problema central é interoperabilidade. Prompts são fortemente acoplados a modelos; desenvolvedores inevitavelmente ajustarão para as idiossincrasias e políticas de qualquer modelo contra o qual estão construindo. É assim que você termina com caminhos de código específicos para modelo — é o problema de compatibilidade entre browsers de novo.”
E sobre os termos de uso:
“Se usar uma API web significa aceitar a política de conteúdo de um vendor específico (especialmente uma que vai além da lei), você não está mais construindo para uma plataforma aberta.”
Apple WebKit
A Apple se opôs formalmente. O WebKit nunca implementou a API e publicou posição contrária. Menos vocal que a Mozilla, mas as preocupações são parecidas: precedente de APIs dependentes de modelo proprietário, impossibilidade de garantir comportamento consistente, modelo de consentimento inadequado.
W3C TAG (Technical Architecture Group)
O TAG — grupo responsável por avaliar a saúde arquitetural da web — revisou a proposta e não alcançou consenso para aprová-la. Isso por si só é significativo. O TAG raramente falha em alcançar consenso, e quando falha, é sinal de problemas sérios.
Os pontos levantados: a API expõe funcionalidade cuja qualidade varia drasticamente entre implementações, não há como escrever código que funcione “na web” (apenas “no Chrome com Gemini Nano”), e o conceito de “prompt” é inerentemente não-interoperável quando modelos diferentes respondem de formas diferentes ao mesmo texto.
Microsoft Edge
A posição da Microsoft é reveladora. Apesar do Edge ser baseado no Chromium:
- Implementou sua própria versão com o modelo Phi-4-mini (não o Gemini Nano)
- Manteve como developer preview nos canais Canary e Dev
- Não habilitou para web pages em stable
- Em junho de 2026, anunciou o Aion-1.0-Instruct como alternativa
A existência de implementações com modelos diferentes demonstra exatamente o problema que os críticos apontam. O mesmo prompt produz resultados diferentes em cada browser:
| Métrica | Chrome (Gemini Nano) | Edge (Phi-4-mini) |
|---|---|---|
| Falha em tarefas generativas | 15,17% | 24,29% |
| Falha em classificação | 23,93% | 29,58% |
| Alucinações (groundedness) | 6% | 17% |
Esses números mostram que a “mesma API” com modelos diferentes produz experiências radicalmente diferentes. É como se Math.random() retornasse números entre 0-1 num browser e entre 0-100 noutro.
Os argumentos do Google
O Google, claro, defende a decisão. Rick Byers, engenheiro do Chrome responsável pelo lançamento, respondeu no GitHub:
“Como um dos aprovadores de API do Blink para o lançamento no Chromium, admito que compartilho das preocupações na posição de padrões da Mozilla. Onde difiro é em preferir caminhos que promovam experimentação, aprendizado com erros e competição àqueles que erram pelo lado de paralisar a inovação por medo do que pode acontecer.”
Os argumentos a favor:
- Só colocando no mundo real dá para saber se funciona
- Outras APIs controversas (como EME/DRM) foram lançadas com oposição e não causaram o apocalipse previsto
- Benefícios concretos: latência zero, custo zero, privacidade por design, uso offline
- A API é abstraída do modelo — em teoria, qualquer browser pode implementar com qualquer modelo
O porta-voz do Google declarou ao The Register:
“Parte de trabalhar abertamente é encorajar debate e discordância. Recebemos bem o feedback da Mozilla e continuaremos a colaborar com eles e a comunidade web conforme trabalhamos para melhorar a API.”
Difícil não ler isso com um pé atrás, dado que lançaram a API apesar do feedback. Mas ok.
O problema do download sem consentimento
Um dos pontos mais inflamáveis: o download automático de 4,27 GB. Em maio de 2026, o pesquisador Alexander Hanff (apelidado “That Privacy Guy”) mostrou que:
- O Chrome baixa o Gemini Nano sem prompt de consentimento
- Não há checkbox em configurações para impedir
- Remover o arquivo manualmente não funciona — o Chrome trata a deleção como erro temporário e re-baixa na próxima oportunidade
Segundo o Yahoo Tech:
“O Chrome instala o arquivo automaticamente em dispositivos que atendem certos requisitos de hardware, sem prompt de consentimento e sem checkbox nas configurações. Remover o arquivo manualmente não se mantém — o Chrome trata a deleção como erro temporário e restaura o download completo na próxima oportunidade.”
A reportagem do XDA Developers notou que isso pode violar regulamentações da UE:
“O deploy em escala pode violar regras de privacidade da UE e adicionar ~30.000 toneladas de CO2e dos downloads generalizados.”
Trinta mil toneladas de CO2. Para baixar um modelo que a maioria das pessoas nem sabe que está ali.
O argumento de interoperabilidade em detalhe
Essa é a parte que merece atenção técnica. Diferente de APIs como Canvas, WebAudio ou Fetch — onde a especificação define um comportamento determinístico — a Prompt API é fundamentalmente não-determinística.
Por que prompts são acoplados ao modelo
// Este prompt funciona bem no Gemini Nano:
const result = await session.prompt(
'Classify as positive/negative: "Great product!"',
{ responseConstraint: { type: "string", enum: ["positive", "negative"] } }
);
// Mas em outro modelo (Phi-4-mini no Edge):
// - Pode classificar diferente
// - Pode falhar silenciosamente
// - Pode retornar formato inesperado apesar do schemaO problema não é o schema — é que a qualidade de compreensão varia. Um modelo pode entender sarcasmo, outro não. Um segue instruções complexas, outro ignora metade. Isso significa que desenvolvedores terão que testar e ajustar para cada modelo, recriando o cenário de feature detection por browser dos anos 2000.
A analogia com “Best viewed in IE”
Nos anos 90-2000, sites eram construídos para Internet Explorer e quebravam nos outros. A web demorou uma década para superar isso com padrões rigorosos.
A Prompt API potencialmente recria esse cenário: sites otimizados para Gemini Nano (Chrome), comportamento diferente no Phi-4-mini (Edge), sem implementação em Firefox ou Safari. Desenvolvedores adicionando if (isChrome) para features de IA.
A diferença — e isso é relevante — é que padrões web modernos são determinísticos. IA não é. O mesmo prompt gera resultados diferentes em modelos diferentes. A interoperabilidade é fundamentalmente mais difícil aqui.
A Google Prohibited Uses Policy
Um aspecto pouco discutido: usar a Prompt API implica aceitar a Google Generative AI Prohibited Uses Policy. Ela proíbe gerar conteúdo “perturbador” (subjetivo), desinformação (quem define?), conteúdo sexual explícito, atividades que “podem causar dano.”
O ponto da Mozilla: uma API web não deveria ter termos de uso do vendor. Se eu uso Canvas para desenhar, não preciso aceitar termos do Google. Se uso WebAudio para tocar som, não assino EULA da Apple. Mas usar LanguageModel.prompt() implicitamente aceita regras do Google sobre conteúdo.
Isso cria um precedente onde APIs de plataforma vêm com restrições de uso do fabricante. Mina o conceito de web aberta.
O fator competição
É impossível ignorar os incentivos econômicos:
| Player | Incentivo |
|---|---|
| Distribuir Gemini Nano para 4+ bilhões de dispositivos; lock-in de modelo; coleta de dados de uso | |
| Mozilla | Manter neutralidade da web; evitar dependência de vendor; proteger relevância do Firefox |
| Apple | Proteger seu ecossistema de IA (Apple Intelligence); não dar vantagem ao Google |
| Microsoft | Competir com Phi-4; manter controle sobre IA no Edge |
| Desenvolvedores | API gratuita e simples vs. risco de lock-in |
Todo mundo tem pele no jogo. Ninguém nesse debate é neutro.
O contra-argumento: Encrypted Media Extensions
Rick Byers comparou a situação com EME (Encrypted Media Extensions) — a API de DRM adicionada ao HTML5 apesar de forte oposição. Na época, críticos previam que EME destruiria a web aberta. Na prática: virou padrão W3C, todos os browsers implementaram, o cenário catastrófico não se materializou (embora debates sobre DRM continuem).
O argumento implícito: “Lançamos EME contra a vontade de todos e deu certo. Podemos fazer de novo.”
Mas há diferenças importantes:
- EME tem comportamento determinístico — DRM funciona igual em todos os browsers
- A Prompt API é inerentemente não-determinística
- EME não exigia aceitar termos de uso do Google
- EME não baixava 4 GB sem consentimento
O que acontece agora?
Em junho de 2026:
| Browser | Status da Prompt API |
|---|---|
| Chrome 148+ | ✅ Stable, habilitado por padrão |
| Edge | ⚠️ Developer preview (Canary/Dev), modelo Phi-4-mini, testando Aion-1.0 |
| Firefox | ❌ Não implementado, oposição formal |
| Safari | ❌ Não implementado, oposição formal |
Cenários possíveis nos próximos 12 meses:
- Google vence por inércia: desenvolvedores adotam, sites dependem, outros browsers são pressionados a implementar. Cenário mais provável, honestamente.
- Padronização forçada: pressão leva a uma spec mais restrita que todos aceitem. Ideal mas improvável no curto prazo.
- Fragmentação permanente: Chrome tem IA, outros não. Web se fragmenta.
- Regulação intervém: EU força remoção por questões de consentimento. Possível mas lento.
Análise equilibrada
Sendo justo com os dois lados:
O Google tem razão em que:
- IA on-device oferece benefícios reais (privacidade, custo, latência)
- Esperar consenso perfeito pode paralisar inovação por anos
- EME mostra que lançar primeiro e iterar pode funcionar
- Desenvolvedores genuinamente querem IA fácil no browser
Os críticos têm razão em que:
- A web é construída sobre interoperabilidade — APIs não-determinísticas a minam
- Download sem consentimento viola princípios básicos de agência do usuário
- Termos de uso do Google numa API de plataforma é precedente perigoso
- Google tem incentivo econômico para lock-in, não apenas “inovação”
- A evidência de demanda dos desenvolvedores foi fraca
Como esse debate se resolve vai definir como IA é integrada à web pelos próximos 10 anos. Não é exagero.
E para desenvolvedores brasileiros?
Na hora de decidir se vai usar a Prompt API hoje:
Use se:
- Seu público é majoritariamente Chrome desktop
- Privacidade é requisito e cloud API é inaceitável
- Você aceita que a feature não funciona em outros browsers
- Tem fallback para quando a API não está disponível
Evite se:
- Precisa funcionar cross-browser
- Seu app precisa funcionar em mobile
- Não quer depender de decisões unilaterais do Google
- Seus usuários estão em hardware limitado
A recomendação pragmática: trate a Prompt API como progressive enhancement, nunca como funcionalidade core. Se estiver disponível, use. Se não, tenha fallback. E nunca assuma que vai existir em outros browsers.
Conclusão
A briga expõe uma tensão que não vai embora: o Google controla ~65% do mercado de browsers e pode, na prática, decidir o que a “web” significa — com ou sem a benção de ninguém. A Prompt API é tecnicamente impressionante, mas o processo pelo qual foi lançada levanta questões legítimas sobre governança, consentimento e poder de mercado.
Pra quem está no dia a dia escrevendo código: use com consciência. Não é padrão web — é API de um vendor. Construa com fallback. E fique de olho no debate, porque ele vai definir as regras do jogo que a gente joga.
Leia também:
- O que é a Chrome Prompt API — visão técnica completa
- Como testar a Prompt API hoje — tutorial prático
- Prompt API vs. OpenAI API — quando usar cada uma
FAQ
A Mozilla vai implementar a Prompt API no Firefox?
Não há indicação de que vá acontecer. A Mozilla publicou oposição formal e considera que a API tem “consequências negativas severas para a interoperabilidade.” Estão investindo em soluções próprias (Mozilla.ai, Smart Window) com abordagens diferentes.
O Google baixou o modelo no meu Chrome sem minha permissão?
Provavelmente sim, se seu hardware atende os requisitos. O Chrome baixa o Gemini Nano automaticamente. Verifique em chrome://on-device-internals. Não há forma simples de impedir permanentemente — mesmo deletando manualmente, o Chrome re-baixa.
A Prompt API pode se tornar um padrão W3C?
Improvável na forma atual. O W3C TAG não alcançou consenso, Mozilla e Apple se opõem, e respostas diferentes entre modelos contradizem os princípios de padronização web. Uma versão futura mais restrita e interoperável poderia eventualmente ser padronizada — mas estamos longe disso.
Por que o Microsoft Edge não habilitou para web pages?
A Microsoft implementou com Phi-4-mini apenas em canais experimentais. Provavelmente reconhece os mesmos problemas de interoperabilidade — especialmente porque o Phi-4 produz resultados bem diferentes do Gemini Nano.
Isso é como “Best viewed in Internet Explorer”?
Analogia imperfeita mas relevante. Nos anos 2000, sites eram otimizados para IE porque era dominante. Aqui, o risco é sites otimizados para o Gemini Nano porque Chrome é dominante. A diferença: padrões web modernos são determinísticos — IA não é. O mesmo prompt gera resultados diferentes em modelos diferentes, tornando a interoperabilidade fundamentalmente mais difícil.