A oposição da Mozilla à Prompt API do Chrome

 (github.com/mozilla)
6 pontos por GN⁺ 2026-05-01 | 1 comentários | Compartilhar no WhatsApp
  • A Prompt API, que expõe modelos de linguagem no navegador como uma API web, pode ser útil em uma forma genérica, mas incentiva implementações ajustadas ao comportamento específico de cada modelo, aumentando o risco de interoperabilidade
  • Se desenvolvedores ajustarem prompts e funcionalidades para implementações específicas, como o Phi-4-mini do Edge, isso pode causar queda de qualidade ou bloqueio de acesso ao site em outros navegadores ou modelos
  • A Mozilla entende que, em vez de ser lançada diretamente como API web, ela deveria passar por mais validação em userland, usando a trial web extension API e a proposta de web extension do grupo Web Machine Learning como canais iniciais de feedback
  • Se prompts de sistema se espalharem ajustados às quirks de um modelo específico, até modelos novos podem parecer ruins, e navegadores podem passar a sofrer pressão para incluir modelos do Google ou modelos compatíveis com essas quirks
  • O Chrome apresentou como mitigação restrições de resposta baseadas em JSON schema e regex, discussões no WebML CG e testes com modelos alternativos, mas a posição da Mozilla sobre a Prompt API está marcada como negative

Avaliação negativa da Mozilla sobre a Prompt API

  • A Prompt API foi analisada no standards-positions da Mozilla após o intent-to-prototype do Blink, e o explainer aponta para o README da webmachinelearning/prompt-api
  • O feedback da Mozilla é quase igual ao de Writing Assistance APIs #1067: uma Prompt API genérica pode ser útil, mas incentiva comportamentos específicos de modelo, aumentando os riscos de interoperabilidade
  • Desenvolvedores podem ajustar prompts e recursos para um modelo específico, e se criarem algo voltado a implementações como o Phi-4-mini do Edge, a qualidade pode cair ou o acesso ao site pode ser bloqueado em outros navegadores ou modelos
  • Em vez de ser lançada diretamente como API web, ela deveria ser validada por mais tempo em userland; a trial web extension API da Mozilla e a proposta de web extension do grupo Web Machine Learning serviriam como caminhos iniciais para coletar feedback
  • Com base nessa discussão e em #1067, a posição da Prompt API foi marcada como negative

Por que preferir Web Extension em vez de Origin Trial

  • Escolha de modelo e momento da padronização

    • A capacidade de escolher exatamente um modelo em um model hub é tratada como central, tanto para funcionalidades na página quanto porque o navegador não deveria escolher um modelo específico
    • Essa capacidade depende de detalhes de implementação em uma área que muda rapidamente e ainda não é vista como pronta para padronização
    • Extensions são uma forma de baixo custo para explorar rapidamente padrões reais de uso além do escopo atual da proposta e experimentar funcionalidades entre navegadores, sem o custo de coordenação de lançar em três engines com semânticas ainda não consolidadas

  • Fronteiras visíveis para o usuário

    • A instalação de um add-on sinaliza ao usuário que ele está saindo dos limites de uma funcionalidade web comum; aqui isso vale para armazenamento cross-origin compartilhado
    • Essa avaliação segue uma lógica parecida com a de WebMIDI Add-On Gated posição adicionada #704 em outro contexto
    • A proposta de extension expõe à página uma API parecida com Prompt, usa inferência local e modelos definidos pelo desenvolvedor, e foi estruturada para obter repositório compartilhado de modelos e feedback inicial dos usuários

