La oposición de Mozilla a la Prompt API de Chrome

 (github.com/mozilla)
6 puntos por GN⁺ 2026-05-01 | 1 comentarios | Compartir por WhatsApp
  • La Prompt API, que expone modelos de lenguaje dentro del navegador como una API web, puede ser útil en una forma general, pero incentiva implementaciones ajustadas al comportamiento específico de cada modelo, aumentando los riesgos de interoperabilidad
  • Si los desarrolladores ajustan prompts y funciones para una implementación concreta, como Phi-4-mini de Edge, pueden surgir caídas de calidad o bloqueos de acceso al sitio en otros navegadores o modelos
  • Mozilla considera que, en lugar de lanzarla directamente como API web, debería pasar por más validación en userland, y propone como rutas iniciales de retroalimentación una trial web extension API y la propuesta de web extension del grupo Web Machine Learning
  • Si los system prompts se difunden ajustados a los quirks de un modelo concreto, los modelos nuevos también podrían parecer peores, y eso podría presionar a los navegadores a incluir modelos de Google o modelos compatibles con esos quirks
  • Del lado de Chrome se propusieron como mitigaciones restricciones de respuesta basadas en JSON schema y regex, discusiones en WebML CG y pruebas con modelos alternativos, pero la postura de Mozilla sobre la Prompt API está marcada como negative

Evaluación negativa de Mozilla sobre la Prompt API

  • La Prompt API fue revisada en standards-positions de Mozilla después del intent-to-prototype de Blink, y el explainer enlaza al README de webmachinelearning/prompt-api
  • La retroalimentación de Mozilla es casi la misma que en Writing Assistance APIs #1067: una Prompt API en forma general puede ser útil, pero fomenta comportamientos específicos de cada modelo, aumentando los riesgos de interoperabilidad
  • Los desarrolladores podrían ajustar prompts y funciones para un modelo específico, y si apuntan a implementaciones como Phi-4-mini de Edge, eso podría degradar la calidad o bloquear el acceso al sitio en otros navegadores o modelos
  • En vez de lanzarla de inmediato como API web, debería validarse por más tiempo en userland; la trial web extension API de Mozilla y la propuesta de web extension del grupo Web Machine Learning servirían como vías iniciales para recopilar feedback
  • Con base en esas discusiones y en #1067, la postura sobre la Prompt API quedó marcada como negative

Por qué prefieren Web Extension sobre Origin Trial

  • Selección de modelos y momento de estandarización

    • La capacidad de elegir el modelo exacto desde un model hub se considera clave, tanto por ser una función dentro de la página como porque el navegador no elegiría un modelo específico
    • Esta capacidad parte de detalles de implementación en un área que cambia rápido, y aún no se considera lista para estandarizarse
    • Las extensiones ofrecen una forma de bajo costo para explorar rápidamente patrones de uso reales más allá del alcance actual de la propuesta, y para experimentar funciones entre navegadores sin el costo de coordinación que implicaría que tres motores publiquen una semántica todavía no consolidada

  • Límites visibles para el usuario

    • Instalar un add-on sirve como señal de que el usuario está saliendo de los límites normales de la web; aquí aplica a shared cross-origin storage
    • Esta evaluación sigue una lógica similar a la de Agregar ubicación Add-On Gated a WebMIDI #704 en otro contexto
    • Esa propuesta de extensión expone a la página una API similar a Prompt, y usa inferencia local y modelos elegidos por el desarrollador para obtener almacenamiento compartido de modelos y feedback inicial de los usuarios

