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

 (github.com/mozilla)
2 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A Prompt API, que expõe modelos de linguagem no navegador como uma Web API, pode ser útil em uma forma genérica, mas incentiva implementações ajustadas ao comportamento específico de cada modelo, ampliando os riscos de interoperabilidade
  • Se desenvolvedores ajustarem prompts e recursos para implementações específicas, como o Phi-4-mini do Edge, pode haver queda de qualidade ou bloqueio de acesso ao site em outros navegadores ou modelos
  • A Mozilla considera que, em vez de ser lançada diretamente como Web API, 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 caminhos iniciais de feedback
  • Se system prompts se espalharem ajustados às quirks de um modelo específico, novos modelos também podem parecer ruins, e navegadores podem sofrer pressão para adotar modelos do Google ou modelos compatíveis com essas quirks
  • O lado do 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: a Prompt API pode ser útil em uma forma genérica, mas incentiva comportamentos específicos por modelo, ampliando os riscos de interoperabilidade
  • Desenvolvedores podem ajustar prompts e recursos a um modelo específico e, se criarem para uma implementação 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 lançar isso diretamente como Web API, seria melhor validar por mais tempo em userland; a trial web extension API da Mozilla e a proposta de web extension do grupo Web Machine Learning funcionariam como canais iniciais de coleta de feedback
  • Com base nas discussões relacionadas e na #1067, a posição sobre a Prompt API foi marcada como negative

Por que preferir Web Extension em vez de Origin Trial

  • Escolha de modelo e timing de padronização

    • A capacidade de escolher o modelo exato em um model hub é tratada como central, porque se trata de uma funcionalidade da página e porque o navegador não deve escolher um modelo específico
    • Essa capacidade pressupõe detalhes de implementação de uma área que muda rápido 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 testar recursos 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 normal da web; aqui, isso se aplica a shared cross-origin storage
    • Esse raciocínio segue lógica semelhante à usada em Adicionar posição gated por Add-On ao WebMIDI #704 em outro contexto
    • Essa proposta de extension expõe à página uma API parecida com a Prompt, usando inferência local e modelos definidos pelo desenvolvedor para obter um repositório compartilhado de modelos e feedback inicial dos usuários