O risco de endurecer em torno de um único modelo

  • Prompts de sistema e quirks de modelo

    • Prompts de sistema tendem a ser ajustados repetidamente às quirks do modelo em uso
    • Em um prompt de sistema para gerar instruções de automação residencial, o modelo Gemini inicialmente respondia de forma muito americana, o que não combinava com uma voz de alto-falante britânica
    • Ao indicar no prompt de sistema que ele falava com voz britânica, surgiram respostas como “a'waight guv'nor apples and pears”, uma imitação americana de inglês britânico, e foi necessário ajustar ainda mais para reduzir isso e chegar a algo mais próximo de um britânico real
    • Uma correção feita para um modelo pode virar correção excessiva em outro, e o problema piora em formatos de saída que não podem ser expressos por voice com branding ou por JSON schema e regex

  • Novos modelos e o custo de atualizar o navegador

    • Se prompts de sistema ajustados às quirks de modelos atuais se espalharem amplamente, até modelos novos e melhores podem parecer ruins para desenvolvedores e usuários
    • Mozilla e Apple podem acabar pressionadas a licenciar modelos do Google ou adotar modelos compatíveis com as quirks dos modelos do Google para manter interoperabilidade
    • Pelo mesmo motivo, até o Chrome pode ter dificuldade para atualizar seus próprios modelos

  • Detecção de ID de modelo e ramificações por navegador

    • O desenvolvedor pode criar um modelo com LanguageModel.create() e perguntar algo como model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') para obter ID, nome, versão e empresa de origem do modelo
    • Um exemplo de retorno seria 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • O desenvolvedor poderia montar conjuntos de prompts de sistema para modelos específicos e bloquear modelos desconhecidos ou avisar ao usuário que a qualidade da saída pode ser inferior
    • Isso é visto como um retorno ao code branching do começo dos anos 2000, algo que deveria ser evitado

Política do Google e o problema da neutralidade de modelo

  • Segundo a documentação do Chrome, antes de usar a Prompt API é necessário reconhecer a Google Generative AI Prohibited Uses Policy
  • Parte dessa política cobre temas que vão além da lei, incluindo a proibição de “geração ou distribuição de conteúdo que promova conteúdo sexualmente explícito” e “promoção de alegações enganosas relacionadas a governo ou processos democráticos”
  • Não é desejável que APIs da plataforma web passem a exigir regras de uso por UA, pois isso pode abrir precedente para que mais APIs venham com regras específicas de UA
  • Se um usuário clicar em “summarize” nos comentários de uma notícia em um site e isso resultar em violação da política do Google, não fica claro se a responsabilidade seria do usuário que clicou no botão, do autor do comentário com conteúdo violador, ou do dono do site que implementou o recurso que envia esse comentário ao LLM da UA do usuário
  • Desenvolvedores podem querer saber com qual LLM estão se comunicando para cumprir os termos do modelo e evitar ações legais por parte do dono do modelo; um modelo desconhecido pode significar termos desconhecidos, e bloqueá-lo pode parecer a escolha racional
  • Há também a linha de argumentação de que um navegador específico não tem base para impor esse tipo de termo aos desenvolvedores de sites, e que essa questão de política deveria ser tratada separadamente da proposta da API

Atualizações e mitigação do lado do Chrome

  • O time da Chrome Prompt API compartilhou o blink-dev I2S e a atualização sobre riscos de interoperabilidade e compatibilidade no ChromeStatus
  • Eles dizem querer manter a participação e as discussões no WebML CG, além de continuar experimentos posteriores, como sampling parameters interoperáveis
  • O lado do Chrome afirma estar motivado a tornar o Language Model fornecido pelo navegador e pelo sistema operacional uma opção útil para desenvolvedores web e usuários, preservando a saúde e a neutralidade de longo prazo da plataforma web
  • A superfície da Prompt API mostrou algum grau de compatibilidade tanto com modelos do Google quanto da Microsoft, e estão sendo aplicadas restrições objetivas de resposta para que a saída siga JSON schema ou regex conhecidos
  • Essas restrições são apresentadas como mitigação para reduzir a necessidade de hacks específicos por modelo ao lidar com saídas imprevisíveis
  • Projetos downstream de Chromium estão explorando modelos alternativos e backends de framework, incluindo integração da Android MLKit da Microsoft e prototipação inicial de integração com foundational models da Apple
  • Durante o trial da API, diferentes versões de modelo foram distribuídas experimentalmente, e ainda são necessárias atualizações e melhorias contínuas, incluindo investigação de suporte aos mais novos Gemma 4 open models
  • Também estão sendo explorados categorical sampling modes para ajustar comportamentos mais interoperáveis entre arquiteturas de base diferentes
  • O texto de Interoperability and Compatibility no blink-dev diz que a variabilidade de comportamento e resposta é uma expectativa já conhecida para desenvolvedores que usam essa tecnologia, e que a API busca uma estrutura de interoperabilidade voltada a uma abordagem consistente da plataforma web entre navegadores e modelos

