Si bien estamos agradecidos de que los paquetes web y las sugerencias relacionadascomprometidos a abordar desafíos específicos, creemos que hay mejores formas de lograr los mismos objetivos sin poner en peligro la naturaleza abierta, transparente y centrada en el usuario de la web. Una posible alternativa es utilizar compromisos firmados para subrecursos descargables de forma independiente. La descripción de las alternativas requerirá un artículo separado, y algunas ya se han compartido con los autores de la especificación.
La web es un sistema abierto único gracias a los enlaces URL.
La web es valiosa porque está centrada en el usuario, controlada por el usuario y editada por el usuario. Incluso los usuarios con poca experiencia pueden averiguar qué recursos web hay en una página y decidir qué debe cargar su navegador. Incluso si no es un experto, puede usar esto e instalar las extensiones o herramientas adecuadas para proteger su privacidad.
El enfoque de la Web en los usuarios es diferente de cómo funcionan la mayoría de las aplicaciones y los sistemas de distribución de información. La mayoría de las aplicaciones son una colección compilada de código y recursos que son difíciles o incluso imposibles de separar entre sí para evaluarlos por separado. Y esta importante distinción explica por qué hay tantas herramientas de protección de la privacidad para la web y tan pocas para las aplicaciones "binarias".
Básicamente, lo que hace que la web sea diferente de otros sistemas, más abierta, más centrada en el usuario y diferente de otras aplicaciones es la URL. Dado que una URL generalmente apunta a un solo recurso, los investigadores y activistas pueden estudiar y sacar conclusiones sobre estas URL con anticipación. Otros usuarios pueden utilizar esta información para tomar decisiones sobre si desean descargar a qué apunta la URL y cómo hacerlo. Más importante aún, los expertos pueden descargar tracker.com/code.js , decidir que viola la privacidad y compartir esta información con otros para que sepan que no deberían descargar este código en el futuro.
Existen excepciones a esta regla, y no existen tales requisitos en la plataforma web; sin embargo, generalmente se espera que las URL permanezcan esencialmente sin cambios. Estas expectativas se encuentran dispersas por toda la plataforma web, en aspectos de políticas de almacenamiento en caché, en instrucciones de biblioteca para implementar código, etc.
Los Web Bundles hacen que las URL carezcan de significado
Google propuso recientemente tres estándares interconectados: Web Bundles, Signed HTTP Exchanges (a veces abreviado como SXG) y Loading. Básicamente, en este artículo, por Web Bundles, nos referiremos a los tres. Hasta ahora, los Web Bundles se han promocionado como estándares para su uso en sistemas publicitarios (TURTLEDOVE, SPARROW) y como parte del futuro sistema AMP de Google, aunque me parece que esto es solo la punta del iceberg.
En un nivel alto, los Web Bundles son una forma de agrupar activos. En lugar de descargar las páginas, las imágenes y los archivos JavaScript por separado, su navegador descarga el "paquete" completo, un archivo que incluye toda la información para cargar la página. Las URL dejan de ser enlaces globales comunes a los recursos de la red y se convierten en índices arbitrarios dentro de los paquetes.
En otras palabras, los Web Bundles convierten los sitios en archivos PDF (o archivos Flash SWF). PDF incluye todas las imágenes, videos y scripts necesarios para renderizar el PDF; no los descarga individualmente. Esto tiene sus ventajas de conveniencia, pero hace que sea imposible examinar partes individuales del PDF independientemente del archivo completo. Por lo tanto, no existen herramientas de bloqueo de contenido para PDF. PDF es una propuesta de todo o nada, y los Web Bundles convertirán los sitios web en propuestas similares.
Al cambiar las URL de identificadores globales significativos a índices arbitrarios específicos de paquetes, los Web Bundles brindan a los anunciantes y rastreadores nuevas y poderosas formas de eludir las herramientas de privacidad y seguridad. La siguiente sección proporciona ejemplos seleccionados para ilustrar este punto.
Los Web Bundles permitirán que los sitios eludan las herramientas de privacidad y seguridad
Las URL en Web Bundles son enlaces arbitrarios a recursos dentro de un paquete, no enlaces a recursos accesibles globalmente. Esto le da a los sitios varias formas de eludir las herramientas de privacidad y seguridad.
Por supuesto, pueden hacer referencia a recursos fuera del paquete, pero este comportamiento haría que el sistema del paquete no tuviera sentido, por lo que este problema no se trata en este artículo.
La principal solución se debe al hecho de que Web Bundles crea un espacio de nombres local para los recursos, independientemente de lo que vea el resto del mundo, lo que puede generar todo tipo de confusión con los nombres, negando los años de trabajo para mejorar la privacidad y la seguridad que los activistas han estado haciendo. privacidad e investigadores. A continuación, se describen solo tres formas en que los sitios web habilitados para Web Bundles aprovechan esta confusión.
Evitando las herramientas de seguridad mediante la aleatorización de URL
Anteriormente, si un sitio web deseaba utilizar un script para realizar un seguimiento de las acciones del usuario, incluía una etiqueta <script> en la página HTML que apuntaba al mismo script con una URL sin cambios. Es posible que investigadores o grupos de usuarios hayan agregado esta URL a una lista de EasyPrivacy para que las preocupaciones sobre la privacidad puedan visitar el sitio sin descargar el script de seguimiento. Así es como funcionan la mayoría de las herramientas de bloqueo en la actualidad.
Los Web Bundles facilitan que los sitios eludan dichas herramientas al aleatorizar la URL de los recursos no deseados. Lo que en la web actual tiene un nombre global, digamos example.org/tracker.js, en un Web Bundles puede nombrar 1.js, en otro 2.js, en el tercero 3.js, y así sucesivamente. Los Web Bundles fomentan esta práctica haciéndola gratuita para los sitios. El almacenamiento en caché no tiene sentido (ya que está distribuyendo todos los recursos a cada usuario y almacenando en caché todo el paquete), y el marcado de URL no es necesario (dado que el paquete enviado al usuario ya contiene URL aleatorias).
Evitando las herramientas de privacidad mediante la reutilización de URL
Para empeorar las cosas, los Web Bundles permitirán que los sitios eludan las herramientas de bloqueo asegurándose de que las mismas URL apunten a diferentes recursos en cada paquete. En la web actual, digamos que example.org/ad.jpg apunta a lo mismo para cualquier usuario. Es difícil para un sitio web hacer que la misma URL devuelva dos imágenes diferentes. Como resultado, las herramientas de bloqueo pueden bloquear ad.jpg sabiendo que están bloqueando anuncios para todos. Prácticamente no hay riesgo de que para algunos sea un anuncio y para otros sea el logotipo de una empresa (esto no es imposible, pero sí difícil; el caso es que los Web Bundles convierten los métodos de elusión, que hoy son complejos y frágiles, en simples y gratuitos).
Los Web Bundles modifican este sistema de manera peligrosa. Example.org puede hacer sus paquetes de manera que en uno de ellosexample.org/ad.jpg apuntará a un anuncio, en otro, al logotipo del sitio, en un tercero, a otra cosa. Esto no solo hará que sea mucho más difícil para los investigadores compilar listas, o incluso lo hará imposible, sino que brindará a los sitios nuevas formas de envenenar las listas de bloqueo.
Eludir las herramientas de privacidad al ocultar URL peligrosas
Finalmente, los Web Bundles abren soluciones aún más peligrosas. En la actualidad, grupos como uBlock Origin y Navegación segura de Google enumeran las URL que incluyen recursos web maliciosos y peligrosos. Estos proyectos consideran que la URL es el único, o al menos el más importante, identificador de un recurso peligroso. La naturaleza universal y global de la URL hace que estas listas sean útiles.
Una vez más, los paquetes web permiten que los sitios eludan esta protección al permitirles vincularse a recursos dañinos conocidos a través de URL verificadas. En la web, es muy difícil conseguir que los sitios traten cdn.example.org/cryptominer.js como si fuera cdn.example.org/jquery.js (y viceversa). En Web Bundles, esta será una tarea trivial.
Web Bundles ,
Los desarrolladores y partidarios de las especificaciones de Web Bundles argumentan que no hay nada nuevo aquí y que todos los métodos anteriores para evitar la protección ya existen. Técnicamente, esto es cierto, sin embargo, en esencia, tal declaración ignora la economía del proceso y, por lo tanto, no describe la situación en su conjunto. Los Web Bundles hacen que estas tecnologías costosas, poco confiables y complejas sean baratas o incluso gratuitas.
Por ejemplo, los sitios web pueden hacer que varias URL apunten al mismo archivo para dificultar la vida de los bloqueadores de anuncios, pero en la práctica es difícil para los sitios hacer esto. La aleatorización de URL perjudica el almacenamiento en caché, requiere almacenar la asignación de URL aleatoria a los recursos deseados y pasar esa información a la CDN, etc. Los sitios pueden hacer esto, pero es costoso y difícil, por lo que rara vez se hace.
De manera similar, los sitios de hoy pueden usar cookies u otros mecanismos de seguimiento de usuarios para hacer que la misma URL funcione de manera diferente para diferentes usuarios, realizando los diversos ataques de ofuscación de URL descritos anteriormente. Sin embargo, este método no es confiable (¿qué hacer con los nuevos visitantes?), Complejo (necesita mantener y distribuir la visualización de cookies y valores de recursos) y costoso (la mayoría de los servidores web y servicios de alojamiento dependen del almacenamiento en caché, por lo que estas tecnologías para sitios que no son propiedad de grandes corporaciones son prácticamente no están disponibles).
En general, los Web Bundles facilitan mucho el comportamiento no deseado al hacerlo más económico.
Otros problemas
Este artículo describe el daño que los Web Bundles pueden causar a las herramientas de privacidad y seguridad. Pero existen otros problemas con este y los estándares relacionados. En particular, estos son:
- SXG no tiene un sistema de retroceso. Si un recurso malicioso aparece accidentalmente en el sitio hoy, el sitio simplemente puede actualizarse. Si un sitio firma Web Bundles usando SXG, no hay una forma clara para que el firmante les diga a todos que "ya no confíen en este paquete en particular".
- Interoperabilidad con Manifest v3: Manifest v3 restringe las extensiones para que utilicen patrones de URL para el bloqueo. Los Web Bundles hacen que estas URL carezcan de significado. La combinación de estas dos cosas permitirá que los sitios eviten por completo el bloqueo.
- Confusión con las fuentes. Loading + SXG le permite descargar contenido de un servidor y luego ejecutarlo con la configuración de privacidad y seguridad de otro servidor. El potencial de confusión de los usuarios es enorme y, aunque estamos seguros de que los empleados de Google están trabajando activamente para abordar este problema, el riesgo para los usuarios sigue siendo muy alto.
Conclusión
Brave está trabajando para mejorar la privacidad web, tanto en nuestro navegador como en las herramientas que creamos y distribuimos, y en la defensa que hacemos para las organizaciones de estándares. Este artículo es solo un ejemplo de nuestro trabajo para garantizar que los estándares web continúen centrándose en la privacidad, la transparencia y la responsabilidad.
Intentamos durante mucho tiempo, pero fue en vano, prestar atenciónautores del estándar Web Bundles sobre los problemas enumerados. Instamos a Google y Web Bundles a detener esta propuesta hasta que se resuelvan los problemas de privacidad y seguridad descritos en este artículo. También alentamos a los miembros de las comunidades de seguridad y privacidad web a unirse a esta discusión y no implementar este estándar hasta que se resuelvan los problemas descritos.
Una forma de hacerlo es describir estos problemas en los comentarios de la publicación que hizo el autor de este artículo sobre el proyecto Web Bundles. Otras opciones son hacer nuevas notas de especificación, decirle a los desarrolladores de su navegador cuán importantes son las herramientas de protección de privacidad para usted personalmente y qué riesgo representan estos nuevos estándares para esas herramientas.