O risco de endurecer em torno de um único modelo

  • System prompts e quirks de modelo

    • System prompts tendem a ser ajustados repetidamente para combinar com a quirk do modelo em uso
    • Em um system prompt para gerar textos de orientação de automação residencial, o modelo Gemini inicialmente respondia de forma muito americana, o que não combinava com a voz de um alto-falante britânico
    • Ao adicionar ao system prompt que ele falava com voz britânica, surgiram respostas como “a'waight guv'nor apples and pears”, uma imitação britânica americanizada, e foram necessários novos ajustes para reduzir isso e aproximar mais da fala britânica real
    • Correções feitas para um modelo podem virar correção excessiva em outro, e o problema aumenta em formatos de saída como voice com branding ou formatos que não podem ser expressos com JSON schema e regex

  • Carga de novos modelos e atualizações do navegador

    • Se system prompts ajustados às quirks de modelos existentes se espalharem, modelos novos e melhores da concorrência também podem parecer ruins para desenvolvedores e usuários
    • Mozilla e Apple podem acabar pressionadas a licenciar modelos do Google ou usar modelos compatíveis com as quirks dos modelos do Google em nome da interoperabilidade
    • Pelo mesmo motivo, até o Chrome pode ter dificuldade para atualizar seus próprios modelos

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

    • Desenvolvedores podem 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 o 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'
    • Desenvolvedores poderiam criar conjuntos de system prompts para modelos específicos e bloquear modelos desconhecidos ou avisar o usuário de que a qualidade de saída pode ser menor
    • Isso seria visto como um retorno indesejado ao code branching do início dos anos 2000

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

  • Segundo a documentação do Chrome, antes de usar a Prompt API é preciso reconhecer a Google Generative AI Prohibited Uses Policy
  • Partes dessa política cobrem um escopo além da lei, incluindo itens proibidos como “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 uma API da plataforma web exija regras de uso por UA, porque isso pode virar precedente para que mais APIs tragam regras específicas por UA
  • Se um usuário clicar em “summarize” em um comentário de artigo em um site e o resultado violar a política do Google, não fica claro se a responsabilidade é do usuário que clicou no botão, do autor do comentário que escreveu o conteúdo em violação, ou do dono do site que criou o recurso que envia esse comentário ao LLM do 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 do dono do modelo; um modelo desconhecido pode significar termos desconhecidos, então bloquear o uso pode parecer uma escolha racional
  • Não há base para um navegador impor esses termos a desenvolvedores de sites, e há também a linha de raciocínio de que esse problema de política deve ser tratado separadamente da proposta da API em si

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

  • O lado da Chrome Prompt API compartilhou o blink-dev I2S e a atualização sobre riscos de interoperabilidade e compatibilidade no ChromeStatus
  • Há o desejo de manter a participação e as discussões no WebML CG e de continuar experimentos posteriores, como os de sampling parameters interoperáveis
  • O Chrome afirma estar motivado a tornar o Language Model fornecido pelo navegador e pelo OS uma opção útil para desenvolvedores e usuários da web, preservando ao mesmo tempo a saúde de longo prazo e a neutralidade da plataforma web
  • A superfície da Prompt API mostrou algum grau de compatibilidade tanto com modelos do Google quanto da Microsoft, e restrições objetivas de resposta estão sendo aplicadas para adequar a saída a JSON schema ou regex conhecidos
  • Essas restrições são usadas como mitigação para reduzir a necessidade de hacks específicos por modelo ao lidar com saídas imprevisíveis
  • Projetos downstream do Chromium estão explorando modelos alternativos e backends de framework, incluindo o trabalho da Microsoft de integração com Android MLKit e a prototipagem inicial da integração com modelos fundacionais da Apple
  • Durante a fase de trial da API, várias versões de modelo foram distribuídas experimentalmente; atualizações e melhorias dos modelos continuam necessárias, e também está sendo explorado suporte aos Gemma 4 open models mais novos
  • Também estão sendo explorados categorical sampling modes para ajustar comportamentos mais interoperáveis em arquiteturas de base diferentes
  • O texto de Interoperability and Compatibility no blink-dev afirma que a variabilidade de comportamento e resposta é uma expectativa bem conhecida para desenvolvedores que usam essa tecnologia e que essa API busca um framework interoperável para um acesso consistente da plataforma web entre navegadores e modelos

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

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

  • Itens listados como base

    • Uma thread no GitHub com 2 respostas positivas
    • Um post único no X
    • Um post de blog que não existe mais, em estado Server Not Found
    • Um post de blog ainda disponível
    • A pesquisa aparentemente perguntava a desenvolvedores se tudo bem essa API existir em extensions, sem deixar explícitos os números nem o público da pesquisa
    • O post de blog removido foi compartilhado em versão preservada por um link do Wayback Machine
    • Mesmo que a documentação destaque fortemente “o que não deve ser assumido” e “o que pode ser assumido”, não está claro se, seguindo essas recomendações, sobra uma utilidade real ampla para a API
    • Na prática, ainda é possível depender em algum grau do comportamento do modelo específico testado e, se esse for o modelo do Chrome, o site pode exibir um aviso recomendando usar a versão mais recente do Chrome
    • Continua sendo um problema o fato de o Google identificar amplamente uma área inacabada e ainda assim considerar que as mitigações atuais bastam para shipping

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

  • Automação de navegador e Lynx mode

    • Havia a linha de raciocínio de que a maior parte do trabalho já era possível com Hermes Agent e Qwen3.6, e que seria melhor focar em browser automation API e no Lynx mode para chat do que na Prompt API
    • Em alguns fluxos de trabalho, uma pessoa faz login no site e usa uma extensão AJAX para tornar arquivos visíveis, depois o agent usa chromedriver/webdriver para baixar documentos e fazer tagging e resumo
    • Esse fluxo poderia ser integrado dentro do navegador sem shell POSIX externo
    • O chat em Lynx mode expõe rapidamente o que os agents veem e economiza recursos dos dois lados por não baixar nem renderizar todos os assets de mídia
    • Também entram nessa discussão um tagging de robots mais granular em nível de HTML, handoff entre o shell do Lynxmode e navegadores existentes, e uma forma de mostrar seletivamente links no estilo antigo do Google AdWords em navegadores dirigidos por agents

  • Open web e FOMO

    • Houve a objeção de que a open web não compete da mesma forma que chat bot super apps e não vai desaparecer
    • Também apareceu a posição de que, em vez de FOMO contínuo, seria melhor perguntar primeiro o que se quer representar
    • Não houve concordância com o temor de que, se a web não conseguir dar suporte rápido e eficiente a agentic computing como antes falhou em suportar plenamente o paradigma de mobile apps, commerce e journalism possam migrar para fora da open web

  • 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 de experimentação, aprendizado com erros e promoção da concorrência
    • Para avaliar danos reais no futuro, seria preciso definir resultados concretos; nesse contexto, foi considerado útil comparar decisões controversas de shipping de APIs, como EME, com seus resultados reais 5 a 10 anos depois
    • O dano de sites endurecerem em torno de um modelo específico do Google poderia ser avaliado pelo número e pelo porte de site compat bugs quando outros navegadores lançarem suporte, e pela natureza dos bugs quando o Chrome atualizar o modelo
    • Surgiu a ideia de diferenciar bugs de “tornar o modelo mais inteligente” dos de “preservar quirks estranhas” e reuni-los com labels em webcompat.com
    • Segundo o blink-dev I2S, o Edge também está lançando essa API com outro modelo, então já há dados iniciais disponíveis
    • No caso das preocupações com TOS, a métrica de dano seria se houve processos ou ameaças reais por violações, e surgiu a ideia de reunir esse tipo de evidência em registro

  • Mitigação posterior e resposta do Chrome

    • A abordagem de verificar os danos potenciais na prática faz sentido, mas houve a objeção de que ela só é útil se houver mitigação significativa disponível depois que o dano acontecer
    • Quando um site endurece em torno de um modelo específico do Google, foram listadas como perguntas opções como unship da feature, mudanças no modelo que quebrem prompts de site excessivamente ajustados, rotação aleatória de modelos e padronização aberta dos pesos de modelos on-device
    • Apareceu a posição de que, se surgirem evidências de que outros navegadores precisem copiar quirks estranhas do modelo do Chrome, então, da posição de liderança no Chromium, pressionariam o Chrome a quebrar essas quirks
    • Foi citado como precedente o caso em que o GMail mobile dependia de quirks bugadas de border image do WebKit; quando o Firefox sentiu necessidade de copiar isso, o Chrome foi corrigido de forma a quebrar o GMail, e o GMail foi atualizado rapidamente sem que os usuários percebessem

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
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