La visión de Mozilla para la evolución de la Web

23 de marzo de 2022

La misión de Mozilla es garantizar que Internet sea un recurso público global, abierto y accesible para todos. Creemos en una Internet que pone a las personas en primer lugar, donde las personas pueden dar forma a su propia experiencia y son empoderadas, seguras e independientes.

Internet en sí es una infraestructura de bajo nivel, una columna vertebral conectiva sobre la cual se construyen otras cosas. Es esencial que esta columna se mantenga saludable, pero tampoco es suficiente. La gente no experimenta Internet directamente. Más bien, lo experimentan a través de la tecnología, los productos y los ecosistemas construidos sobre él. El sistema de este tipo más importante es la Web, que es, con mucho, el sistema de comunicación abierto más grande jamás construido.

Este documento describe nuestra visión de la Web y cómo pretendemos alcanzar esa visión. No tenemos todas las respuestas hoy, y esperamos que esta visión evolucione con el tiempo a medida que identificamos nuevos desafíos y oportunidades. Damos la bienvenida a la colaboración, tanto para hacer realidad esta visión como para expandirla al servicio de nuestra misión.

Si bien este documento se enfoca en cuestiones técnicas, somos muy conscientes de que muchos de los problemas de la Web no pueden solucionarse únicamente con la tecnología. Más bien, la tecnología debe trabajar mano a mano con los cambios sociales y políticos para producir la Internet que queremos.

Nuestros Valores para la Web

Comenzamos examinando lo que hace que la Web sea especial. Aquí identificamos algunos valores clave que guían nuestro pensamiento. La Web en la práctica no siempre logra estos valores, pero creemos que reflejan lo mejor de la Web.

Franqueza

Todo el mundo puede acceder a la Web y utilizarla para llegar a otros.

Una fortaleza clave de la Web es que existen barreras de entrada mínimas tanto para los usuarios como para los editores. Esto difiere de muchos otros sistemas, como las redes telefónicas o de televisión, que limitan la participación plena a las grandes entidades, lo que inevitablemente da como resultado un sistema que sirve a sus intereses en lugar de a las necesidades de todos. (Nota: en este documento, "editores" se refiere a entidades que publican directamente a los usuarios, a diferencia de aquellas que publican a través de una plataforma mediada).

Una propiedad clave que permite esto es la interoperabilidad basada en estándares comunes; cualquier punto final que se ajuste a estos estándares es automáticamente parte de la Web, y los estándares en sí tienen como objetivo evitar suposiciones sobre el hardware o software subyacente que podría restringir dónde se pueden implementar. Esto significa que ninguna parte decide qué factores de forma, dispositivos, sistemas operativos y navegadores pueden acceder a la Web. Brinda a las personas más opciones y, por lo tanto, más vías para superar los obstáculos personales de acceso. Las opciones en tecnología de asistencia, localización, factor de forma y precio, combinadas con un diseño cuidadoso de los propios estándares, permiten que un grupo muy diverso de personas acceda a la misma Web.

De manera similar, la arquitectura técnica de la Web reduce la vigilancia en la publicación. La URL actúa como un espacio de nombres distribuido global, de baja fricción, que permite a las personas publicar en sus propios términos, con una interferencia comparativamente pequeña de los actores centralizados que buscan extraer el pago o ejercer el control editorial.

La naturaleza libre de instalación de la Web también hace que la experiencia predeterminada sea fluida. Las personas pueden navegar sin problemas entre sitios sin obstrucciones ni compromisos, lo que les permite explorar, participar y elegir cuándo formar relaciones más profundas.

La Web también es duradera. Si bien no es absoluta, la compatibilidad con versiones anteriores es un principio clave de la Web: a medida que se agregan nuevas capacidades (generalmente como extensiones a la arquitectura central), los sitios existentes aún se pueden utilizar. El resultado final es que las personas pueden ver fácilmente el contenido anterior y los editores pueden mantener su contenido disponible y coherente a lo largo del tiempo sin necesidad de volver a crearlo.

Todos estos factores han trabajado juntos a lo largo del tiempo para dar a la Web un alcance increíble. La Web no es solo una tecnología, sino un ecosistema enorme y próspero que la gente real entiende y usa. Las personas pueden escuchar de un amplio conjunto de voces y hablar a una gran audiencia. Hay un esfuerzo humano asombroso invertido en la Web que tenemos hoy, y merece una administración cuidadosa.

Agencia

Una vez que las personas acceden a la Web, están facultadas para lograr sus objetivos de manera efectiva y en sus propios términos.

La Web es versátil y expresiva. Los autores de sitios tienen una amplia gama de herramientas a su disposición, lo que permite todo, desde el simple intercambio de información hasta ricas experiencias interactivas. Además, debido a que los sitios web generalmente se crean mediante la composición de múltiples subcomponentes, los autores pueden crear fácilmente sitios potentes basándose en trabajos y servicios preexistentes.

La profunda flexibilidad y el control que se les brinda a los autores también hace que la Web sea abierta. A diferencia, digamos, de la televisión por cable, la Web se usa rutinariamente de maneras novedosas que los operadores de la plataforma nunca anticiparon. Esta naturaleza suelta e ilimitada puede dar lugar a incoherencias entre sitios, pero también dota a la Web de una fuerza única para servir a una amplia gama de personas y propósitos.

La agencia no es solo para autores de sitios, sino también para usuarios individuales. La Web logra esto ofreciendo control a las personas. Mientras que otras modalidades tienen como objetivo ofrecer opciones a las personas, uno puede seleccionar de un menú de opciones, como canales en la televisión o aplicaciones en una tienda de aplicaciones, los términos de cada oferta son en su mayoría no negociables. La elección es buena, pero no es suficiente. Los seres humanos tienen diversas necesidades, y la confianza total en los proveedores para anticipar esas necesidades a menudo es inadecuada.

La Web es diferente: debido a que el diseño básico de la Web pretende transmitir información semánticamente significativa (en lugar de solo un flujo opaco de audio y video), los usuarios pueden elegir cómo interpretar esa información. Si alguien tiene problemas con el contraste de color o la tipografía en un sitio, puede cambiarlo o verlo en el modo de lectura . Si alguien elige navegar por la Web con tecnología de asistencia o un factor de forma inusual, no es necesario que pida permiso al sitio. Si alguien quiere bloquear rastreadores , puede hacerlo. Y si quieren remezclar y reinterpretar el contenido de formas más sofisticadas , también pueden hacerlo.

Todo esto es posible porque las personas tienen un agente de usuario , el navegador, que actúa en su nombre. Un agente de usuario no solo necesita mostrar el contenido que proporciona el sitio, sino que también puede configurar la forma en que se muestra para representar mejor los intereses del usuario. Esto puede venir en forma de controles que permiten a los usuarios personalizar su experiencia, pero también en la configuración predeterminada de esos controles. El resultado es un equilibrio que ofrece una agencia sin precedentes entre los grupos: los autores del sitio tienen una amplia libertad para construir la experiencia predeterminada, pero las personas tienen la última palabra sobre cómo se interpreta el sitio. Y debido a que la Web se basa en estándares abiertos, si los usuarios no están satisfechos con un agente de usuario, pueden cambiar a otro.

La seguridad

La experiencia de uso de la Web no debe someter a las personas a daños.

La promesa central de la Web es que las personas pueden navegar en cualquier parte de la Web sin consecuencias dañinas no intuitivas. No es responsabilidad del individuo determinar si visitar un sitio generará una factura, violará su privacidad, lo inscribirá en algo o infectará su dispositivo con malware. Esto no significa que sea el trabajo del navegador evitar que el usuario vea cualquier contenido que pueda encontrar objetable, aunque, por supuesto, los usuarios deberían poder extender el navegador para filtrar el contenido si eso es lo que desean. Más bien, el navegador debe proteger al usuario de daños invisibles, y si no les gusta un sitio, o algo que ven en un sitio, pueden descartarlo con un solo clic.

Esta expectativa es mucho más fuerte que con la mayoría de las plataformas de software nativas (es decir, descargables en lugar de web). Tradicionalmente, estas plataformas no han intentado restringir el comportamiento de los programas descargados y, en cambio, requieren que las personas confíen en el autor y los instalen bajo su propio riesgo. Las plataformas más nuevas ofrecen algunas protecciones técnicas limitadas, pero tienen dificultades para transmitir las implicaciones de una manera que las personas puedan entender .. Como consecuencia, dichas plataformas se basan en gran medida en las tiendas de aplicaciones seleccionadas y la firma de paquetes para gestionar el abuso. En la Web, no se necesitan tales mecanismos porque la seguridad es lo primero: debido a que el navegador está diseñado para mostrar cualquier página de manera segura, los usuarios pueden navegar libremente por la Web sin depender de que alguien se encargue del conjunto de páginas "seguras". Esto permite que la Web tenga barreras de entrada muy bajas y un control central mínimo.

La seguridad es una promesa, y mantenerla genera confianza en la Web. La confianza, a su vez, permite la navegación casual, otorgando a las personas una libertad sin precedentes para explorar y eliminando la necesidad de que los guardianes decidan qué puede o no ser parte de la Web. Los guardianes pueden surgir y surgen por otras razones, pero dado que no son fundamentales para el diseño, podemos trabajar para reducir la centralización sin poner en riesgo la seguridad del usuario.

Persiguiendo estos valores

¿Qué significan estos valores en la práctica? La Web es una tecnología madura, por lo que no esperamos que la Web en un futuro previsible sea radicalmente diferente de la Web actual. Si lo conseguimos, puede ser la misma Web en esencia, solo que mejor:

