Cuando Google presentó Manifest V3 en 2019, los desarrolladores de extensiones web se alarmaron por la cantidad de funcionalidades que se quitarían para las características que proporcionan a los usuarios. Especialmente características como bloquear rastreadores y proporcionar conexiones seguras. Esta nueva iteración de la interfaz de extensiones web de Google Chrome todavía tiene defectos que podrían abordarse a través del consenso reflexivo de la comunidad de desarrolladores de extensiones web. Sin embargo, dos años y pico de discusiones y conflictos en torno a Manifest V3 han dejado al descubierto el problemático poder que tiene Google sobre la forma en que millones de personas experimentan la web. Con el reciente anuncio de la transición oficial a Manifest V3 y la desaparición de Manifest V2 en 2023, muchas extensiones web basadas en la privacidad verán mitigada su capacidad de proteger a los usuarios.
Las reclamaciones de seguridad y privacidad que Google ha hecho sobre las extensiones web pueden o no ser abordadas con Manifest V3. Pero el hecho es que las extensiones en las que los usuarios han confiado para su privacidad se verán fuertemente obstaculizadas si la propuesta actual sigue adelante. Una medida que se presentó como centrada en el usuario, en realidad le quita el poder de bloquear el seguimiento no deseado para sus necesidades de seguridad y privacidad.
Gran influencia, poco desafío
Primero, una breve lección de historia. En 2015, Mozilla anunció su movimiento para adoptar la API webRequest, ya utilizada por Chrome, en un esfuerzo por sincronizar el panorama para los desarrolladores de extensiones web. Avanzando rápidamente hasta el anuncio de Manifest V3 en 2019, Google puso a Mozilla en la posición de elegir entre dividir o sincronizar con su navegador Firefox. Dividir significaría tomar una posición firme contra Manifest V3 como alternativa y apoyar la innovación de los desarrolladores de extensiones web en los controles de privacidad del usuario. Sincronizar significaría seguir el plan de Google en aras de no dividir más el desarrollo de extensiones web.
Mozilla ha decidido dar soporte a la API de bloqueo webRequest de Manifest V2 y a la API declarativaNetRequest de MV3 por ahora. Un movimiento que está muy condicionado por el empuje de Google para hacer de MV3 el estándar, el apoyo a ambas APIs es sólo la mitad de la batalla. MV3 dicta un cambio en el ecosistema que limita las extensiones de MV2 y probablemente obligará a las extensiones basadas en MV2 a ajustarse a MV3 en un futuro próximo. El reconocimiento por parte de Mozilla de que MV3 no satisface las necesidades de los desarrolladores de extensiones web demuestra que MV3 aún no está listo para el momento de máxima audiencia. Sin embargo, existe una presión para que las extensiones estables y de confianza asignen recursos para portar sus extensiones a versiones más limitadas de sí mismas con una API menos estable.
Cuestiones técnicas del Manifiesto V3
Aunque se ha avanzado en la seguridad y privacidad del navegador, las extensiones web como Privacy Badger, NoScript y uBlock Origin han llenado el vacío de proporcionar el control granular que los usuarios desean. Uno de los cambios más significativos de Manifest V3 es la eliminación de la API de bloqueo de webRequest y la flexibilidad que ofrecía a los desarrolladores para gestionar mediante programación las solicitudes de red en nombre del usuario. La API declarativa de peticiones de red, que sustituirá a la API de peticiones web bloqueantes, incluye límites bajos en cuanto al número de sitios que pueden cubrir estas extensiones. Otro mandato es pasar de Background Pages, un contexto que permite a los desarrolladores de extensiones web evaluar y depurar adecuadamente, a un contexto alternativo menos potente llamado Background Service Workers. Este contexto no se construyó originalmente pensando en el desarrollo de extensiones web, lo que ha dado lugar a su propia conversación en muchos foros.
En resumen, los Service Workers estaban pensados para un ciclo de sueño/despertar de la entrega de activos web al usuario, por ejemplo, el almacenamiento en caché de imágenes e información consistente para que el usuario no tenga que utilizar muchos recursos cuando se vuelva a conectar a ese sitio web con una conexión limitada. Las extensiones web necesitan una comunicación persistente entre la extensión y el navegador, a menudo basada en la interacción con el usuario, como la posibilidad de detectar y bloquear los rastreadores de anuncios cuando se cargan en la página web en tiempo real. Esto ha dado lugar a una importante lista de cuestiones que tendrán que abordarse para cubrir muchos casos de uso válidos. Estas discusiones, sin embargo, se están produciendo mientras se pide a los desarrolladores de extensiones web que se adapten a MV3 en el próximo año sin un flujo de trabajo estable disponible con problemas pendientes como la falta de un contexto de trabajador de servicios definido para las extensiones web, el soporte pendiente de WebAssembly y la falta de soporte consistente y directo del propio equipo de extensiones de Chrome.
Una tormenta de arena en materia de privacidad
Desde el anuncio de Manifest V3, Google ha anunciado varias propuestas controvertidas de "Privacy Sandbox" para los mecanismos de privacidad de Chrome. Las discusiones más importantes sobre estas propuestas tienen lugar en el World Wide Web Consortium, o W3C. Aunque técnicamente "cualquiera" puede escuchar las reuniones abiertas, sólo los miembros del W3C pueden proponer documentación formal sobre las especificaciones y ocupar puestos de liderazgo. Ser miembro tiene sus propios gastos de honorarios y compromiso de tiempo. Esto es algo que una gran corporación multinacional puede superar fácilmente, pero puede ser una barrera para los grupos centrados en el usuario. A menos que se aborden directamente estas dinámicas de poder, la voz de un participante se hace más fuerte con la cuota de mercado.
Este año, tras las numerosas discusiones en el foro de Google en torno a Manifest V3, se ha formado un grupo comunitario de WebExtensions en el W3C. La participación en el grupo comunitario no requiere ser miembro del W3C, pero no producen estándares. Presidido por empleados de Google y Apple, este grupo afirma que "al especificar las API, la funcionalidad y los permisos de las WebExtensions, podemos facilitar aún más a los desarrolladores de extensiones la mejora de la experiencia del usuario final, a la vez que los movemos hacia API que mejoran el rendimiento y evitan el abuso".
Pero este movimiento a favor de una mayor democracia habría sido más potente y eficaz antes del impulso unilateral de Google para imponer el Manifiesto V3. Esta historia es decepcionantemente similar a lo que ocurrió con la tecnología AMP de Google: sólo se ofrecieron debates más democráticos y una gobernanza abierta después de que AMP se hiciera omnipresente.
Con la prevista depreciación de las extensiones Manifest V2, la decisión ya está tomada. El resto de la comunidad de extensiones web se ve obligada a cumplir, desviarse o abandonar un gran ecosistema de extensiones de navegador que no incluye a Chrome. Y eso es más difícil de lo que parece: Chromium, el motor de navegador de código abierto basado en Chrome, es la base de Microsoft Edge, Opera, Vivaldi y Brave. Vivaldi, Brave y Opera han hecho declaraciones sobre MV3 y sus planes para preservar los bloqueadores de anuncios y las características de preservación de la privacidad de MV2, sin embargo, los efectos dominantes son claros cuando Chrome hace un cambio importante.
¿Cómo es un mejor MV3?
Se han planteado algunas preocupaciones y peticiones muy válidas al Grupo de la Comunidad de Extensiones Web del W3C que ayudarían a impulsar el reino de las extensiones web a un lugar mejor.
- Hacer que la API declarativeNetRequest sea opcional en Chrome, como lo es actualmente. La API proporciona un camino para las extensiones que tienen características más estáticas y simplistas sin necesidad de implementar APIs más potentes. Las extensiones que utilizan la API webRequest de bloqueo, con su potencia añadida, pueden ser objeto de un escrutinio adicional en la revisión de la presentación.
- En un esfuerzo por calmar los problemas técnicos en torno a los Background Service Workers, Mozilla propuso en el Grupo W3C una alternativa a los Service Workers para las extensiones web, denominada "Limited Event Pages". Este enfoque restaura muchas de las APIs estándar de los sitios web y el soporte perdido con los Background Service Workers. Safari expresó su apoyo, pero Chrome ha expresado su falta de apoyo con razones pendientes pero no explícitamente declaradas en el momento de este post.
- No introducir más regresiones en funcionalidades importantes que tiene MV2. Por ejemplo, poder inyectar scripts antes de la carga de la página. Esto se rompe con las modificaciones pendientes en MV3.
Aunque uno pueda ver los movimientos entre los cambios en las API de las extensiones web y las propuestas de mecanismos de privacidad como dos esfuerzos separados, esto habla del poder expansivo de cómo una compañía puede impactar en el ecosistema de la web; tanto cuando hacen grandes cosas, como cuando toman malas decisiones. La pregunta que hay que hacerse es quién tiene la carga de hacer cumplir lo que es justo: ¿las organizaciones de normalización que se comprometen con las propuestas de las grandes empresas o las propias empresas? En segundo lugar, ¿quién tiene más poder si un grupo dice "no" y otro dice "sí"? Los socios de la comunidad, los defensores y las empresas más pequeñas pueden decir que no y no trabajar con empresas que entran en la sala con frecuencia con propuestas preocupantes, pero luego esa empresa puede alegar que el silencio significa consenso cuando deciden seguir adelante con un plan. Ya se produjo una dinámica similar cuando el W3C lidió con el Do Not Track (DNT), donde los defensores de mecanismos de privacidad más débiles fingieron preocupación por la privacidad y la elección del usuario. Así que en este caso, las grandes empresas como Google pueden tomar decisiones nefastas o ampliamente útiles sin mucho incentivo para decirse a sí mismas que no. En el caso de MV3, dieron espacio y tiempo para discutir los problemas con la comunidad de extensiones web. Esa es la norma mínima para hacer un cambio tan grande, así que felicitar a una entidad poderosa por dar cabida a muchas otras voces no haría más que aumentar el sentimiento de que esto debería ser la norma en la política de la web abierta.
Por muy buena que sea una propuesta, la realidad es que las experiencias de millones de personas en Internet suelen quedar a merced de la ética de unos pocos en empresas y organizaciones de normalización.