El riesgo de quedar atados a un solo modelo

  • System prompts y quirks del modelo

    • Los system prompts tienden a reajustarse repetidamente para adaptarse a los quirks del modelo con el que se está trabajando
    • En un system prompt para generar instrucciones de automatización del hogar, el modelo Gemini respondía al principio de forma muy estadounidense, lo que no encajaba con una voz de altavoz británica
    • Al agregar al system prompt que hablara con voz británica, produjo algo como “a'waight guv'nor apples and pears”, una imitación británica estereotipada desde una perspectiva estadounidense, y fue necesario seguir ajustándolo para acercarlo a un tono británico más realista
    • Una corrección para un modelo puede convertirse en sobrecorrección en otro, y el problema crece en formatos de salida como voces con marca o formatos que no pueden expresarse con JSON schema o regex

  • Carga para modelos nuevos y actualizaciones del navegador

    • Si los system prompts ajustados a los quirks de modelos existentes se vuelven comunes, incluso modelos nuevos y mejores de la competencia podrían verse mal para desarrolladores y usuarios
    • Mozilla y Apple podrían terminar en una situación donde, por interoperabilidad, tengan que licenciar un modelo de Google o usar uno compatible con los quirks de los modelos de Google
    • Chrome también podría tener dificultades para actualizar sus propios modelos por la misma razón

  • Detección de model ID y ramificación por navegador

    • Los desarrolladores pueden crear un modelo con LanguageModel.create() y luego preguntar algo como model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') para obtener el ID, nombre, versión y empresa de origen del modelo
    • Un ejemplo de respuesta sería 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Los desarrolladores podrían preparar paquetes de system prompts para modelos específicos, y bloquear modelos desconocidos o avisar al usuario que la calidad de salida podría ser menor
    • Esto se ve como un regreso a la ramificación de código de principios de los 2000 que se debería evitar

La política de Google y el problema de neutralidad del modelo

  • Según la documentación de Chrome, antes de usar la Prompt API hay que aceptar la Google Generative AI Prohibited Uses Policy
  • Parte de esa política cubre alcances que van más allá de la ley; entre las prohibiciones están la “generación o distribución de contenido que promueva contenido sexualmente explícito” y la “promoción de afirmaciones engañosas relacionadas con el gobierno o procesos democráticos”
  • No es deseable que una API de la plataforma web exija reglas de uso por UA, y eso podría sentar un precedente para que más APIs queden sujetas a reglas específicas de cada UA
  • Si un usuario hace clic en “summarize” en los comentarios de un artículo dentro de un sitio web y el resultado termina violando la política de Google, no queda claro si la responsabilidad recaería en el usuario que hizo clic, el autor del comentario que escribió el contenido infractor o el propietario del sitio que creó la función que envía ese comentario al LLM del UA del usuario
  • Los desarrolladores podrían querer saber con qué LLM se están comunicando para cumplir los términos del modelo y evitar acciones legales del dueño del modelo; un modelo desconocido podría implicar términos desconocidos, por lo que bloquear su uso puede parecer una decisión razonable
  • También existe la línea de pensamiento de que ningún navegador tiene base para imponer este tipo de términos a los desarrolladores web, y que este problema de políticas debe tratarse aparte de la propuesta de la API en sí

Actualizaciones y mitigaciones del lado de Chrome

  • El equipo de Chrome Prompt API compartió el blink-dev I2S y una actualización en ChromeStatus sobre riesgos de interoperabilidad y compatibilidad
  • Quieren mantener la participación y las discusiones en WebML CG y continuar con experimentos posteriores, como sampling parameters interoperables
  • Desde Chrome explican que su motivación es mantener la salud y neutralidad a largo plazo de la plataforma web, mientras convierten los Language Model provistos por navegador y sistema operativo en una opción útil para desarrolladores web y usuarios
  • La superficie de la Prompt API mostró cierto nivel de compatibilidad tanto con modelos de Google como de Microsoft, y se están aplicando restricciones objetivas de respuesta para que la salida se ajuste a JSON schema o regex conocidos
  • Estas restricciones se usan como mitigación para reducir la necesidad de hacks específicos por modelo al manejar salidas impredecibles
  • Proyectos Chromium downstream están explorando modelos alternativos y backends de frameworks, incluyendo trabajo de integración con Android MLKit de Microsoft y prototipos iniciales de integración con modelos fundacionales de Apple
  • Durante la fase de trial de la API se distribuyeron experimentalmente varias versiones de modelos, y sigue siendo necesario continuar con actualizaciones y mejoras; también se está explorando soporte para Gemma 4 open models más recientes
  • También se están explorando categorical sampling modes para ajustar comportamientos más interoperables entre arquitecturas base diferentes
  • El texto de Interoperability and Compatibility en blink-dev señala que la variabilidad de comportamiento y respuesta es una expectativa ya conocida para los desarrolladores que usen esta tecnología, y que esta API apunta a un marco interoperable para un acceso consistente a la plataforma web entre navegadores y modelos