• Los usuarios podrán navegar sin temor, sabiendo que están a salvo no solo de los sitios que visitan, sino también de atacantes en la red que roben sus datos, así como de ser rastreados en la Web.

• Los autores de sitios podrán crear una amplia gama de contenido más fácilmente que en la actualidad. La Web será la plataforma elegida por equipos de todos los tamaños y niveles de habilidad, lo que simplificará la creación de sitios fluidos y hermosos y ofrecerá capacidades de clase mundial para aplicaciones complejas.

• Los intereses de los usuarios y los sitios se equilibrarán, en lugar de inclinarse hacia los sitios como lo son hoy, con usuarios capaces de experimentar la Web en sus propios términos.

• Los usuarios podrán elegir el contenido que experimentan y con quién pueden comunicarse sin estar a merced de unos pocos sitios grandes. Los autores de sitios pequeños y medianos podrán llegar a los usuarios sin el permiso de los grandes jugadores.

• La Web será accesible para muchos usuarios que actualmente están excluidos por razones económicas o técnicas.

En otras palabras, nuestro objetivo es cumplir el ideal original de la Web e Internet como deberían haber sido: un recurso global, abierto y accesible para todos.

El resto de esta sección describe una serie de áreas técnicas específicas de enfoque que son esenciales para cumplir con esta visión.

Privacidad

La actividad de todos en la Web debe ser privada de forma predeterminada. Desafortunadamente, las personas son espiadas dondequiera que van. Vemos esto como una amenaza para la seguridad individual de todos y para la salud de la sociedad, y estamos trabajando a través de la tecnología y las políticas para identificar y eliminar sistemáticamente todos los mecanismos para catalogar la actividad de las personas en los sitios.

Seguimiento entre sitios

La técnica de vigilancia más extendida en la actualidad es el seguimiento entre sitios , en el que las redes publicitarias aprovechan su presencia en diferentes sitios para crear perfiles de comportamiento detallados de las personas en función de su actividad en la Web. Si bien los navegadores han comenzado a implementar medidas anti-seguimiento (con Safari frecuentemente a la cabeza), los sitios también están encontrando formas cada vez más creativas de rastrear a las personas que utilizan el almacenamiento del navegador, la navegación, los identificadores primarios , las huellas dactilares o los ataques de canal lateral. . La gente rara vez espera o consiente de manera significativa este nivel de vigilancia, por lo que nuestro objetivo final es eliminar el seguimiento entre sitios en la Web. Reconocemos que esto puede reducir la capacidad de muchos sitios para monetizar las visitas de los usuarios a través de publicidad en línea dirigida individualmente, pero consideramos que esto es una compensación aceptable y esperamos que los anuncios basados ​​en perfiles se vuelvan menos atractivos debido a las regulaciones de privacidad y los avances recientes. en la publicidad contextual.

Recopilación de datos por parte de los proveedores de la red

Incluso con la generación actual de protocolos de red en gran parte encriptados, los proveedores de servicios de Internet (ISP) y los operadores de redes móviles (MNO) tienen una visibilidad significativa de la actividad del usuario, tanto longitudinalmente (la mayoría de las personas solo envía tráfico a través de uno o dos proveedores) como horizontalmente (la mayoría del tráfico es llevado por uno de los pocos grandes proveedores). En algunos países existen pocas barreras contra el mal uso de esa información. Al igual que con el seguimiento entre sitios, nuestro objetivo es minimizar la cantidad de datos filtrados a los proveedores de servicios, lo que significa cerrar sistemáticamente una serie de fugas de información, siendo las tres más importantes el DNS, la Indicación del nombre del servidor TLS (SNI) y la dirección IP. del sitio web de destino.

Estamos bastante avanzados en el camino de la protección del tráfico de DNS utilizando una combinación de tecnología y política, particularmente en los Estados Unidos y Canadá (con trabajo en curso para otras jurisdicciones). Primero, estamos implementando DNS sobre HTTPS de forma predeterminada para que solo una parte vea el dominio de destino. En segundo lugar, requerimos que los puntos finales de DNS en el programa Trusted Recursive Resolver de Mozilla se comprometan legalmente a recopilar un subconjunto limitado de datos solo con fines operativos, manteniendo la confidencialidad de los datos y eliminándolos de inmediato. Idealmente , el proveedor de la red acepta estos términos , pero si no lo hace, podemos dirigir la consulta a una parte que sí lo haga. A largo plazo, también apuntamos a aumentar estas garantías legales con mecanismos técnicos como el olvidado DoH .

Proteger el campo SNI es más difícil, pero estamos trabajando activamente en Encrypted Client Hello , que ayudará hasta cierto punto, dejando que la fuga principal sea la dirección IP del servidor. Si bien las tecnologías como las VPN y los proxies encriptados pueden ayudar a prevenir este ataque, actualmente no son prácticos para la mayoría de los usos comunes. Proporcionar privacidad completa de la recopilación de datos de ISP parece ser un problema difícil y, en última instancia, puede requerir una combinación de política y tecnología. Afortunadamente, estamos viendo un progreso cada vez mayor en el ámbito de las políticas,

con más y más jurisdicciones que buscan limitar la capacidad de los proveedores de red para procesar y retener los datos de los usuarios.

Protección de los datos del navegador

Tu historial de navegación es solo eso, tuyo. Sin embargo, muchos servicios que ofrecemos para ayudar a los usuarios de Firefox, como compartir su historial de navegación y marcadores entre dispositivos, funcionan mejor con un servicio en la nube. Nuestro objetivo es brindar esos servicios de una manera que mantenga sus datos seguros y privados, incluso de nosotros. Por ejemplo, Firefox Sync funciona almacenando datos en nuestros servidores para que puedas recuperarlos desde un dispositivo incluso si otro dispositivo está fuera de línea o destruido. Sin embargo, antes de almacenar los datos, los encriptamos con una clave de usuario, lo que nos impide ver el contenido.

Un caso más desafiante son las mediciones remotas: la mayoría de los navegadores informan datos al fabricante del navegador para ayudarlos a mejorar su producto y evolucionar la Web. Es fácil deslizarse por la pendiente de aspirar más y más datos, y trabajamos duro para no hacerlo con Firefox . Sin embargo, ocasionalmente hay datos específicos, por ejemplo, páginas en las que los usuarios experimentan problemas, que son a la vez muy útiles para mejorar el navegador y también revelan la información privada del usuario. La privacidad siempre es lo primero para Mozilla, pero una compensación siempre presente entre la privacidad y la calidad del producto no es un estado saludable para la industria. Estamos entusiasmados con el avance de las tecnologías de medición de preservación de la privacidad como Prio .permitir que los navegadores y otros productos de software brinden sólidas garantías de privacidad sin ponerse en desventaja.

Sitios mismos

Una Web que mantuviera toda la historia confidencial sería una gran mejora con respecto a la Web que tenemos hoy. Sin embargo, ciertos editores y plataformas, en particular los de los gigantes tecnológicos con muchos servicios ampliamente utilizados, todavía saben demasiado sobre demasiadas personas, lo que pone en riesgo la seguridad y afianza a los titulares. Desafortunadamente, es poco probable que tales entidades cambien esta situación por sí solas: los datos son un activo competitivo, y el enfoque más fácil y flexible es registrar tanto como sea posible y almacenarlo sin cifrar. Existen técnicas emergentes que prometen permitir que los sitios brinden una buena experiencia sin comprometer la privacidad del usuario, pero es poco probable que se adopten ampliamente sin una reestructuración significativa de los incentivos de los sitios. Este es un problema desafiante para el que no tenemos todas las respuestas,

Seguridad del navegador

La promesa central de seguridad de la Web debe significar que los sitios nunca deben comprometer el dispositivo de alguien. Sin embargo, como cuestión práctica, esto no ha resultado ser cierto. La Web tiene una enorme superficie de API y, por lo tanto, una enorme superficie de ataque. Los navegadores web están escritos principalmente con lenguajes (C/C++) y técnicas que han demostrado ser extremadamente difíciles de usar correctamente y que fallan catastróficamente cuando inevitablemente ocurren errores. Casi todas las versiones de los principales navegadores incluyen correcciones para vulnerabilidades de seguridad explotables de forma remota. En pocas palabras, los navegadores no están a la altura de la garantía de que es seguro navegar. Para que la Web tenga éxito, debemos cumplir esa promesa.

Prevención de defectos

Para el nuevo código, ahora tenemos tecnologías que permiten a los desarrolladores escribir código con menos defectos, menos catastróficos. El ejemplo más obvio aquí es el lenguaje de programación Rust , que proporciona un rendimiento comparable al de C y C++, pero que es intrínsecamente seguro para la memoria, lo que convierte las vulnerabilidades anteriormente explotables en fallas de compilación o bloqueos seguros. Gran parte del nuevo código de Firefox se está escribiendo en Rust. Cada vez más, también somos capaces de escribir código verificable que no solo es seguro para la memoria, sino que también puede ser verificado por máquina para verificar su corrección. Un buen ejemplo de esto es el HACL*biblioteca que contiene implementaciones verificadas de muchas primitivas criptográficas importantes. Otra área prometedora para el código verificado es el compilador Javascript Just In Time (JIT). Los JIT son fragmentos de código complicados y los errores lógicos pueden generar vulnerabilidades graves; Las técnicas de verificación formal pueden ayudar a encontrar y prevenir estos errores. En el futuro, esperamos ver mucho más uso de estas nuevas técnicas para producir código que sea correcto desde el principio.

Mitigación de defectos

