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

 (github.com/mozilla)
2 puntos por GN⁺ 3 시간 전 | 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 implementaciones concretas como Phi-4-mini de Edge, puede haber degradación de calidad o bloqueo de acceso al sitio en otros navegadores o modelos
  • Mozilla considera que, en lugar de enviarla directamente como API web, debería pasar por más validación en userland, y plantea su trial web extension API y la propuesta de web extension del grupo Web Machine Learning como vías iniciales para recibir retroalimentación
  • Si los system prompts se difunden ajustados a los quirks de un modelo específico, los modelos nuevos también podrían verse mal, y podría generarse presión para que los navegadores incorporen modelos de Google o modelos compatibles con esos quirks
  • Del lado de Chrome se propusieron mitigaciones como 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 aparece como negative

Evaluación negativa de Mozilla sobre la Prompt API

  • La Prompt API fue revisada en Mozilla standards-positions tras el 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 de forma general puede ser útil, pero fomenta el comportamiento específico por modelo, aumentando los riesgos de interoperabilidad
  • Los desarrolladores pueden ajustar prompts y funciones para un modelo concreto, y si apuntan a implementaciones como Phi-4-mini de Edge, la calidad puede caer o el acceso al sitio puede bloquearse en otros navegadores o modelos
  • En vez de lanzarla directamente 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 sirven como rutas iniciales para recopilar feedback
  • Con base en esa discusión y en #1067, la postura sobre la Prompt API quedó marcada como negative

Por qué prefirieron Web Extension sobre Origin Trial

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

    • La capacidad de elegir el modelo exacto desde un model hub se considera clave porque es una función a nivel de página y porque el navegador no debería elegir un modelo específico
    • Esta capacidad asume detalles de implementación de un área que cambia rápidamente, y todavía no se considera lista para estandarizarse
    • Las extensiones permiten explorar rápidamente patrones de uso reales más allá del alcance actual de la propuesta, y ofrecen una forma de bajo costo para experimentar funciones entre navegadores sin el costo de coordinación de alinear tres motores en semánticas todavía no consolidadas

  • Límites visibles para el usuario

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

El riesgo de fijarse en un solo modelo

  • System prompts y quirks del modelo

    • Los system prompts tienden a ajustarse repetidamente a los quirks del modelo con el que se está trabajando
    • En un system prompt para generar textos de guía de automatización del hogar, el modelo Gemini al principio respondía de forma muy estadounidense, lo que no encajaba con una voz de altavoz británica
    • Al agregar al system prompt que hablara con una voz británica, produjo una imitación británica americanizada como “a'waight guv'nor apples and pears”, y fue necesario seguir ajustándolo para bajarlo hacia algo más cercano al británico real
    • Una corrección pensada para un modelo puede convertirse en sobrecorrección en otro, y el problema crece con outputs como voces con branding o formatos de salida que no pueden expresarse con JSON schema o expresiones regulares

  • Carga de nuevos modelos y actualizaciones del navegador

    • Si se difunden ampliamente system prompts ajustados a los quirks de modelos existentes, incluso modelos competidores nuevos y mejores podrían verse mal para desarrolladores y usuarios
    • Mozilla y Apple podrían verse presionados a licenciar modelos de Google o a incluir modelos compatibles con los quirks de los modelos de Google para mantener la interoperabilidad
    • Chrome también podría tener dificultades para actualizar sus propios modelos por la misma razón

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

    • Los desarrolladores pueden crear un modelo con LanguageModel.create() y 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 del modelo, nombre, versión y empresa de origen
    • Un ejemplo de retorno es 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Los desarrolladores podrían crear paquetes de system prompts para modelos específicos y bloquear modelos desconocidos o avisar a los usuarios que la calidad de salida puede ser baja
    • Se considera que esto sería volver a una forma de code branching de principios de los 2000 que debería evitarse

Problemas de política de Google y 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 un alcance que va más allá de la ley, e incluye como prohibido “la generación o distribución de contenido que promueva contenido sexualmente explícito” y “la promoción de afirmaciones engañosas relacionadas con gobiernos o procesos democráticos”
  • No es deseable que las APIs de la plataforma web exijan reglas de uso específicas por UA, porque podría sentar un precedente para que más APIs carguen reglas específicas por agente de usuario
  • Si un usuario hace clic en “summarize” en los comentarios de un artículo en un sitio web y el resultado viola la política de Google, no está 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 web 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 puede implicar términos desconocidos, así que bloquear su uso puede parecer una decisión razonable
  • También existe la idea de que un navegador específico no tiene base para imponer este tipo de términos a los desarrolladores de sitios web, y que este problema de política debería tratarse por separado de la propuesta de API en sí