Fundamentos del apoyo de desarrolladores web y críticas al lanzamiento

  • El intent to ship de blink-dev marca la postura de los desarrolladores web como “Strongly positive” y enlaza como sustento el stakeholder feedback del explainer
  • Ese sustento se considera poco consistente con una evaluación de “Strongly positive”

  • Elementos listados como fundamento

    • Un hilo de GitHub con 2 respuestas positivas
    • Una sola publicación en X
    • Una entrada de blog que ya no existe, con estado Server Not Found
    • Una entrada de blog que sí sigue existiendo
    • La encuesta parece preguntar a desarrolladores si estaría bien que esta API existiera en extensiones, pero no especifica cifras ni el público objetivo
    • La entrada de blog desaparecida se compartió en una versión archivada en Wayback Machine
    • Aunque la documentación marque en grande qué “no se debe asumir” y qué “sí se puede asumir”, si se siguiera esa recomendación no queda claro si el API conservaría usos reales o si su utilidad quedaría demasiado limitada
    • En la práctica, sí puede dependerse hasta cierto punto del comportamiento del modelo específico probado, y si ese modelo es el de Chrome, un sitio podría mostrar un aviso recomendando usar la versión más reciente de Chrome
    • Sigue siendo problemático que Google identifique ampliamente un área todavía inmadura y aun así considere que las mitigaciones actuales bastan para shipping