Desafortunadamente, todos los principales navegadores contienen grandes cantidades de código C y C++, y volver a escribirlo requeriría niveles de recursos poco prácticos e introduciría un volumen inaceptable de nuevos defectos. La defensa estándar, iniciada por Chrome, es aislar partes del navegador en sus propios procesos de "espacio aislado", lo que limita el efecto del compromiso. Esta es una técnica importante, pero que se enfrenta a una serie de limitaciones , principalmente debido al costo de los recursos de la caja de arena y el costo de ingeniería de separar cada componente individual. Parece probable que el nivel de sandboxing implementado por Chrome, con cada sitioen su propio proceso, está cerca del límite de la practicidad. Afortunadamente, ahora están disponibles nuevas técnicas ligeras de sandboxing en proceso, lo que hace posible sandboxing de componentes individuales de manera económica . Creemos que esto nos permitirá proteger el código C/C++ existente con un consumo de recursos y un esfuerzo mínimos.

Trabajando juntos

A diferencia de muchas de las tecnologías descritas en este documento, la mayor parte del trabajo en esta área es invisible para los usuarios. En algunos casos, se requieren algunos cambios en la plataforma web, como las contramedidas COOP y COEP para sincronizar ataques como Spectre. Pero, en general, lo que queremos es que los navegadores sean invisiblemente más seguros. Si bien esto requiere una coordinación menos formal que los cambios en la plataforma web observable, es un problema tan difícil que los navegadores cooperan de manera informal para compartir técnicas y conocimientos, lo que da como resultado una web más segura.

Cifrado ubicuo

La Web comenzó como un proyecto de investigación en 1989 y, como casi todos los sistemas de esa época, no estaba cifrada. Internet de hoy es un lugar hostil para el tráfico no cifrado y debemos garantizar la confidencialidad, integridad y autenticidad de cada bit que se transmite o recibe.

La experiencia ha demostrado que esto solo puede suceder cuando el cifrado es tan eficiente y conveniente que puede proporcionarse de forma predeterminada. Durante años, la mayor parte de la Web no estaba cifrada y el cifrado se percibía como lento y difícil de implementar. Sin embargo, en los últimos 10 años la situación ha cambiado significativamente. En primer lugar, el cifrado se ha vuelto mucho más rápido, tanto en términos absolutos (debido a los nuevos protocolos como TLS 1.3 y QUIC, nuevos algoritmos como la criptografía de curva elíptica y procesadores más rápidos) y relativamente (debido al aumento del tamaño de otras partes de la Web, como JavaScript, imágenes y video). En segundo lugar, las normas han cambiado, en parte debido a la amplia implementación de autoridades de certificación gratuitas, como Let's Encrypt, y el cifrado ahora se considera más esperado que excepcional. Como resultado de estos y otros cambios, la fracción de cargas de páginas cifradas pasó de alrededor del 30 % en 2015 a la gran mayoría del tráfico en 2022. Nuestro objetivo es llevar esta cifra al 100 %.

La Web también hace uso de una serie de otros protocolos además de HTTP. Deberíamos asegurar nuevos protocolos desde cero, como hicimos con QUIC , WebPush y WebRTC . Además, debemos buscar oportunidades para introducir el cifrado de extremo a extremo en la capa de aplicación con protocolos como Messaging Layer Security . Para los protocolos no cifrados establecidos como DNS, debemos seguir el camino de HTTP definiendo versiones cifradas como DNS sobre HTTPS y luego hacer una transición gradual del ecosistema a cifrado completo.

Al mismo tiempo que la tecnología permite el cifrado omnipresente, también vemos actividad de los gobiernos para debilitar el cifrado . Creemos que esto representa una amenaza a la seguridad y privacidad de Internet y que los gobiernos deben trabajar para fortalecer la seguridad de los usuarios, no debilitarla.

Seguridad para nuevas capacidades

Las preocupaciones de seguridad también entran en juego cada vez que consideramos agregar nuevas capacidades a la plataforma web. Hay muchas ventajas de publicar en la Web, pero la Web también limita lo que pueden hacer los sitios. Esto ha resultado en esfuerzos continuos para expandir la variedad de contenido que se puede entregar a través del navegador mediante la adición de nuevas capacidades, como el acceso a la cámara o al micrófono para las interacciones WebRTC, la ejecución rápida de código compilado escrito en cualquier idioma con WebAssembly y más inmersivo. aplicaciones con la API de pantalla completa. En su mayor parte, esto es algo bueno: las personas pueden acceder a un conjunto cada vez más amplio de experiencias con todos los beneficios que brinda la Web. Sin embargo, las nuevas capacidades pueden introducir riesgos que deben gestionarse con cuidado.

Idealmente, se pueden diseñar nuevas capacidades para que se puedan exponer de forma segura en cualquier sitio sin solicitar el permiso del usuario. A menudo, esto requiere cierto cuidado y da como resultado una característica que es algo diferente de la funcionalidad equivalente disponible para las aplicaciones nativas. Por ejemplo, no es seguro permitir que el contenido web abra un socket TCP arbitrario a cualquier servidor en Internet porque esa capacidad podría usarse para eludir los firewalls corporativos. En cambio, tanto WebSockets como WebRTC implementan mecanismos que aseguran que el sitio web solo pueda comunicarse con servidores que hayan dado su consentimiento para comunicarse con ellos. Esto nos permite hacer que esas API estén disponibles universalmente sin tener que explicar los riesgos al usuario.

Sin embargo, otras capacidades, como el acceso a la cámara, implican riesgos inherentes que son difíciles de eludir. En estos casos, no podemos exponer de forma segura la capacidad de forma predeterminada. En algunas circunstancias, puede ser apropiado ofrecer a las personas la opción de habilitarlo para un sitio determinado. Utilizamos los siguientes criterios para evaluar si ese es el caso:

• Valor: ¿Ofrece la capacidad suficiente beneficio al usuario para justificar el riesgo?

• Gravedad: ¿Qué nivel de daño puede ocurrir si la capacidad se usa indebidamente?

• Consentimiento: ¿Pueden las personas tomar una decisión informada sobre el riesgo?

• Transparencia: ¿Está claro cómo se utiliza la capacidad y por quién?

• Revocabilidad: ¿Qué sucede si alguien cambia de opinión?

Para el acceso a la cámara, las consecuencias del mal uso son graves, pero también son fáciles de entender: el sitio puede ver cualquier cosa a la que apunte la cámara y los usuarios tienen la capacidad de cubrir o reorientar su cámara si les preocupa el uso encubierto por parte de los sitios para que han concedido permiso. Además, revocar el acceso a la cámara tiene implicaciones claras y es fácil de verificar, mientras que el valor de las teleconferencias en la Web es sustancial. Combinado con una variedad de mitigaciones técnicas , llegamos a la conclusión de que era apropiado ofrecer acceso a la cámara en la Web.

Sin embargo, las solicitudes de permiso por sí solas no pueden hacer que todas las capacidades sean seguras, y desconfiamos de someter a las personas a un aluvión de elecciones inescrutables y de alto riesgo, junto con la fatiga de decisión resultante . Algunas características requieren una consideración cuidadosa de las consecuencias, lo que está directamente en desacuerdo con el objetivo de la navegación casual. Además, las personas a menudo no están preparadas para comprender los riesgos y las consecuencias. En la práctica, la evidencia sugiere que muchas personas simplemente aceptan las indicaciones que se les ofrecen, especialmente a medida que se vuelven más comunes. Si esto resulta en sorpresa y arrepentimiento , las personas perderán la confianza en la Web.

Por ejemplo, creemos que la API WebUSB propuesta no es buena para la Web. WebUSB permite la comunicación de bajo nivel entre un sitio web y cualquier dispositivo conectado a la computadora de alguien. La mayoría de los dispositivos USB no están protegidos contra la entrada adversaria, y conectarlos a fuentes no confiables podría permitir el robo de credenciales , la inyección de malware, la vigilancia o incluso daños físicos. Estos riesgos son opacos para la mayoría de las personas, y el protocolo funciona de forma rápida y silenciosa sin ninguna indicación estándar de si se está utilizando y cómo. Y aunque WebUSB ofrece beneficios reales para ciertas tareas especializadas como actualizar el firmware, esas tareas generalmente no son cosas que la mayoría de la gente hace a diario. Por esta razón, llegamos a la conclusión de que no era seguro ofrecer la API de WebUSB. Por el contrario, las API de nivel superior comoWebAuthn permite el uso de tokens USB para aplicaciones específicas que hemos determinado que son seguras.

Como principio general, nos entusiasma traer más contenido y aplicaciones a la Web. Pero ciertas aplicaciones pueden no ser adecuadas para la Web en general, y eso está bien. En algunos casos, es posible que podamos resolver esta tensión al permitir que los usuarios amplíen su navegador para brindar capacidades mejoradas a sitios específicos en los que confían (consulte Extensibilidad ) . Sin embargo, requiere que mantengamos a las personas seguras en la Web.

Actuación

La gente a menudo discute el rendimiento del software en términos de rendimiento abstracto (por ejemplo, "el doble de rápido"), pero lo que más importa en la Web es la capacidad de respuesta , que los usuarios experimentan como la ausencia de fricción. Los autores del sitio conciben las experiencias como instantáneas y fluidas, pero los retrasos y tartamudeos surgen como defectos prácticos que hacen que el resultado no sea lo prometido. Las consecuencias de estos defectos recaen en los usuarios, quienes experimentan frustración, sobrecarga cognitiva e incapacidad para lograr sus objetivos. Esta fricción también se refleja mal en el sitio e impide sus objetivos. Todos pagan un costo y nadie se beneficia.