Base do apoio de desenvolvedores web e crítica ao lançamento

  • O blink-dev intent to ship marca a posição dos desenvolvedores web como “Strongly positive” e liga como evidência o stakeholder feedback no explainer
  • Essa base é tratada como algo que não combina bem com uma avaliação de “Strongly positive”

  • Itens listados como evidência

    • Uma thread no GitHub com 2 respostas positivas
    • Uma postagem única no X
    • Um post de blog que não existe mais, retornando Server Not Found
    • Um post de blog que ainda existe
    • Uma pesquisa que aparentemente perguntava aos desenvolvedores se seria aceitável que essa API existisse em extensions, sem explicitar os números da pesquisa nem o público consultado
    • O post de blog removido foi compartilhado em versão arquivada via Wayback Machine
    • Mesmo que a documentação destaque fortemente o que “não se deve depender” e o que é seguro depender, não fica claro se, seguindo essa orientação, ainda sobra uma utilidade prática ampla para a API
    • Na prática, parece possível depender até certo ponto do comportamento do modelo específico testado e, se esse for o modelo do Chrome, o site pode simplesmente recomendar o uso da versão mais recente do Chrome
    • Continua sendo problemático que o Google identifique amplamente áreas ainda inacabadas, mas ao mesmo tempo considere que as mitigações atuais já são suficientes para shipping

Discussão nos comentários: alternativas, medição de danos e mitigação posterior

  • Automação de navegador e modo Lynx

    • Com Hermes Agent e Qwen3.6 já era possível executar a maioria das tarefas, e a linha de raciocínio é que a atenção deveria ir mais para browser automation API e para o modo Lynx para chat do que para a Prompt API
    • Em alguns fluxos de trabalho, uma pessoa faz login no site e, com uma extensão AJAX, torna arquivos visíveis; depois, o agent usa chromedriver/webdriver para baixar documentos, etiquetar e resumir
    • Esse fluxo poderia ser integrado dentro do navegador, sem shell POSIX externo
    • O chat em modo Lynx expõe rapidamente o que os agents veem e economiza recursos dos dois lados por não baixar nem renderizar todos os ativos de mídia
    • Também foram citados marcação robots mais granular em nível de HTML, handoff entre shell Lynxmode e navegadores tradicionais, e formas de exibir seletivamente links no estilo antigo do Google AdWords em navegadores guiados por agent

  • Web aberta e FOMO

    • Há a contraposição de que a web aberta não compete do mesmo jeito que chat bot super apps e não vai desaparecer
    • Também aparece a ideia de que, antes de viver em FOMO constante, é preciso perguntar o que exatamente se quer representar
    • Há ainda uma corrente que não concorda com o temor de que, se a web não der suporte rápido e eficaz a agentic computing — assim como não sustentou plenamente o paradigma de apps mobile — comércio e jornalismo migrariam para fora da web aberta

  • Shipping no Chromium e medição de danos

    • Um dos blink API owner approvers do Chromium disse compartilhar as preocupações da Mozilla, mas preferir um caminho que permita experimentar, aprender com erros e incentivar concorrência
    • Para avaliar danos reais no futuro, seria preciso definir resultados concretos; há o contexto de que foi útil comparar, 5 a 10 anos depois, decisões controversas de shipping de APIs como EME com seus efeitos reais
    • O dano de sites endurecerem em torno de um modelo específico do Google poderia ser medido pelo número e pela gravidade de bugs de compatibilidade de sites quando outros navegadores fizerem shipping, e pela natureza dos bugs que surgirem quando o Chrome atualizar o modelo
    • A ideia é distinguir bugs de “tornar o modelo mais inteligente” de bugs de “preservar uma quirk estranha”, e reuni-los com labels em webcompat.com
    • Segundo o blink-dev I2S, o Edge também já está fazendo shipping dessa API com um modelo diferente, então já existem dados iniciais
    • Para as preocupações com TOS, a métrica de dano seria se violações realmente geraram processos ou ameaças legais, e a sugestão é reunir esse tipo de evidência em registro

  • Mitigação posterior e resposta do Chrome

    • A abordagem de verificar primeiro se os danos possíveis realmente acontecem é válida, mas há o contra-argumento de que isso só é útil se houver mitigação significativa depois que o dano surgir
    • Quando um site endurece em torno de um modelo específico do Google, surgem perguntas sobre opções como feature unship, mudanças no modelo que quebrem prompts de site superajustados, random model rotation e padronização aberta dos pesos de modelos on-device
    • Foi dito que, se surgirem evidências de que outros navegadores precisam copiar quirks estranhas do modelo do Chrome, a partir de uma posição de liderança no Chromium o Chrome deveria ser pressionado a quebrar essas quirks
    • Foi citado como precedente o caso em que o GMail mobile dependia de quirks bugadas de border image no WebKit; quando o Firefox sentiu necessidade de copiar esse comportamento, o Chrome foi corrigido de modo a quebrar o GMail, e o GMail se atualizou rapidamente sem que os usuários percebessem