Discusión en comentarios: alternativas, medición de daños y mitigaciones posteriores

  • Automatización del navegador y modo Lynx

    • Con Hermes Agent y Qwen3.6 se pudo hacer la mayoría de las tareas, y hay una línea que sugiere poner más atención en una browser automation API y en un modo Lynx para chat que en la Prompt API
    • Algunos flujos de trabajo consisten en que una persona inicia sesión en un sitio web y, mediante una extensión AJAX, hace visibles archivos; luego un agente usa chromedriver/webdriver para descargar documentos, etiquetarlos y resumirlos
    • Ese enfoque podría integrarse dentro del navegador sin depender de un POSIX shell externo
    • El chat en modo Lynx expone rápidamente lo que ven los agentes y ahorra recursos de ambos lados al no descargar ni renderizar todos los recursos multimedia
    • También se habla de etiquetado robots más fino a nivel HTML, handoff entre el shell de Lynxmode y navegadores tradicionales, y formas de mostrar selectivamente enlaces tipo Google AdWord de la vieja escuela en un navegador guiado por agentes

  • La web abierta y el FOMO

    • Hay una postura que rebate la idea de que la web abierta compita del mismo modo que las chat bot super apps, o que esté destinada a desaparecer
    • También se plantea que, antes de actuar por FOMO constante, conviene preguntarse primero qué se quiere representar
    • Existe una corriente que no comparte la preocupación de que, si la web no logra soportar agentic computing de forma rápida y eficaz como no logró soportar del todo el paradigma de apps móviles, entonces el comercio o el periodismo se irán fuera de la web abierta

  • El shipping de Chromium y la medición del daño

    • Uno de los approvers de blink API owner en Chromium dice compartir las preocupaciones de Mozilla, pero prefiere un camino de experimentación, aprendizaje a partir de errores y promoción de la competencia
    • Para evaluar daños reales más adelante, haría falta definir resultados concretos; se menciona que fue útil comparar decisiones polémicas de shipping de APIs como EME con sus resultados reales 5 a 10 años después
    • El daño de que los sitios queden atados a un modelo específico de Google podría medirse por el número y la escala de bugs de compatibilidad de sitio que enfrenten otros navegadores al lanzar soporte, y por la naturaleza de los bugs que aparezcan cuando Chrome actualice sus modelos
    • Se plantea distinguir si un bug busca “hacer el modelo más inteligente” o “preservar un quirk extraño”, y reunir evidencia etiquetada en webcompat.com
    • Según el blink-dev I2S, Edge también está lanzando esta API con otros modelos, así que ya existe datos iniciales
    • La métrica de daño para las preocupaciones de TOS sería si realmente hubo demandas o amenazas legales por violaciones, y se propone empezar a registrar esa evidencia

  • Mitigaciones posteriores y respuesta de Chrome

    • Se responde que el enfoque de verificar si el daño realmente ocurre es válido, pero solo sirve si después de ocurrido todavía existen mitigaciones significativas
    • Si los sitios quedan atados a un modelo específico de Google, se enumeran como preguntas opciones como hacer feature unship, cambiar el modelo para romper prompts de sitio excesivamente ajustados, rotar modelos al azar o estandarizar de forma abierta los pesos de modelos on-device
    • Si aparece evidencia de que otros navegadores deben copiar quirks extraños del modelo de Chrome, surge la postura de que, desde una posición de liderazgo dentro de Chromium, se presionaría a Chrome para romper ese quirk
    • También se recuerda el precedente de Mobile GMail, que dependía de quirks defectuosos de WebKit border image; cuando Firefox sintió la necesidad de copiarlos, Chrome corrigió su comportamiento aunque eso rompiera GMail, y GMail se actualizó tan rápido que los usuarios no lo notaron

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-05-01
Comentarios de Hacker News

  • El argumento en contra parece bastante claro: el fuerte acoplamiento entre prompt y modelo, y el problema de la neutralidad de modelo en los términos de uso
    Como en el caso personal de https://github.com/mozilla/standards-positions/issues/1213, al crear un system prompt para alertas de automatización del hogar, Gemini al principio respondía de forma demasiado estadounidense, y cuando se le indicó que hablara con voz británica, salió con algo como “a'waight guv'nor apples and pears”, una torpe imitación británica hecha por un estadounidense, así que hubo que ajustarlo más
    En ese proceso, el system prompt queda ajustado a un modelo específico, y como otros modelos tienen otros quirks, una corrección introducida para un modelo puede convertirse en sobrecorrección en otro

    • El resultado suena como si se burlara en adversarial mode
    • Si eso fuera una buena razón para no soportar capacidades de LLM, entonces la conclusión sería no ponerlas en ninguna API de plataforma. Pero ya se han añadido a muchísimas plataformas
      Que cada modelo sea distinto es una característica central de esta tecnología. Es parecido a que el tamaño del canvas cambie según el dispositivo o la orientación, a que la precisión de la geolocation API varíe, o a que las voces de Speech Synthesis cambien según el dispositivo
      Esto se parece menos a una crítica constructiva y más a un sentimiento anti-AI. Ahora mismo hace falta una UI de permisos, y tal vez algún día haya niveles de IQ como low/medium/high, pero a fin de cuentas los desarrolladores que sí se preocupan igual terminarán dependiendo en un 90% de un modelo específico
      Con el tiempo, cuando baje el rechazo a la AI y la gente vea que ayuda, que Firefox no tenga esta función podría verse como un fracaso en términos de autonomía de los datos personales. Si el problema son los TOU relacionados de Chrome, eso más bien sería una razón para que Firefox implemente esta función con términos de modelo que no tengan ese problema

  • No sabía quién había escrito la objeción, pero resultó ser el Googler de larga trayectoria del equipo de Chrome, Jake Archibald, que se fue a Mozilla y escribió una objeción a una API de Chrome. No sorprende que la crítica esté bien estructurada, y seguro le dio cierto alivio no tener que seguir la línea del partido esta vez

    • Gracias, pero yo diría que ni siquiera cuando estaba en Google seguía la línea del partido. Solo que eso le fue haciendo la vida cada vez más difícil internamente y al final se fue
      Por lo que cuentan quienes todavía siguen en el equipo, en ese aspecto la situación parece haber empeorado exponencialmente
    • Seguro conoce muy bien el repo de standards-positions, y se lee como una defensa típica de cuando Google intenta empujar algo sin suficiente consulta
      En vez de proponer cambios, va más por desecharlo entero, y si se desecha parece que esperan reescribirlo desde cero de forma colaborativa, sin partir desde la perspectiva del equipo de Google Chrome. Pero no recuerdo muchos casos en que eso haya salido bien, así que parecería mejor simplemente proponer modificaciones concretas

  • Estoy en contra de esto

    1. Se convierte en nueva información de fingerprinting, y como es difícil engañar a un fingerprinting script, puede abusarse para “verificación de dispositivo”. No debería ser posible “verificar” el navegador; cualquiera debería poder emular cualquier navegador
    2. Los LLM consumen mucha memoria y CPU, y considerando el precio actual de la RAM, actualizar también sale caro. Si los sitios web dependen de un modelo local, en dispositivos baratos van a funcionar lento
    3. La API parece ajustada a un LLM específico como OpenAI
    4. Podría sacar del mercado de navegadores a competidores que no tienen su propio modelo de AI. Si los sitios se construyen esperando el modelo Gemini de Google, podrían romperse en otros modelos o en navegadores de países sin modelo de AI, y no deberían existir navegadores de “primera” y “segunda” clase
      El explainer dice que los datos pueden procesarse localmente sin enviarse a ninguna parte, pero entonces queda la duda de por qué un modelo local de Google Gemini necesitaría una Prohibited Use Policy. ¿Por qué le importaría a Google un prompt y una respuesta que no puede conocer?
      El acceso a LLM offline en sí suena bien, pero no hace falta integrar un LLM al navegador para eso: los sitios pueden usar WebGPU o se puede mejorar WebGPU para procesar modelos de ML. O todos deberían usar el mismo LLM open source
    • Google, como otra bacteria cualquiera, solo agita su flagelo y va hacia donde huele dinero. No entiendo por qué alguien pensaría que Google va a hacer algo bueno por la web o por la humanidad
    • Estoy muy en desacuerdo con eso de que “no debería poder verificarse el navegador”. La industria de AI hizo pedazos el consenso social pre-COVID sobre anti-scraping y anti-botting
      Ya es conocimiento común que robots.txt no es un requisito obligatorio y puede esquivarse por completo, y eso prácticamente convirtió la web abierta en un dark forest
      Probablemente vamos hacia alguna forma de verificar que una sesión de navegador no fue alterada o que es “trusted”. Es horrible, sí, pero también en parte nos lo buscamos
    • Sobre la preocupación por el fingerprinting, asumiría que tanto Chrome como, por supuesto, Firefox tendrán una opción de “nunca descargar un LLM y desactivar todas las funciones de LLM”
      Es posible una vía donde el sitio mande una solicitud pequeña al LLM para fingerprinting del modelo mismo, pero si se puede desactivar, no me parece un gran problema
      Más ampliamente, aquí hay una preocupación del tipo “la plataforma web no debería poder hacer esto”. Desde esa postura, incluso si el usuario puede desactivarlo, se puede decir que surgirán sitios con cosas como “navegador no soportado porque no hay LLM” y que eso empeorará la web
      Pero al final esa sería una decisión del operador del sitio de apagar el sitio si no hay LLM, no culpa de la plataforma o del mantenedor que creó la capacidad. Es parecido a desactivar soporte en Firefox solo porque da flojera probarlo, aunque funcione bien allí
      La web es la plataforma de aplicaciones más exitosa del mundo, en un mundo donde compite no con PDF sino con SwiftUI. La idea de “mantengamos la web estática como está ahora” es una fantasía; la opción real es adaptar la web a las necesidades cambiantes de los usuarios, o que la web fracase y SwiftUI o WinUI llenen ese vacío. Lo segundo es mucho peor
    • Leyendo las respuestas en este hilo me di cuenta de algo: igual lo van a hacer, y ya hay gente que depende de LLM o que no tiene la capacidad de juzgar bien que lo va a aplaudir
      https://news.ycombinator.com/item?id=47960596
      La conclusión es que ya toca pasar página. Hay que pensar en formatos mejores que el navegador web para intercambiar información online y reproducir medios. Si nosotros somos el producto, las herramientas que usamos no deberían actuar también como proxies que desvían en secreto ingresos publicitarios hacia señores dominantes no confiables, sino reflejar ese hecho directamente

  • Mientras más lo pienso, más tiendo a estar del lado del diseño de API de Google esta vez
    El fuerte acoplamiento entre prompt y modelo es una preocupación real y un problema que se vive a diario. Pero si la solución es una API que acople aún más el prompt a evaluar con el modelo que está en el navegador del usuario, pronto acabaremos con situaciones como “nuestro prompt solo se probó en Gemini, así que este sitio necesita Chrome”
    Peor aún, podría volverse “no se puede reconocer el modelo de AI en uso”. Si un sitio creado en 2026 no se actualiza hasta 2030, es totalmente plausible
    Esto también se conecta con el problema de términos de uso que mencionó por detrás el ingeniero de Mozilla. Si queremos que existan navegadores en los que no haga falta aceptar los términos de un modelo de AI específico, por ejemplo navegadores que usen un buen modelo open source, conviene más impedir el fingerprinting de Big Models
    Claro, muchos sitios de todos modos harán llamadas como isChrome(). Aun así, en general me opongo a cambios que aumenten las formas de fingerprinting del navegador. La ventaja de mantener anónimo el modelo es mayor que la desventaja de que de vez en cuando salgan respuestas raras por pequeñas diferencias entre modelos como Gemini y Qwen

  • No entiendo por qué Google no dedica recursos masivos a arreglar debilidades estructurales de las muchísimas cosas que el navegador ya puede hacer, y en cambio sigue agregándole chucherías hasta volverlo un Homermobile
    ¿No podrían enfocarse en cosas básicas que mejoren la calidad de vida en toda la plataforma web, desde blogs estáticos hasta comercio electrónico y webapps de punta?
    https://simpsons.fandom.com/wiki/The_Homer

    • Google no hace Chrome para construir una mejor web. Hacer un buen navegador por el simple hecho de hacer un buen navegador sería gastar miles de millones de dólares en goodwill, y el objetivo de Chrome es convertirse en la plataforma que reemplace el sistema operativo del usuario cuando hace algo en su dispositivo
      Lo intentan directamente con Android y ChromeOS, pero Chrome logra que incluso el usuario promedio en entornos como Windows pase la mayor parte de su tiempo dentro del mundo de Google
    • Para ascender en Google hay que lanzar una prompt API
    • ¿Que no se implemente la prompt API haría que se inviertan recursos en otras cosas antes no prioritarias? Eso me parece una false dichotomy

  • Considero firmemente que los LLM y API harness actuales no son lo bastante maduros técnicamente como para que algo así entre en el estándar
    Aun así, si se va a hacer, como mínimo debería ser con permiso opt-in por sitio, y debería haber alguna forma de identificar a qué modelo se le está enviando el prompt. Incluso pequeños ajustes al system prompt deberían formar parte de esa identidad
    Como usuario, necesito la certeza de que al visitar cualquier sitio no me van a hacer fingerprinting con esta API sin mi permiso
    Como desarrollador, necesito saber qué modelo usan los usuarios para tener la opción de crear prompts específicos por modelo

  • ¿“Se espera cada vez más que navegadores y sistemas operativos accedan a modelos de lenguaje”? ¿De verdad?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • Creo que la dirección está equivocada. No quiero que el OS ni el navegador accedan a un LLM, pero sí quiero que el LLM acceda al navegador o al OS, y de hecho eso ya está pasando
      Así que bastaría con ofrecer una interfaz para LLM que venga apagada por defecto y que el usuario pueda activar cuando quiera
      Entonces uno también podría elegir qué LLM provider usar, sin quedar atado al LLM que Apple metió en el OS. Por ejemplo, quisiera que Claude pudiera acceder a las cosas a las que puede acceder Apple Intelligence
    • Yo escribí originalmente esa frase, y no imaginé que se malinterpretaría así. No quería decir que fuera una expectativa de usuarios o desarrolladores, sino hablar de la tendencia de la industria en que los vendors de OS y navegadores están integrando o preparando LM
      A estas alturas quizá se puede cambiar “se espera que accedan” por “se están integrando”. Parece que mucha gente se confunde, así que estaría bien que el equipo de mantenimiento del proyecto lo actualizara así
    • macOS, iOS y Windows tienen APIs de modelo local para desarrolladores third-party, y Chrome también está experimentando. Firefox genera alt-text con un modelo, pero no tiene API
      En teoría es útil. Si los desarrolladores pueden depender de modelos locales, es más private y decentralized, y también reduce la necesidad de enviar dinero a AWS o Anthropic. Al ser local, hay casos de uso de bajo riesgo que solo tienen sentido si funciona offline y gratis
      Pero en la práctica casi no he visto adopción de Apple Foundation Models en apps nativas. Me da curiosidad si los desarrolladores de Mac/iOS tienen algo que compartir al respecto
    • La AI les da un poder enorme a quienes solo saben hacer bikeshedding. Puede que la propia AI también sea un bikeshed, pero sí tiene usos legítimos, y además da poder para empujar ideas inútiles durante más tiempo y con más insistencia que la mera oposición
      Ahora todo parece esperar cada vez más bikeshed. Se espera el CVE
    • Parece que la superficie de APIs del navegador todavía no es lo suficientemente obscenamente amplia

  • Lo bueno de los protocolos abiertos es que no hace falta respaldar ni usar una implementación específica, pero aun así el monopolio del navegador sigue siendo un dilema
    Hay proyectos buenos como ungoogled chromium y Tor, pero el problema más grande es que faltan voces y proyectos conectados con el público masivo y con la gente promedio
    A muchos usuarios que no saben mucho les da igual la causa y la forma de comunicar el mensaje, y responden más a lo “divertido” y a la falta de fricción que a la libertad y el control
    ¿Cómo se resuelve eso? ¿Cómo hacemos que el navegador sea nuestro, de la gente y para la gente? Cada vez que pienso en eso, me da tristeza

    • Si compilas tu propio navegador, en realidad empeora. Si quieres Spotify o Netflix, necesitas Widevine con attestation, y al final tienes que pagarle a Google
      Si el Browser Agent string no es Chrome ni Firefox, te esperan CAPTCHAs infinitos de Cloudflare o 403
    • Hay que empezar por aprender las APIs de plataforma en vez de meter Chrome dentro de aplicaciones “native”
      Después, construir aplicaciones web basadas en estándares web en lugar de seguir lo que haga Chrome, y no quejarse de que Firefox y Safari no pueden seguirle el ritmo
    • Es simple. Hay que partir a todas las grandes tecnológicas con leyes antimonopolio. Son los robber barons de nuestra era
    • Lamentablemente, la respuesta casi siempre es financiamiento público sustancial
    • Los navegadores decentes ya existen, y la gente promedio usa Chrome. A quien le importa se cambia a uno de los primeros. ¿Qué problema hay que resolver?
      Dices que hace falta un proyecto que llegue a la gente promedio, pero al mismo tiempo que ellos quieren menos fricción más que libertad y control. Ahí hay una contradicción. La gente promedio conecta más con less friction que con control

  • Me pregunto cuál es el use case de esta API
    Mi experiencia al correr un LLM local es levantar llama-server, si hace falta correrlo en otra máquina, y luego configurar otras aplicaciones para que apunten a ese servidor compatible con OpenAI en vez de a OpenAI o a un servicio parecido
    No quiero que el navegador cree o ejecute una instancia de LLM, porque esa máquina puede no tener capacidad ni margen para correr una

  • Me pregunto si esta es la diferencia entre una generación joven que ya no puede vivir sin LLM, y una generación vieja que no quiere que le pidan hasta una supercomputadora para correr un navegador web que invade su privacidad
    A mí esto me suena al punto donde la gente empezará a buscar y desarrollar alternativas al navegador/web

    • Esto no significa que Mozilla haya publicado una postura contra la AI
      Lo que hizo fue explicar razones claras y lógicas de por qué la API propuesta, en su forma actual, es mala para la interoperabilidad web
    • Creo que la objeción aquí no tiene nada que ver con que te gusten o no los LLM. Se trata de si esta propuesta específica de API abierta para la web es viable
      Personalmente uso LLM para asistencia de código y automatización del hogar, pero no creo que esta API sea buena para la web
    • En mi experiencia, a la gente joven en general no le gusta la AI
    • Un poco aparte, pero creo que lo que necesita rehacerse está más cerca del concepto mismo de sistema operativo que de la interfaz del navegador
      No sé cuál sea la respuesta correcta, pero después de usar Niri/Wayland, GNOME, Windows y Mac, ya nunca volvería a un workflow de manejo de ventanas de escritorio no-tiling ni que no esté centrado en el teclado
    • El barco de los “navegadores que invaden la privacidad y necesitan una supercomputadora” ya zarpó en 2008