Actualizaciones y mitigaciones del lado de Chrome

  • El equipo de Chrome Prompt API compartió el blink-dev I2S y la actualización en ChromeStatus sobre riesgos de interoperabilidad y compatibilidad
  • Quieren mantener la participación y discusión en WebML CG, junto con experimentos posteriores como los sampling parameters interoperables
  • Desde Chrome explican que su motivación es convertir el Language Model provisto por el navegador y el OS en una opción útil para desarrolladores web y usuarios, manteniendo la salud y neutralidad de largo plazo de la plataforma web
  • La superficie de la Prompt API ha mostrado cierto grado de compatibilidad tanto con modelos de Google como de Microsoft, y se están aplicando restricciones objetivas de respuesta para hacer que la salida siga JSON schema o regex conocidos
  • Estas restricciones se usan como mitigación para reducir la necesidad de hacks específicos por modelo al lidiar con salidas impredecibles
  • Los proyectos downstream de Chromium 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 los foundational models de Apple
  • Durante la fase de prueba de la API se desplegaron experimentalmente varias versiones de modelos, y sigue siendo necesario actualizar y mejorar los modelos, además de explorar soporte para los Gemma 4 open models más recientes
  • También se están explorando categorical sampling modes para afinar un comportamiento más interoperable entre distintas arquitecturas base
  • El texto de Interoperability and Compatibility en blink-dev señala que la variabilidad en comportamiento y respuestas es una expectativa conocida para los desarrolladores que usen esta tecnología, y que esta API apunta a un marco de interoperabilidad para un acceso consistente de 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 posición de los desarrolladores web como “Strongly positive” y enlaza como base el stakeholder feedback del explainer
  • Esa base se considera poco alineada con una evaluación de “Strongly positive”

  • Elementos listados como evidencia

    • Un thread de GitHub con 2 respuestas positivas
    • Un post individual en X
    • Un post de blog que ya no existe, con estado Server Not Found
    • Un post de blog que todavía existe
    • Una encuesta que aparentemente preguntó a desarrolladores si estaba bien que esta API existiera en extensiones, sin especificar cifras ni población encuestada
    • El post desaparecido fue compartido en una versión preservada mediante Wayback Machine
    • Aunque la documentación marque en grande “lo que no se debe asumir” y “lo que sí se puede asumir”, no queda claro si, siguiendo esas recomendaciones, el API conserva suficiente utilidad práctica
    • En la práctica, sí podría dependerse hasta cierto punto del comportamiento del modelo específico probado, y si ese modelo es el de Chrome, un sitio podría terminar mostrando un aviso para usar la versión más reciente de Chrome
    • Sigue siendo problemático que Google identifique ampliamente un área todavía inmadura, pero aun así considere que las mitigaciones actuales bastan para shipping

Discusión en comentarios: alternativas, medición de daños y mitigación posterior

  • Automatización del navegador y modo Lynx

    • Con Hermes Agent y Qwen3.6 fue posible hacer la mayoría de las tareas, y hay una línea de opinión que cree que debería prestarse más atención a una browser automation API y a un modo Lynx para chat que a la Prompt API
    • Algunos flujos de trabajo consisten en que una persona inicia sesión en un sitio web y hace visibles archivos mediante una extensión AJAX, tras lo cual un agent usa chromedriver/webdriver para descargar documentos, etiquetarlos y resumirlos
    • Este enfoque podría integrarse dentro del navegador sin un POSIX shell externo
    • El chat en modo Lynx expone rápidamente lo que ven los agents y evita descargar o renderizar todos los assets multimedia, ahorrando recursos de ambos lados
    • También se mencionan etiquetado robots más detallado a nivel HTML, handoff entre un shell Lynxmode y un navegador tradicional, y una forma de mostrar selectivamente enlaces estilo Google AdWord old-school dentro de un navegador guiado por agents

  • Web abierta y 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 vaya a desaparecer
    • También se plantea que, antes que dejarse llevar por el FOMO continuo, hace falta preguntarse qué se quiere representar realmente
    • Existe una corriente que no coincide con la preocupación de que, si la web no logra soportar agentic computing de forma rápida y eficaz como no pudo soportar del todo el paradigma de apps móviles, entonces el comercio o el periodismo se irán fuera de la web abierta

  • Shipping en Chromium y medición del daño

    • Uno de los blink API owner approvers de Chromium comparte las preocupaciones de Mozilla, pero prefiere un camino que fomente la experimentación, el aprendizaje a partir de errores y la competencia
    • Para evaluar daños reales en el futuro, habría que definir resultados concretos, en un contexto donde comparar decisiones polémicas de shipping de APIs como EME con sus efectos reales 5 a 10 años después ha sido útil
    • El daño de que los sitios se fijen en un modelo específico de Google puede medirse por el número y magnitud de site compat bugs cuando otros navegadores hagan shipping, así como por la naturaleza de los bugs cuando Chrome actualice el modelo
    • Se propone distinguir si un bug busca “hacer el modelo más inteligente” o “preservar un quirk raro”, y recopilar esos casos con etiquetas en webcompat.com
    • Según el blink-dev I2S, Edge también está lanzando esta API con otro modelo, por lo que ya existen datos iniciales
    • La métrica de daño para las preocupaciones sobre TOS sería si efectivamente hubo demandas o amenazas reales por violaciones, y se propone reunir evidencia de eso como registro

  • Mitigación posterior y respuesta de Chrome

    • La idea de verificar daños posibles en la práctica es razonable, pero hay una objeción: solo sirve si existen mitigaciones significativas una vez que el daño ocurre
    • Cuando un sitio ya quedó fijado a un modelo específico de Google, se plantean como preguntas opciones como hacer feature unship, cambiar el modelo para romper prompts de sitio demasiado ajustados, rotación aleatoria de modelos u open standardización de los pesos de modelos on-device
    • Si aparece evidencia de que otros navegadores tienen que copiar quirks extraños del modelo de Chrome, se afirma que desde la posición de liderazgo de Chromium se presionaría para que Chrome rompa ese quirk
    • También se menciona el precedente de que Mobile GMail dependía de buggy WebKit border image quirks y, cuando Firefox sintió la necesidad de copiarlos, se corrigió Chrome de una forma que rompió GMail; luego GMail se actualizó rápidamente y los usuarios ni lo notaron

Lecturas relacionadas

1 comentarios

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