Leituras relacionadas

1 comentários

 
GN⁺ 2026-05-01
Comentários do Hacker News

  • O argumento contrário parece bem claro: acoplamento forte entre prompt e modelo, e o problema da neutralidade de modelo nos termos de uso
    Como no caso pessoal em https://github.com/mozilla/standards-positions/issues/1213, ao criar um prompt de sistema para alertas de automação residencial, o Gemini inicialmente respondia de forma americana demais; quando foi informado de que falaria com voz britânica, passou a produzir uma imitação britânica canhestra feita por um americano, tipo “a'waight guv'nor apples and pears”, exigindo mais ajustes
    Nesse processo, o prompt de sistema acaba sendo ajustado para um modelo específico, e outros modelos têm quirks diferentes, então uma correção colocada para um modelo pode virar sobrecorreção em outro

    • O resultado soa como deboche em adversarial mode
    • Se isso for um bom motivo para não oferecer funcionalidade de LLM, então a conclusão seria que ela não deveria estar em nenhuma API de plataforma. Só que ela já foi adicionada a várias plataformas
      O fato de variar entre modelos é uma característica central dessa tecnologia. É parecido com o tamanho do canvas mudar conforme o dispositivo ou a orientação, a precisão da geolocation API variar, ou as vozes de Speech Synthesis serem diferentes em cada aparelho
      Isso parece menos uma crítica construtiva e mais um sentimento anti-AI. Hoje talvez seja preciso uma UI de permissões, e talvez um dia surjam níveis de QI como low/medium/high, mas os desenvolvedores que realmente se importam vão acabar dependendo 90% de um modelo específico de qualquer forma
      Com o tempo, quando a aversão a IA diminuir e as pessoas perceberem que ela ajuda, a ausência desse recurso no Firefox pode acabar parecendo um fracasso em termos de autonomia dos dados pessoais. Se o problema são os TOU relacionados no Chrome, isso seria justamente um motivo para o Firefox implementar o recurso com termos de modelo sem esse problema

  • Eu não sabia quem tinha escrito a posição contrária, mas era o Googler de longa data da equipe do Chrome Jake Archibald, que foi para a Mozilla e escreveu uma posição contra uma API do Chrome. Não surpreende que a crítica esteja bem organizada, e deve ter sido libertador desta vez não precisar seguir a linha do partido

    • Obrigado, mas acho que ele já não seguia a linha do partido quando estava no Google. Só que isso foi tornando a vida interna cada vez mais difícil, e no fim ele saiu
      Pelo que se ouve de quem ainda está no time, nessa dimensão a situação parece ter piorado exponencialmente
    • Ele certamente conhece muito bem o repo standards-positions, e o texto soa como a defesa típica quando o Google tenta empurrar algo sem consulta suficiente
      Em vez de propor mudanças, a postura é mais de descartar tudo; e, se for descartado, parece haver a expectativa de reescrever do zero de forma colaborativa, sem começar da visão da equipe do Google Chrome. Só que não lembro de muitos casos em que isso deu certo, então talvez fosse melhor simplesmente apresentar alterações concretas

  • Sou contra isso

    1. Vira uma nova fonte de fingerprinting, e como é difícil enganar scripts de fingerprinting, pode ser abusado para “verificação de dispositivo”. Não deveria ser possível “verificar” o navegador, e qualquer pessoa deveria poder emular qualquer navegador
    2. LLM consome muita memória e CPU, e considerando o preço atual de RAM, fazer upgrade também sai caro. Se sites dependerem de modelo local, aparelhos baratos vão ficar lentos
    3. A API parece moldada para um LLM específico, como o da OpenAI
    4. Pode expulsar concorrentes do mercado de navegadores que não tenham seu próprio modelo de IA. Se os sites forem feitos esperando o Google Gemini, eles podem quebrar em outros modelos ou em navegadores de países sem modelo de IA, e não deveria existir navegador de “primeira classe” e “segunda classe”
      O explainer diz que pode processar localmente sem enviar dados para lugar nenhum, mas nesse caso fica a dúvida de por que um modelo local do Google Gemini precisaria de Prohibited Use Policy. Por que o Google se importaria com prompts e respostas que ele não consegue ver?
      O próprio acesso offline a LLM parece interessante, mas sites não precisam de um LLM embutido no navegador para isso: podem usar WebGPU ou melhorar o WebGPU para processar modelos de ML. Ou então todo mundo deveria usar o mesmo LLM open source
    • O Google é como outra bactéria qualquer: aponta seu flagelo para onde tem dinheiro e vai nessa direção. Não sei por que alguém ainda acha que o Google vai fazer algo bom pela web ou pela humanidade
    • Discordo fortemente de “não deveria ser possível verificar o navegador”. O setor de IA rasgou completamente o consenso social pré-COVID em torno de anti-scraping e anti-botting
      Virou senso comum que robots.txt não é exigência obrigatória e pode ser totalmente contornado, transformando a web aberta praticamente numa dark forest
      É bem provável que surjam formas de verificar que uma sessão do navegador não foi adulterada ou é “trusted”. É péssimo, mas em parte foi algo que nós mesmos provocamos
    • Quanto à preocupação com fingerprinting, imagino que tanto no Chrome quanto, obviamente, no Firefox haverá uma opção de “nunca baixar LLM e desativar todas as funções de LLM”
      É possível que um site envie solicitações pequenas a um LLM para fingerprintar o próprio modelo, mas se isso puder ser desligado, não me parece um grande problema
      Num plano mais amplo, existe a preocupação de que “a plataforma web não deveria poder fazer isso”. Nessa visão, mesmo que o usuário possa desligar, ainda surgiriam sites do tipo “sem LLM, navegador não suportado”, e isso pioraria a web
      Mas aí no fim essa é uma decisão do operador do site de desligar o site na ausência de LLM, não culpa da plataforma ou do mantenedor por criar o recurso. É parecido com algo funcionar bem no Firefox, mas o suporte ser desativado só porque testar dá trabalho
      A web é a plataforma de aplicações mais bem-sucedida do mundo num cenário em que ela não compete com PDF, e sim com SwiftUI. A ideia de “manter a web estática como está” é fantasia; a escolha real é adaptar a web às necessidades mutáveis dos usuários ou deixar a web fracassar e SwiftUI ou WinUI preencherem esse espaço. A segunda opção é muito pior
    • Lendo as respostas desta thread, percebi algo: eles vão fazer isso de qualquer forma, e pessoas que já dependem de LLM ou não têm capacidade de avaliar direito vão elogiar
      https://news.ycombinator.com/item?id=47960596
      A conclusão é que chegou a hora de seguir em frente. Precisamos pensar em formatos melhores para troca de informação online e reprodução de mídia do que o navegador web. Se nós somos o produto, então as ferramentas que usamos também não deveriam agir como proxies que desviam furtivamente receita de anúncios para soberanos não confiáveis; isso deveria estar refletido de forma direta

  • Quanto mais penso nisso, mais acabo concordando com o lado do design de API do Google desta vez
    O acoplamento forte entre prompt e modelo é uma preocupação real e um problema do dia a dia. Mas, se a solução for uma API que acople ainda mais o prompt avaliado ao modelo presente no navegador do usuário, logo teremos situações do tipo “nosso prompt só foi testado no Gemini, então este site exige Chrome”
    Pior ainda seria “não é possível identificar qual modelo de IA está em uso”. Se um site feito em 2026 não for atualizado até 2030, isso é totalmente plausível
    Isso também se conecta ao problema dos termos mencionado ao fundo pelo engenheiro da Mozilla. Se quisermos que existam navegadores em que você não precise aceitar os termos de modelos de IA específicos — por exemplo, navegadores usando bons modelos open source — então é melhor impedir o fingerprinting de Big Models
    Claro, muitos sites vão fazer chamadas como isChrome() de qualquer maneira. Ainda assim, em geral sou contra mudanças que ampliem as formas de fingerprinting do navegador. O benefício de manter o modelo anônimo é maior do que a desvantagem de, raramente, surgirem saídas estranhas por pequenas diferenças entre modelos como Gemini e Qwen

  • Não entendo por que o Google continua gastando recursos enormes para enfiar tralha no navegador e transformá-lo num Homermobile, em vez de corrigir fraquezas estruturais de tantas coisas que os navegadores já fazem
    Por que não focar no básico que melhoraria a qualidade de vida em toda a plataforma web, de blogs estáticos a e-commerce e webapps de ponta
    https://simpsons.fandom.com/wiki/The_Homer

    • O Google não faz o Chrome para criar uma web melhor. Fazer um bom navegador por si só é gastar bilhões de dólares em goodwill, e o objetivo do Chrome é ser a plataforma que substitui o sistema operacional do usuário quando ele faz qualquer coisa no dispositivo
      Eles tentam isso diretamente com Android e ChromeOS, mas o Chrome também faz com que até o usuário médio de ambientes como Windows passe a maior parte do tempo dentro do mundo do Google
    • Para ser promovido no Google, você precisa lançar a prompt API
    • O fato de não implementar a prompt API faria com que recursos passassem a ser investidos em outras coisas que antes não eram prioridade? Isso me parece uma false dichotomy

  • Vejo fortemente as LLMs atuais e API harness como algo ainda não maduro o bastante, do ponto de vista técnico, para esse tipo de API entrar em um padrão
    Ainda assim, se for para fazer, no mínimo deveria ser uma permissão de opt-in por site, e deveria haver um jeito de identificar para qual modelo o prompt está sendo enviado. Até pequenos ajustes no prompt de sistema fazem parte dessa identidade
    Como usuário, preciso ter confiança de que, ao visitar um site qualquer, não vou ser fingerprintado por essa API sem permissão
    Como desenvolvedor, preciso saber quais modelos os usuários estão usando para poder optar por criar prompts específicos por modelo

  • “Espera-se cada vez mais que navegadores e sistemas operacionais tenham acesso a modelos de linguagem”? Sério mesmo?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • Acho que a direção está invertida. Não quero que o SO ou o navegador tenham acesso a LLM, mas quero que o LLM tenha acesso ao navegador ou ao SO, e isso já está acontecendo
      Então bastaria fornecer interfaces para LLM que venham desativadas por padrão e que o usuário possa ligar quando quiser
      Assim, você também poderia escolher qual LLM provider usar, sem ficar preso ao LLM que a Apple colocou no SO. Por exemplo, eu gostaria que o Claude também pudesse acessar as coisas às quais o Apple Intelligence tem acesso
    • Eu escrevi aquela frase originalmente, mas não imaginei que fosse ser entendida assim. Não queria dizer expectativa de usuários ou desenvolvedores, e sim a tendência da indústria de fornecedores de SO e navegadores embutirem ou se prepararem para LM
      Agora talvez já dê até para trocar “espera-se que tenham acesso” por “estão sendo embutidos”. Parece que muita gente está se confundindo, então seria bom se a equipe que mantém o projeto atualizasse isso
    • macOS, iOS e Windows têm APIs de modelo local para desenvolvedores de terceiros, e o Chrome também está experimentando isso. O Firefox gera alt-text com modelo, mas não oferece API
      Em teoria isso é útil. Se desenvolvedores puderem depender de modelos locais, tudo fica mais private e decentralized, e diminui a necessidade de mandar dinheiro para AWS ou Anthropic. Também existem usos de baixo risco que só fazem sentido se for local, offline e gratuito
      Mas, na prática, quase não vi adoção de Apple Foundation Models em apps nativos. Tenho curiosidade se devs de Mac/iOS têm algo a compartilhar
    • IA dá um poder enorme a pessoas que só sabem fazer bikeshedding. A própria IA provavelmente também é um bikeshed, mas há alguns usos legítimos, e ela também dá força para empurrar ideias inúteis por mais tempo e com mais barulho do que a oposição
      Agora tudo parece cada vez mais esperar um bikeshed. CVE incluído
    • Pelo visto a superfície de API do navegador ainda não é obscenamente ampla o suficiente

  • O bom dos protocolos abertos é que você não precisa apoiar nem usar uma implementação específica, mas mesmo assim o monopólio dos navegadores continua sendo um dilema
    Existem bons projetos como ungoogled chromium e Tor, mas o maior problema continua sendo a falta de uma voz e de projetos conectados ao grande público, voltados para a pessoa comum
    Muitos usuários que não entendem muito simplesmente não ligam para a causa nem para a forma de comunicar a mensagem, e reagem mais a coisas “divertidas” e com menos atrito do que a liberdade e controle
    Como resolver isso? Como fazer o navegador voltar a ser nosso, das pessoas e para as pessoas? Sempre que penso nisso, só bate tristeza

    • Compilar o navegador por conta própria piora ainda mais. Se você quiser Spotify ou Netflix, vai precisar de Widevine com attestation, e no fim terá de pagar o Google
      Se a string do Browser Agent não for Chrome ou Firefox, você toma CAPTCHA infinito da Cloudflare ou 403
    • É preciso começar aprendendo APIs de plataforma, em vez de enfiar Chrome dentro de aplicativos “nativos”
      Depois disso, criar aplicações web com base em padrões web, não no que o Chrome faz, e parar de reclamar quando Firefox e Safari não acompanham
    • É simples: basta usar leis antitruste para dividir todas as grandes empresas de tecnologia. Elas são os robber barons do nosso tempo
    • Infelizmente, a resposta quase sempre é financiamento público substancial
    • Já existem navegadores decentes, e a pessoa média usa Chrome. Quem se importa migra para os primeiros. O que exatamente precisa ser resolvido?
      Você diz que é preciso um projeto que alcance a pessoa média, mas ao mesmo tempo diz que ela quer menos atrito do que liberdade e controle. Há uma contradição aí. A pessoa média se conecta mais com less friction do que com controle

  • Fico me perguntando qual é o caso de uso dessa API
    Minha experiência ao rodar um LLM local é subir um llama-server e, se necessário, rodá-lo em outra máquina, depois configurar outros aplicativos para apontarem para esse servidor compatível com OpenAI em vez de OpenAI ou serviço parecido
    Não quero que o navegador crie ou execute uma instância de LLM. Talvez aquela máquina não tenha capacidade nem folga para rodar uma instância de LLM

  • Fico me perguntando se isso é a diferença entre uma geração mais nova que já não vive sem LLM e uma geração mais velha que não quer precisar de um supercomputador só para rodar um navegador invasivo à privacidade
    Para mim, isso soa como o ponto em que as pessoas começam a buscar e desenvolver alternativas ao navegador/web

    • Isso não significa que a Mozilla tenha adotado uma posição contra IA
      Ela apenas explicou, de forma clara e lógica, por que a API proposta, no formato atual, é ruim para a interoperabilidade da web
    • Acho que a oposição aqui não tem nada a ver com gostar ou não de LLM. A questão é se esta proposta específica de API da web aberta é viável
      Pessoalmente, eu uso LLM para auxílio de programação e automação residencial, mas não acho que essa API seja boa para a web
    • Pela minha experiência, jovens em geral odeiam IA
    • Fugindo um pouco do assunto, acho que o que precisa ser repensado é menos a interface do navegador e mais o próprio conceito de sistema operacional
      Não sei qual é a resposta certa, mas depois de usar Niri/Wayland, GNOME, Windows e Mac, nunca mais volto para desktop non-tiling nem para workflow de gerenciamento de janelas que não seja centrado no teclado
    • O navio do “navegador invasivo à privacidade que exige supercomputador” já partiu em 2008