No podemos hacer que cada operación sea instantánea. Pero, afortunadamente, existen presupuestos de tiempo bien entendidos dentro de los cuales los humanos experimentan las interacciones sin frustraciones. En términos generales, estos se reducen a 16 milisegundos para cuadros de animación, 100 milisegundos para comentarios de entrada y 1000 milisegundos para navegación. Queremos que todos los usuarios experimenten constantemente los sitios dentro de estos presupuestos para que la Web satisfaga las necesidades de las personas sin hacerlas sentir miserables.

Desafortunadamente, no estamos cerca de ese objetivo y, a pesar de los considerables avances en hardware y software, hemos avanzado muy poco para lograrlo . En pocas palabras, las personas están creando sitios mucho más exigentes que antes, principalmente para crear experiencias más ricas con menos esfuerzo. Al igual que con el cifrado, ahora sabemos que pedirles a los autores de sitios que hagan sacrificios para lograr una experiencia receptiva no logrará el resultado que queremos. Necesitamos ofrecer a los autores las capacidades para crear la experiencia que desean de una manera eficiente y garantizar que la forma más fácil de crear algo sea también la más rápida. Y dado que el rendimiento es tan fuerte como su eslabón más débil, debemos aplicar sistemáticamente este pensamiento a cada capa de la pila.

Bajo el capó

La forma más básica de hacer que los sitios sean más rápidos es que los navegadores implementen la plataforma web existente de manera más eficiente. La competencia entre navegadores crea fuertes incentivos para hacerlo y ha resultado en enormes mejoras en la ejecución de JavaScript, la manipulación del DOM y la representación. Sin embargo, todavía existen deficiencias significativas, que planeamos abordar y alentar a otros proveedores de navegadores a abordar también.

En primer lugar, muchos de los puntos de referencia de JavaScript a los que históricamente se han dirigido los navegadores se diseñaron para probar los límites computacionales en lugar de representar cargas de trabajo del mundo real. Estos han fomentado optimizaciones hiperespecíficas y demasiado complejas, que rara vez ayudan y, a menudo, dificultan la navegación diaria. Ahora que los sitios pueden usar WebAssembly para cargas de trabajo especializadas de alta computación, creemos que los navegadores deben reorientar sus motores para priorizar la capacidad de respuesta del mundo real , donde la ejecución rápida de cargas de trabajo moderadas suele ser más importante que la velocidad máxima. Por ejemplo, creemos que acortar los tiempos de compilación JIT y simplificar la canalización de optimizaciónpuede mejorar sustancialmente la carga de la página y aumentar el comportamiento fluido, y planea realizar este tipo de cambios incluso si reduce nuestra puntuación en ciertos puntos de referencia JS sintéticos como Octane y Kraken. También queremos ver nuevos puntos de referencia que reflejen mejor las cargas de trabajo y la capacidad de respuesta del mundo real. El velocímetro fue un gran paso en esta dirección y esperamos continuar con esa tendencia.

En segundo lugar, necesitamos identificar y eliminar los acantilados de rendimiento. Los autores de sitios a menudo tienen dificultades para obtener un buen rendimiento en la plataforma web, y los cambios pequeños y aparentemente inocuos pueden hacer que una página rápida sea inexplicablemente lenta. Brindando velocidad con consistenciareduce el contratiempo de los usuarios y permite a los autores crear e iterar sin miedo. Por ejemplo, es significativamente más costoso realizar el diseño de texto para idiomas bidireccionales como el árabe y el hebreo que para idiomas unidireccionales. Firefox condicionó anteriormente este cálculo adicional a la presencia de cualquier texto bidireccional en el documento, pero esto significaba que incluir una sola palabra de dicho idioma, por ejemplo, mediante un enlace a una traducción, haría que la página fuera sustancialmente más lenta incluso si la gran cantidad de la mayoría del texto era unidireccional. Firefox ahora toma esta decisión a un nivel más granular, pero aún queda trabajo por hacer para eliminar la sobrecarga por completo.

Finalmente, hemos visto numerosas optimizaciones en subsistemas de navegadores individuales, pero no nos hemos centrado en el panorama general de cómo estos sistemas funcionan juntos. Por ejemplo, programar el mismo trabajo en un orden más inteligente puede tener un impacto mucho mayor en la experiencia que una reducción incremental en el cómputo total. Del mismo modo, una mejor gestión de caché para mejorar la reutilización de recursos de alto valor puede evitar el cálculo y las recuperaciones por completo. Vemos oportunidades significativas para mejorar el rendimiento de Firefox con estos enfoques holísticos y transversales, y los buscaremos en el futuro.

Nuevas API

Hay límites en lo que los navegadores pueden optimizar sin la ayuda del sitio, y hay límites en los tipos de experiencias que los sitios pueden crear sin las abstracciones adecuadas. Esto a menudo requiere nuevas adiciones a la plataforma web para permitir que los sitios y los navegadores cooperen en el rendimiento. Este tipo de mejoras generalmente se dividen en algunas categorías.

En primer lugar, pueden proporcionar a los sitios un mecanismo más fluido y específico para realizar una tarea, con menos restricciones y efectos secundarios observables que podrían requerir que el navegador realice un trabajo innecesario. Por ejemplo, Intersection Observers suplantó técnicas mucho más costosas para medir cuándo los elementos entran y salen de la ventana gráfica.

En segundo lugar, estas capacidades pueden permitir un uso más rápido y eficiente de los recursos del sistema o del hardware. WebAssembly mejora la eficiencia de la CPU de JavaScript con abstracciones de nivel inferior, WebGPU mejora la eficiencia de la GPU de WebGL con primitivas gráficas más modernas y WebTransport mejora la eficiencia de la red de WebSockets con protocolos más nuevos (QUIC).

En tercer lugar, las nuevas API pueden ofrecer a los sitios un mejor control y coordinación con la canalización de cómputo del navegador. Por ejemplo, WebAnimations permite a los desarrolladores conectarse a la infraestructura de animación CSS eficiente de JavaScript, evitando la necesidad de negociar entre flexibilidad y rendimiento. Del mismo modo, requestAnimationFrame y requestIdleCallback han brindado a los desarrolladores mejores primitivas para ejecutar su código en el momento adecuado, y la API de programación de tareas prioritarias promete mejorar aún más la programación de Javascript.

Diseñar bien estas capacidades no es fácil, por varias razones: necesitan mejorar sustancialmente el rendimiento para que valga la pena hacerlo; deben ser lo suficientemente generales para ser ampliamente útiles; necesitan integrarse perfectamente en la plataforma web existente; deben ser sencillos de implementar en múltiples navegadores y arquitecturas de hardware; necesitan gestionar con cuidado el riesgo de daño no intencionado a otras prioridades (es decir, privacidad y seguridad); y deben ser lo suficientemente simples para que una amplia gama de autores de sitios los entiendan y los implementen. Es mucho pedir, pero hasta ahora hemos visto un trabajo impresionante y creemos que la industria está preparada para los desafíos que se avecinan.

Entrega más rápida

El bajo rendimiento de la red es uno de los contribuyentes más obvios a una experiencia web lenta en general. Si bien en gran medida esto es el resultado de conexiones de red lentas, en muchos casos tampoco estamos haciendo un uso óptimo de esas conexiones. En algunos casos estos cambios se pueden realizar de forma unilateral del lado del cliente o del servidor, pero en otros requieren mejoras en la Plataforma Web o en los protocolos de red que utiliza.

Idealmente, minimizaríamos la cantidad de datos que deben enviarse y recibirse. Esta es un área en la que queda mucho trabajo por hacer, desde códecs mejorados como AV1, que reduce drásticamente el tamaño del video de alta resolución , hasta un mejor almacenamiento en caché, como con el encabezado inmutable HTTP . Si bien hemos visto mejoras en algunos frentes, también hay varias áreas que aún presentan desafíos. En particular, el uso de marcos grandes combinado con el aumento de cachés aislados significa que incluso las páginas simples a menudo necesitan descargar grandes cantidades de JavaScript. Abordar esto sigue siendo un área activa de investigación, pero parece difícil hacerlo sin afectar negativamente la privacidad .. Un caso aún más difícil es la publicidad y los rastreadores, los cuales ralentizan significativamente la carga de la página y son una fuente común de quejas sobre la experiencia del usuario. Aquí no hay soluciones fáciles, ya que el modelo de monetización web actualmente depende en gran medida de la publicidad y, sin embargo, la situación actual es muy insatisfactoria.

Cuando se deben enviar datos, es importante programar esa transmisión para minimizar el trabajo realizado en la ruta crítica. Por ejemplo, históricamente los navegadores usaban OCSP para verificar la revocación de certificados. Debido a que los servidores OCSP suelen ser lentos y las páginas no se pueden procesar antes de que se complete la verificación OSCP, esto contribuye a la latencia de carga de la página. Cada vez más, los navegadores cargan previamente el estado de los certificados mediante tecnologías como CRLSets en Chrome o CRLite en Firefox. Esto también tiene la ventaja de mejorar la privacidad del usuario al no filtrar al servidor OCSP qué certificados ha solicitado el navegador. Parece probable que optimizaciones similares sean posibles en otros lugares.

También podemos mejorar nuestros protocolos de red básicos. En los últimos años, hemos visto el desarrollo de HTTP/2, TLS 1.3 y QUIC, todos los cuales están diseñados para reducir la latencia, especialmente en el área de configuración de la conexión, que contribuye en gran medida al rendimiento general. Un beneficio adicional es que estos nuevos protocolos siempre están encriptados y ofrecen un rendimiento comparable, si no mejor, que los protocolos no encriptados que reemplazan, lo que fomenta el encriptado completo de Internet. A medida que aumente la implementación de estos protocolos, la Web será más rápida y será más fácil obtener un buen rendimiento sin tener que recurrir a este tipo de hacks.que los sitios han usado tradicionalmente para compensar el bajo rendimiento de HTTP. Además, hay una serie de nuevas áreas potenciales de mejora (corrección de errores hacia adelante, mejor priorización, etc.) que aún no se han explorado, y esperamos ver más trabajo en ellas en el futuro.

Finalmente, podemos reducir la latencia de la red acercando los puntos finales. En los primeros días de Internet, el alojamiento distribuido geográficamente estaba disponible solo para los editores con mejores recursos, pero con el tiempo, la innovación y la competencia entre los proveedores de CDN han ampliado enormemente la proporción de sitios que utilizan esta técnica. Del mismo modo, las nuevas técnicas de computación perimetral permiten a los desarrolladores aplicar el mismo enfoque a las respuestas dinámicas utilizando tecnologías web estándar como WebAssembly . Vemos un potencial significativo para la innovación en este espacio para acelerar la Web y esperamos verlo evolucionar.

Optimización de sitios

No importa cuánto mejoremos la plataforma, no podemos hacer que cada operación sea instantánea. Además, las restricciones de compatibilidad con versiones anteriores hacen que sea muy difícil evitar que los sitios utilicen patrones ineficientes. Debido a que siempre será posible construir sitios lentos, los autores juegan un papel crucial para lograr una Web rápida.

El enfoque tradicional para esto ha sido suponer que los autores supervisarán y ajustarán el rendimiento de su sitio y les ofrecerán diagnósticos para hacerlo. Hemos visto grandes avances en esta área con API web como Navigation Timing, herramientas para desarrolladores como Firefox Profiler y servicios como Lighthouse y WebPageTest . Sin embargo, si bien los diagnósticos potentes son necesarios para una Web rápida, no son suficientes. A pesar de la disponibilidad de estas herramientas, muchos sitios siguen siendo lentos porque sus autores carecen de los recursos, el interés o la experiencia para optimizar el rendimiento. Hay dos formas generales de abordar esto.

En primer lugar, podemos proporcionar a los sitios los incentivos adecuados para que sean rápidos. Los sitios ya tienen incentivos naturales para optimizar el rendimiento a fin de mejorar las tasas de retención y conversión , pero a pesar de que los principales oradores en las conferencias web destacaron estos hallazgos durante años, parecen ser insuficientes para generar el tipo de cambio en toda la industria que queremos ver. Sin embargo, el enorme tamaño de la industria de SEO demuestra que muchos sitios harán todo lo posible para mejorar la ubicación de búsqueda, por lo que nos complace ver que la iniciativa Web Vitals de Google vincula directamente la ubicación de búsqueda con el rendimiento de la página .

En segundo lugar, podemos hacer que sea más fácil y automático crear sitios rápidos. Esto es difícil de hacer para los navegadores unilateralmente: hacer que algo sea automático requiere ser obstinado, y es difícil para una plataforma tan general como la Web tener opiniones sobre algunas de las áreas complejas, como la carga de recursos y la gestión del estado, donde comúnmente surgen problemas de rendimiento. Durante la última década, un ecosistema de herramientas y marcos ha evolucionado para llenar estos vacíos, algunos de los cuales impulsan cientos de miles de sitios en la Web en la actualidad. En consecuencia, las opciones de diseño y los valores predeterminados de estos componentes básicos tienen un gran impacto en las características de rendimiento de la Web. El ritmo de evolución de estas herramientas es impresionante y, si bien vemos áreas de mejora, somos optimistas de que se abordarán con el tiempo.

Ergonomía de construcción del sitio

La creación de sitios web se ha vuelto sustancialmente más fácil en muchos sentidos, pero también se ha vuelto más compleja y sigue habiendo una serie de puntos débiles que hacen que la experiencia sea más difícil de lo que debería ser. Esto tiene varias consecuencias negativas. Primero, quita poder a los autores del sitio al obstaculizar su capacidad de expresarse. En segundo lugar, dirige el contenido a las plataformas de aplicaciones nativas, lo que disminuye el alcance de la Web. Finalmente, fomenta la centralización al inclinar el campo de juego hacia los grandes editores y proveedores de plataformas con equipos de ingeniería sofisticados e infraestructura compleja. Nuestro objetivo es revertir estas tendencias facilitando la creación y el mantenimiento de sitios.

La forma más poderosa de hacer algo más fácil es simplificarlo, por lo que nuestro objetivo es reducir la complejidad total con la que los autores deben lidiar para producir el resultado deseado. Para ser más efectivos, debemos priorizar lo que simplificamos, por lo que nuestra estrategia es categorizar las técnicas de desarrollo en niveles crecientes de complejidad y luego trabajar para eliminar las brechas de usabilidad que empujan a las personas hacia enfoques más complejos. Por lo general, esto significa crear nuevas funciones que permitan a los editores realizar funciones que antes requerían grandes cantidades de código, a menudo en forma de bibliotecas, marcos o plataformas monolíticas de terceros.

La red declarativa

El diseño básico de la web es declarativo: HTML y CSS han empoderado a una amplia gama de personas para desarrollar contenido web porque son fáciles de entender y permiten a los autores del sitio centrarse en el qué en lugar del cómo .. Además, las funciones declarativas proporcionadas por el navegador pueden garantizar comportamientos alternativos sólidos y predecibles, en contraste con los enfoques imperativos más frágiles, donde la responsabilidad del manejo de errores recae completamente en los desarrolladores. Desafortunadamente, mientras que las experiencias web se han vuelto sustancialmente más ricas en los últimos 20 años, la expresividad de HTML y CSS no ha seguido el mismo ritmo. En cambio, los autores que desean crear aplicaciones interactivas generalmente se basan en marcos que luego dibujan sus interfaces usando HTML pero usan JavaScript para el trabajo pesado de la aplicación y la lógica de representación. Para aplicaciones complicadas, esta es una opción razonable, pero el conjunto limitado de funciones de HTML/CSS significa que los autores se sienten obligados a usar bibliotecas y marcos JS más grandes y cada vez más complejos para casi cualquier sitio interactivo. En un mundo mejor,

Aquí hay dos deficiencias que vale la pena abordar. El primero es la falta de buenos controles estandarizados que también se puedan diseñar fácilmente en todos los navegadores. Las plataformas de aplicaciones nativas, como iOS y Android, brindan ricas bibliotecas de controles que funcionan bien y están diseñados para coincidir con el resto de la plataforma. Por el contrario, la plataforma web básica es comparativamente deficiente, con un conjunto mucho más limitado de controles integrados. Y donde la web tiene controles equivalentes, a menudo no se pueden diseñar lo suficiente y tienen estructuras internas inconsistentes en todos los navegadores, lo que dificulta que sean visualmente consistentes con el resto de la página web. Queremos llenar estos vacíos y nos complace ver que el esfuerzo de OpenUI ya está progresando en este espacio.

La segunda deficiencia está en las primitivas de diseño. El diseño de bloques, el primitivo de diseño histórico de la Web, se ha optimizado en gran medida, pero no se adapta bien a los diseños de tipo de aplicación. En los últimos años, hemos visto una serie de primitivas de diseño directas y expresivas, como flexbox, cuadrícula, mampostería y consultas de contenedores. Estos permiten a los autores decir lo que quieren decir sin apoyarse en marcos de diseño complicados, posicionamiento basado en secuencias de comandos o trucos poco intuitivos como flotadores y tablas. Desafortunadamente, estas primitivas aún no están completamente disponibles en todos los navegadores o no son tan predeciblemente rápidas como el diseño de bloques. Estamos trabajando intensamente para admitir y mejorar estas primitivas más nuevas en Gecko y esperamos que otros motores hagan lo mismo para que los desarrolladores puedan confiar en ellos.

Extendiendo la Web con JavaScript

Si bien creemos que las potentes capacidades declarativas son importantes, también sabemos que las funciones integradas de la plataforma web nunca pueden ofrecer todas las características imaginables. JavaScript existe para hacer que la plataforma sea extensible y ha demostrado ser un mecanismo poderoso para brindar experiencias ricas en la Web.

A medida que ha aumentado el alcance y la gama de casos de uso de JavaScript, también lo ha hecho la complejidad. Los desarrolladores han respondido con un ecosistema de herramientas y marcos que se mueve rápidamente y es orgánico. Esto ha creado su propio conjunto de desafíos para que los desarrolladores identifiquen las herramientas adecuadas para el trabajo, naveguen por sus complejidades y asperezas y se mantengan al día con el ritmo del cambio. No obstante, consideramos que la elección y la competencia son buenas para la Web, y esto se refleja en el poder y la flexibilidad cada vez mayores de las aplicaciones Web. En términos generales, esta es un área en la que desempeñamos un papel de apoyo, más que de liderazgo.

Como se describe en el Manifiesto de la Web Extensible, creemos que los navegadores deben aprender de lo que funciona, escuchar lo que se necesita y proporcionar las primitivas correctas. A medida que surgen características esenciales y abstracciones en el ecosistema, podemos estandarizarlas e integrarlas directamente en la plataforma web para simplificar las cosas. Por ejemplo, las promesas se introdujeron y perfeccionaron por primera vez en las bibliotecas de JavaScript. Una vez que se establecieron su valor y su semántica óptima, se trasladaron a la plataforma web, desbloqueando más expresiones idiomáticas para las API web y nuevas y poderosas construcciones de programación como async/await. También podemos proporcionar prestaciones como Import Maps para alinear más estrechamente la plataforma web con la forma en que los desarrolladores realmente crean el código. Finalmente, los navegadores pueden agregar funciones para reducir la sobrecarga de rendimiento de las abstracciones populares, ya sea admitiéndolas de forma nativa (por ejemplo,

Control de usuario

La Web es única porque ofrece a los usuarios un control sin igual sobre el contenido que experimentan. Este control es la base de la agencia, pero la realidad no siempre ha estado a la altura de la promesa, y vemos amenazas en el futuro. En consecuencia, buscamos proteger y expandir los mecanismos que permiten a las personas experimentar la Web en sus propios términos.

Contenido reinterpretable

La capacidad superior de la Web para ofrecer control proviene de su arquitectura técnica, en la que los usuarios pueden elegir su agente de usuario (es decir, navegador) y los sitios comunican información de una manera que es receptiva a la reinterpretación. HTML y CSS ofrecen transparencia semántica, proporcionando al navegador un modelo de presentación que puede ser modificado o reinterpretado. Los estándares web otorgan al navegador una amplia discreción para operar, y el acoplamiento flexible de las funciones de la plataforma web y su implementación desigual e incremental desalienta a los sitios a hacer suposiciones sobre el resultado final. Estas propiedades técnicas son un ingrediente necesario para los controles efectivos, pero están amenazadas desde varios ángulos.

En primer lugar, la aparición de cadenas de herramientas más poderosas y complicadas puede oscurecer la intención semántica y dificultar la reinterpretación. Por ejemplo, los desarrolladores a menudo codifican información semántica extensa en la jerarquía de componentes de un marco, pero las herramientas eliminan esa información, lo que deja al navegador con una sopa de elementos div. Peor aún, algunos marcos tienen como objetivo eludir el DOM por completo mediante la representación directa en un elemento de lienzo. Siempre que sea posible, tratamos de trabajar con marcos para encontrar mecanismos elegantes y eficientes para proporcionar al navegador un modelo semántico significativo del contenido.

En segundo lugar, a medida que se agregan nuevos tipos de contenido a la Web, puede ser un desafío técnico y político integrarlos teniendo en cuenta la transparencia semántica. Por ejemplo, los sitios orientados a texto, como periódicos y revistas, generalmente se procesan directamente con las primitivas web habituales, lo que facilita a los usuarios guardarlos, reformatearlos, mezclarlos o traducirlos. Por el contrario, las fuertes demandas de tecnologías de gestión de derechos digitales (DRM) para audio y video conducen a su incorporación a la plataforma web con extensiones de medios cifrados. Ante la perspectiva de que la gente abandonara Firefox en masa para acceder a los servicios de transmisión, finalmente optamos por admitir EME , pero, sin embargo, lo vemos como un capítulo lamentable en la evolución de la Web.

Palancas de expansión

El contenido reinterpretable es necesario para el control, pero no es suficiente: el navegador debe proporcionar a los usuarios palancas para controlar su experiencia. Los sitios y los navegadores pueden trabajar juntos para ofrecer este control, por ejemplo, utilizando el esquema de color preferido para personalizar la presentación de acuerdo con los deseos del usuario.

Sin embargo, los sitios no siempre se anticipan a las necesidades de todos, por lo que es importante ofrecer también mecanismos que el usuario pueda invocar unilateralmente, como anulaciones de color . La viabilidad de este tipo de mecanismos depende sustancialmente de la medida en que la funcionalidad subyacente sea administrada por el navegador en lugar del sitio. Si bien es posible modificar el comportamiento impulsado por el sitio a través de intervenciones, puede ser complicado hacerlo bien, por lo que debemos buscar oportunidades para ofrecer funcionalidad con funciones de navegador en lugar de API de plataforma web. Por ejemplo, preferimos ofrecer videos Picture-in-Picture directamente a los usuarios , en lugar de dejar que los sitios dicten la disponibilidad .de la función De manera similar, podemos promover estos objetivos al proporcionar primitivas semánticas de nivel superior en la plataforma web. Por ejemplo, el tipo de entrada "fecha" permite que el navegador personalice la representación del calendario de acuerdo con las preferencias del usuario sin exponer esta información privada a JavaScript o sin depender de los sitios para respetarla.

Extensibilidad

Hay una tensión natural entre la funcionalidad y la simplicidad. Ofrecer control a menudo significa ofrecer una función, pero demasiadas funciones pueden ser confusas y abrumadoras, lo que en última instancia dificulta la agencia de las personas. Así como los sitios no pueden anticipar todas las necesidades de los usuarios, tampoco pueden hacerlo los navegadores.

La extensibilidad resuelve esta tensión al permitir que las personas personalicen su experiencia de navegación con complementos. Los desarrolladores tienen una alta tolerancia al alcance, por lo que los navegadores pueden ofrecer numerosos puntos de extensión configurables para permitirles crear una amplia variedad de funciones. El menú de complementos disponibles proporciona a los usuarios amplias palancas bajo demanda para satisfacer sus necesidades mientras mantiene la experiencia predeterminada simple.

Los complementos tienen acceso a capacidades mucho más poderosas que los sitios, lo que los hace claramente no casuales. Esto requiere cierto grado de control y curación para mantener a las personas a salvo de complementos maliciosos. Estamos explorando formas de reducir esta fricción, pero en última instancia, debemos ejercer cierto grado de supervisión para equilibrar la apertura, la agencia y la seguridad de las extensiones del navegador.

Los complementos también pueden proporcionar un mecanismo para ampliar la plataforma web normal con funciones que son demasiado peligrosas para proporcionar de forma predeterminada. Debido a que los usuarios deben instalar complementos explícitamente y se les recuerda como parte de la experiencia de instalación que los complementos tienen poderosos privilegios más allá de los de las páginas web ordinarias, los complementos específicos del sitio pueden permitir a los usuarios proporcionar capacidades elevadas a los sitios en los que confían sin comprometer el modelo de interacción casual que sustenta la Web. Estamos experimentando activamente con este enfoque en Firefox.

Mediación entre intereses contrapuestos

Permitir a los usuarios mejorar su propia experiencia suele ser bueno para todos, pero a veces los sitios y los usuarios tienen objetivos opuestos. En estos casos, los sitios pueden intentar limitar el control del usuario. Los sitios tienen amplias capacidades para promover sus intereses. El papel de un navegador como Firefox es nivelar el campo de juego actuando en nombre de las personas para proporcionarles herramientas y agregar su influencia.

Esta desalineación de intereses tiende a manifestarse en algunas dimensiones comunes. Primero, muchos sitios se enfocan estrechamente en su propio compromiso y buscan captar la atención del usuario de manera invasiva y que distrae. Firefox tiene una larga historia de contramedidas a estas técnicas, originalmente con el bloqueo de ventanas emergentes y, más recientemente, restringiendo la reproducción automática de videos y el abuso de notificaciones ., que planeamos continuar. En segundo lugar, muchos sitios están muy interesados ​​en ejecutar secuencias de comandos intrusivas para generar ingresos o recopilar análisis y, por lo tanto, desaprueban las funciones de protección de seguimiento o los complementos de bloqueo de contenido. Finalmente, los sitios a veces intentan deshabilitar las capacidades del usuario, como autocompletar formularios, copiar y pegar, o hacer clic con el botón derecho, ya sea en un intento de salvaguardar su propiedad intelectual o porque se ven a sí mismos como mejores jueces de los mejores intereses del usuario. En todos estos casos, creemos que los navegadores deben encontrar soluciones técnicas y no técnicas creativas para mantener el control del usuario.

Comportamiento abusivo

Las formas técnicas de reinterpretación descritas anteriormente otorgan al usuario cierto control sobre su experiencia, pero tienden a fallar al permitir que los usuarios moldeen su experiencia en las plataformas de comunicación (correo electrónico, redes sociales, etc.). Esto se debe a que estas plataformas usan estructuras semánticas genéricas para entregar contenido dinámico (a menudo generado por el usuario), por lo que es difícil para los navegadores diferenciar entre lo que el usuario quiere y lo que no. Por ejemplo, si bien es posible bloquear todos los anuncios, bloquear ciertos tipos de anuncios es un problema mucho más difícil y filtrar los comentarios es aún más difícil.

En estas situaciones, el método principal para controlar la experiencia de uno es a través de los controles proporcionados por la plataforma, que con demasiada frecuencia son limitados u opacos. Esto puede conducir a situaciones en las que los usuarios tienen experiencias muy negativas (que incluyen información errónea, intimidación, doxing e incluso amenazas de muerte) y no pueden hacer nada al respecto más allá de desconectarse por completo. Además de los casos en los que la plataforma simplemente no otorga a los usuarios el control, en el pasado las plataformas han cooperado activamente en comportamientos abusivos, por ejemplo, proporcionando una orientación extremadamente detallada para anuncios diseñados para manipular el comportamiento político de los usuarios. Por razones obvias, en estos casos las plataformas no están incentivadas para brindar control sobre estos aspectos de la experiencia del usuario.

No entendemos bien cómo resolver este conjunto de problemas: si bien es posible que las mejoras en los navegadores o la plataforma web puedan ayudar en cierta medida al mostrar más información que luego se puede usar para filtrar, parece probable que crear una más positiva experiencia para todos los usuarios de la Web eventualmente requerirá cambios sociales y de políticas, así como cambios tecnológicos.

internacionalización

Menos del 20% de la población mundial habla inglés y menos del 5% lo habla de forma nativa . La Web no puede servir adecuadamente a la humanidad si proporciona una experiencia de primera clase solo en inglés o en un puñado de idiomas dominantes. Desafortunadamente, el predominio del inglés entre las personas que desarrollan la infraestructura técnica de la Web a menudo ha resultado precisamente en eso. Queremos que la Web funcione bien para todos, independientemente de dónde vivan y qué idiomas hablen.

El primer paso de esto es asegurar que las personas puedan realmente usar la Web en su idioma. La Web nació con innumerables supuestos lingüísticos y culturales en su arquitectura técnica, lo que impedía que los autores construyeran correctamente sitios para muchas de las localidades del mundo. Hemos visto mejoras sustanciales en los estándares e implementaciones para abordar estas brechas. Algunos de estos, como la API de internacionalización de Javascript , están casi completos, pero aún queda mucho trabajo por hacer antes de que los autores puedan crear sitios en cualquier idioma.

Sin embargo, la compatibilidad con los idiomas locales no es suficiente; los sitios deben estar realmente disponibles en los idiomas que la gente entiende. Muchos sitios ampliamente relevantes podrían ser útiles para una audiencia mucho mayor si se superaran las barreras lingüísticas, pero solo existen en inglés y no están traducidos ni siquiera a los idiomas que son compatibles con la plataforma web. Para acercar la Web a todos, debemos hacerlo lo más fácil posible para admitir todas las configuraciones regionales.

Para los sitios que tienen los recursos para invertir en localización, necesitamos tecnología que lo permita. Tradicionalmente, la traducción se realizaba simplemente traduciendo bloques de texto. Las ricas aplicaciones web actuales pueden ser muy dinámicas y, por lo tanto, requieren muchos más matices para manejar géneros, múltiples categorías plurales anidadas, declinaciones y otras características gramaticales que difieren entre idiomas y dialectos. Además, la experiencia de generar localizaciones y aplicarlas a los sitios es propensa a errores y engorrosa. Queremos que sea tan fácil y flexible localizar un sitio como diseñarlo con CSS. Durante la última década, creamos un sistema de este tipo para Firefox, llamado Fluent. Más allá de localizar Firefox, estamos trabajando con otros para llevar las ideas y la tecnología detrás de Fluent a otros proyectos de software del lado del cliente con la biblioteca ICU4X Rust y a la Web con el grupo de trabajo MessageFormat del Consorcio Unicode . Junto con una nueva propuesta para la localización de DOM , vemos una historia mucho más poderosa para la localización de sitios web en el horizonte.

Sin embargo, sabemos que muchos sitios simplemente no pueden invertir en traducción y proporcionarán su contenido solo en una pequeña cantidad de idiomas, tal vez solo uno. En estos casos, tecnologías como la traducción automática (y mejor aún, la traducción del lado del cliente ) aún pueden traer estos sitios al mundo. Estas tecnologías dependen de poder acceder al sitio a nivel semántico para que puedan comprender correctamente el contexto del texto que están traduciendo, ya sea a través de los mecanismos básicos de la Web que permiten la reinterpretación o, mejor aún, proporcionando explícitamente una estructura semántica a través de mecanismos como MessageFormat.

Accesibilidad

Aproximadamente mil millones de personas viven con algún tipo de discapacidad . Para estas personas, la llegada de la Web fue un gran paso adelante en su capacidad de participar en el intercambio de información. A diferencia de otros medios, la estructura simple y la transparencia semántica de la Web temprana hicieron que fuera práctico interpretar con tecnología de asistencia como lectores de pantalla sin mucha o ninguna consideración explícita del sitio (el texto alternativo para las imágenes es una excepción notable, pero a menudo tolerable). En combinación con las funciones del navegador para controlar cosas como el tamaño y el color de la fuente, la Web ofrece una amplia flexibilidad para superar los obstáculos de acceso. Sin embargo, a medida que los sitios evolucionaron de simples documentos a experiencias mucho más ricas y complejas, su accesibilidad ha empeorado .

El mayor desafío es que las técnicas modernas de construcción de sitios tienden a requerir un esfuerzo mucho más intencional por parte del autor para brindar una experiencia accesible. La Web comenzó con solo unos pocos elementos dinámicos, como <textarea>y <button>, que eran fáciles de administrar con tecnología de asistencia. A medida que la Web se volvió más dinámica, hubo una explosión de nuevos widgets implementados en JavaScript con una semántica compleja y matizada que son en gran medida opacas para el navegador, lo que impide que las tecnologías de asistencia los presenten a los usuarios de una forma sensata. Esto llevó a la creación de ARIA., que permitía a los autores web incorporar explícitamente información de accesibilidad en las páginas. Desafortunadamente, la adopción fue deficiente: los sitios tenían que tomar medidas explícitas en lugar de que las cosas funcionaran de forma predeterminada, tenían que lidiar con un nivel de complejidad normalmente reservado para los implementadores de navegadores y no había una forma fácil de verificar que lo habían hecho. correctamente.

Al igual que con el rendimiento y la localización, la realidad es que existe un presupuesto finito de esfuerzo que los sitios dedicarán a la accesibilidad; si queremos que los sitios sean accesibles, debemos ayudar a los autores a crear sitios que sean accesibles de forma predeterminada. Aumentar el uso de enfoques declarativos es clave aquí: cuanta más información semántica tenga el navegador, mejor podrá proporcionar versiones accesibles de contenido. Vemos oportunidades de progreso en este frente, además de mejorar los marcos de JavaScript para ofrecer más widgets con accesibilidad integrada. Sin embargo, en última instancia, es posible que necesitemos aumentar las implementaciones de tecnología de asistencia con heurísticas más complejas para detectar y reparar automáticamente problemas comunes de accesibilidad.

Establecer una barra alta

Queremos que la Web dure mucho tiempo, por lo que es importante hacerlo bien. Esto significa que los proveedores de navegadores deben establecer colectivamente un estándar alto para la calidad de la plataforma web. Cada empresa está influenciada por su propia agenda, necesidades comerciales y política. Si no se controlan, esas presiones pueden resultar fácilmente en la inclusión de características mal concebidas de las que todos se arrepienten. Esta dinámica estaba en plena exhibición en la era de Internet Explorer 6, y todavía estamos analizando las consecuencias.

El proceso de desarrollo de múltiples partes interesadas de la Web está lejos de ser perfecto, pero sin embargo sirve como un poderoso baluarte contra una agenda corporativa del día que empuja malas ideas a la Web. Todas las organizaciones sufren este punto ciego, incluida Mozilla. Hace algún tiempo, propusimos una gran cantidad de API web a medias como parte de nuestra iniciativa FirefoxOS para construir un sistema operativo basado en la web. Otros proveedores ignoraron o rechazaron en gran medida estas propuestas, lo que fue frustrante en ese momento, pero por lo que estamos profundamente agradecidos hoy. Creemos que la Web merece un listón muy alto e invitamos a otros a exigirnos que lo hagamos.

Móvil

Si bien la Web ha tenido un éxito fantástico en el desplazamiento de las aplicaciones de "escritorio" de estilo antiguo en las computadoras personales, las aplicaciones nativas siguen siendo dominantes en los dispositivos móviles. para usuarios de escritorio. Hay una serie de razones por las que los desarrolladores a menudo eligen apuntar a las aplicaciones móviles en lugar de la Web, que incluyen:

• Las tiendas de aplicaciones integradas reducen drásticamente la fricción de encontrar e instalar software nativo. Además, debido a que esas aplicaciones están seleccionadas y (hasta cierto punto) protegidas, los usuarios se sienten más seguros al instalarlas que al descargar un ejecutable en su computadora personal.
• Las aplicaciones tienen una historia de monetización incorporada facilitada por el proveedor del sistema operativo (aunque con una fracción significativa pagada a la plataforma). Por el contrario, la monetización web es en gran parte DIY.
• Las aplicaciones móviles suelen ser más fluidas y funcionan mejor en los dispositivos previstos. Los equipos de Android e iOS han invertido años en la creación de conjuntos de widgets rápidos, fluidos y de alta calidad que permiten a cualquier desarrollador ofrecer una buena experiencia. Por el contrario, incluso los desarrolladores experimentados luchan por producir experiencias comparables a través de la plataforma web. Como ejemplo extremo, en los sistemas operativos de escritorio, Firefox usa tecnologías web para representar su interfaz de usuario, pero en Android descubrimos que necesitábamos usar los widgets nativos.
• Las aplicaciones nativas pueden aprovechar capacidades que no ofrece la Web, como aparecer en la pantalla de inicio o acceder a ciertos sensores.

Si bien ha habido un progreso significativo para hacer posible que las aplicaciones basadas en la web actúen más como aplicaciones móviles en forma de aplicaciones web progresivas (PWA), las aplicaciones nativas aún dominan el espacio. En varios casos, los desarrolladores optarán por tener una PWA y una aplicación nativa, pero esto solo sirve para resaltar la brecha de calidad entre las experiencias nativa y web.

Gran parte de la discusión sobre las capacidades móviles ha sido impulsada por el Proyecto Fugu de Google., cuyo objetivo es "cerrar las brechas en las capacidades de la web permitiendo que nuevas clases de aplicaciones se ejecuten en la web", principalmente agregando nuevas API que brindan capacidades que son nuevas para la web. Si bien es cierto que algunas aplicaciones que actualmente se implementan como aplicaciones nativas podrían construirse como aplicaciones web si solo estuviera disponible "API X", la evidencia de que esto resultaría en un cambio generalizado de nativo a la Web es escasa. Por el contrario, el hecho de que los desarrolladores elijan crear aplicaciones nativas en lugar de PWA, incluso cuando no necesitan ninguna capacidad especial, sugiere que esta estrategia no será efectiva y, a pesar de las numerosas API de capacidad nueva en Chrome, los desarrolladores aún parecen preferir aplicaciones nativas.

Incluso para los casos de uso de navegación casual donde brilla la Web, sabemos que la experiencia es dramáticamente peor en los dispositivos móviles. Esto se debe a una combinación de factores que incluyen las limitaciones de los tamaños de pantalla pequeños, procesadores generalmente más lentos, duración de la batería, API de animación deficientes y redes más lentas. Todo esto conduce a una situación en la que el móvil es una experiencia mucho peor que el escritorio, incluso en el mismo contenido, especialmente cuando el contenido, o los navegadores, solo reflejan la experiencia del escritorio reducida al factor de forma móvil y las expresiones idiomáticas.

La conclusión que sacamos de esto es que el lugar para comenzar cuando se piensa en dispositivos móviles es abordar los casos de uso que, en principio, están bien atendidos por el modelo web, pero que en la práctica no han sido bien atendidos por la web móvil. En gran medida, esto consiste en las mejoras incrementales que hemos discutido anteriormente en este documento (mejorar el rendimiento y la capacidad de respuesta generales, los marcos que funcionan bien de forma predeterminada y las posibilidades del navegador y del marco que se adaptan a múltiples tamaños de pantalla). Nada de esto es imposible, es simplemente el arduo trabajo de trabajar sistemáticamente con todas las fuentes de fricción que se interponen en el camino para tener una experiencia web de primera clase en dispositivos móviles.

Destaca una mejora en particular: la monetización. La gran mayoría de la Web y gran parte del ecosistema de aplicaciones se financia con publicidad; sin embargo, sabemos que la publicidad gráfica es especialmente problemática en la Web móvil, tanto por el escaso espacio en pantalla como por el impacto en el rendimiento de la red al cargar los propios anuncios. Una mejor historia de monetización no solo haría que la Web móvil fuera más atractiva, sino que también ayudaría a eliminar uno de los principales factores que impulsan a las personas hacia las aplicaciones nativas.

Nuestro objetivo no es desplazar las aplicaciones nativas por completo en dispositivos móviles. Más bien, es para abordar las fuerzas que empujan a los usuarios móviles fuera de la Web, incluso para los casos de uso casual en los que la Web debería brillar. El éxito aquí parece un mundo en el que la Web funciona tan bien en estas situaciones que los usuarios en su mayoría son indiferentes a si sus interacciones son con aplicaciones o con sitios web. Queremos un mundo en el que los desarrolladores no se vean obligados a invertir en una aplicación simplemente para obtener una experiencia de usuario aceptable, sino que aún puedan crear aplicaciones en situaciones en las que eso tenga sentido.

Sustentabilidad

Internet consume mucha electricidad. Las estimaciones varían , pero incluso las más conservadoras muestran centros de datos , infraestructura de comunicaciones y dispositivos de consumo.cada uno consume cientos de Teravatios-hora por año. Esto representa varios por ciento del consumo mundial de electricidad, gran parte del cual es generado por combustibles fósiles. Simultáneamente, Internet también es una fuerza para reducir las emisiones de carbono al reemplazar las actividades que consumen mucha energía, como las reuniones que requieren muchos viajes y el correo en papel, por videoconferencias y mensajes electrónicos. También aporta valor al mundo de muchas otras maneras, y las personas adaptan rápidamente sus vidas para depender de sus capacidades en expansión. Como tal, simplemente apagarlo o degradar su funcionalidad (por ejemplo, almacenar y transmitir videos a baja resolución) para conservar energía no son soluciones realistas.

Al mismo tiempo, sabemos que este consumo de energía contribuye al cambio climático global. Si bien abordar este problema requerirá en última instancia descarbonizar la generación de electricidad global, debemos buscar áreas en las que Internet pueda mejorar hoy. En este sentido, vemos dos propiedades clave en Internet que crean oportunidades para mitigar su huella de carbono antes de una red totalmente renovable.

La primera propiedad es la relativa independencia de la ubicación del cálculo. Si bien los puntos finales de los clientes y la infraestructura de red no son fáciles de mover, los centros de datos se pueden ubicar de manera mucho más inteligente y colocar servicios para muchos clientes diferentes. Esto les permite ubicarse en lugares donde la energía limpia ya es abundante, o usar su escala y flexibilidad para negociar capacidad renovable adicional en áreas que carecen de ella. En la medida en que los incentivos normativos y de mercado sean insuficientes, el reciente repunte de los compromisos corporativos voluntarios con los servicios de nube sostenibles demuestra el poder de la opinión pública para impulsar estos cambios.

La segunda propiedad es la naturaleza de baja fricción de la distribución de software, lo que significa que las decisiones de diseño en protocolos e implementaciones ampliamente utilizados pueden tener un impacto enorme en el consumo de electricidad. Esto significa que debemos ser conscientes de estas consideraciones al diseñar nuevos sistemas que se implementarán a escala. En muchos casos, los incentivos adecuados ya existen. Por ejemplo, el software de consumo se ejecuta cada vez más en dispositivos alimentados por batería, lo que crea una presión competitiva para ser juiciosos sobre el consumo de energía (sin duda es algo en lo que dedicamos mucho esfuerzo en Firefox). Esto también tiene la ventaja de permitir que la Web funcione en dispositivos de bajo consumo, lo que reduce la tasa a la que las personas tienen que reemplazar sus dispositivos y el impacto ambiental concomitante. Sin embargo, este no es siempre el caso. Por ejemplo,consume una enorme cantidad de electricidad e incentiva comportamientos perjudiciales para el medio ambiente y para los usuarios . Debemos ser cuidadosos en el diseño de nuevos sistemas para asegurarnos de que los requisitos permitan y alienten las implementaciones para operar de manera energéticamente eficiente, y luego trabajar para identificar las mayores oportunidades para ahorrar energía en los sistemas existentes que operan a escala y dirigir nuestros esfuerzos hacia optimizándolos.

Lo que no sabemos

Hay algunos problemas con la Web que nos parecen preocupantes pero que aún no tenemos una estrategia clara para abordar. Tenemos algunas ideas en estas áreas, pero no balas de plata. En última instancia, nuestro objetivo es colaborar con una amplia coalición de organizaciones e individuos con ideas afines para identificar y aplicar medidas efectivas.

Centralización

Queremos una Web sin guardianes. La arquitectura abierta y distribuida de la Web implica una centralización inherente mucho menor que otras modalidades como la radio o la televisión. Sin embargo, existen poderosas fuerzas técnicas y de mercado que incentivan la consolidación, y hemos visto cómo la Web se desplaza hacia la centralización a lo largo de una serie de ejes, incluidos los proveedores de red, las empresas de hospedaje, los desarrolladores de software y las plataformas de contenido. La última categoría es quizás la más importante: debido a que se accede a una gran fracción del contenido desde una pequeña cantidad de plataformas, estas ejercen un enorme control sobre la experiencia del usuario en la Web. Incluso en el mejor de los casos, esto tiene el potencial de privilegiar ciertas perspectivas sobre otras, pero como han demostrado los acontecimientos recientes,

monetización

La Web se financia principalmente a través de la publicidad. Si bien esto tiene la ventaja de que permite a las personas acceder a grandes cantidades de contenido de forma gratuita, también tiene muchas consecuencias negativas. Las personas encuentran que los anuncios en sí mismos distraen y molestan, lo que los lleva a instalar bloqueadores de anuncios que pueden socavar el modelo comercial de muchos editores. Además, con el tiempo, la publicidad en la Web ha pasado de simples anuncios publicitarios a anuncios dirigidos individualmente, que dependen de tecnologías de vigilancia y creación de perfiles que son profundamente problemáticas. Esto no es bueno para los usuarios. Sin embargo, incluso los editores generalmente consideran que la situación es insatisfactoria, ya que una parte cada vez mayor de sus ingresos termina en los bolsillos de las grandes redes publicitarias y el valor de su relación con el usuario se filtra a sitios web de terceros.

Si bien esta es claramente una pregunta central para la salud de la Web, aún no tenemos una buena respuesta. Estamos tomando algunas medidas unilaterales para proteger a nuestros usuarios, pero reconocemos que esto no será suficiente. En última instancia, necesitamos colaborar en todo el ecosistema para diseñar mejores modelos de monetización que funcionen para usuarios y editores. Nos alienta ver a los editores y otros considerando modelos alternativos. Por ejemplo:

• Algunos editores están explorando métodos de publicidad contextual que aprovechan el aprendizaje automático para ofrecer anuncios de alto valor sin rastrear a los usuarios.
• Ha surgido una variedad de aplicaciones y servicios para ofrecer valor a los usuarios finales al tiempo que permite a los editores monetizar a los usuarios que nunca pagarían por una suscripción.
• Se están realizando algunos esfuerzos para examinar cómo hacer que el ecosistema de publicidad gráfica sea más respetuoso con la privacidad del usuario.

Queda por ver si alguno de estos esfuerzos dará sus frutos, pero resolver este problema es esencial para el futuro de la Web.

Pensamientos finales

La Web es un recurso enorme para la humanidad y Mozilla se compromete a protegerla y mejorarla. Poderosas fuerzas económicas y tecnológicas se han combinado para hacer que la Web sea como es hoy. Mejorarlo no será fácil y no podemos hacerlo solos. Algunas partes del camino a seguir son claras y otras, especialmente cómo abordar la monetización y la centralización, son mucho más turbias, pero creemos que todos podemos trabajar juntos como comunidad para hacer una Web que sea verdaderamente abierta y accesible para todos.