Chrome 88 utilizara nuevo manifiesto incompatible con uBlock Origin

Los desarrolladores de Google que están a cargo del navegador web «Google Chrome» han anunciado la inclusión en Chrome 88 (que se espera que lance el 19 de enero de 2021) de la tercera edición del manifiesto, el cual ha causado mucho conflicto entre los desarrolladores de extensiones para el navegador, debido a la violación del trabajo de muchas adiciones para bloquear contenido inapropiado y seguridad.

Cabe señalar que la compatibilidad con complementos que utilizan la segunda versión del manifiesto se mantendrá durante algún tiempo. Aún no se ha determinado el final del soporte para Manifest V2, pero el período de migración al nuevo manifiesto durará al menos un año.

Como recordatorio, el manifiesto de Chrome define las capacidades y los recursos proporcionados por los complementos.

El nuevo manifiesto es parte de una iniciativa para mejorar la seguridad, la privacidad y el rendimiento de los complementos. El objetivo principal de los cambios es facilitar la creación de complementos seguros y de alto rendimiento, y dificultar la creación de complementos lentos y no seguros.

Con la introducción de Manifest V3, no permitiremos el código alojado de forma remota. Este mecanismo es utilizado como un vector de ataque por los malos actores para eludir las herramientas de detección de malware de Google y representa un riesgo significativo para la privacidad y seguridad del usuario.

La principal insatisfacción con el nuevo manifiesto está relacionada con el fin del soporte para el modo de bloqueo de funcionamiento de la API webRequest, que se limitará al modo de solo lectura.

Se hará una excepción solo para la edición Chrome for Enterprise, que seguirá siendo compatible con la API webRequest. Mozilla ha decidido no seguir el nuevo manifiesto y mantendrá Firefox utilizando completamente la API webRequest. En su lugar, API webRequest para filtrar contenido en el nuevo manifiesto propuso un declarativo API declarativeNetRequest.

La nueva API declarativeNetRequest proporciona acceso a un motor de filtrado integrado universal listo para usar que procesa de forma independiente las reglas de bloqueo, no permite el uso de algoritmos de filtrado personalizados y no permite establecer reglas complejas y superpuestos entre sí dependiendo de las condiciones.

Como motivo de la transición a la API declarativeNetRequest, se señalan las preocupaciones sobre la privacidad: con la nueva API, los complementos perderán el acceso ilimitado a todos los flujos de datos, que pueden incluir la información confidencial del usuario.

Google ha tratado de mitigar algunos de los problemas expresados ​​durante el debate con los desarrolladores de complementos, que se verán afectados por la API declarativeNetRequest (por ejemplo, uBlock Origin, cuyo autor considera que la funcionalidad declarativeNetRequest es insuficiente para que el complemento funcione correctamente), dejará de funcionar.

De acuerdo con los deseos de los desarrolladores de complementos, se ha agregado soporte para usar declarativeNetRequest para varios conjuntos de reglas estáticas, filtrar por expresiones regulares, modificar encabezados HTTP, cambiar y agregar reglas dinámicamente, eliminar y reemplazar parámetros de solicitud.

El nuevo manifiesto también presenta los siguientes cambios que afectan la compatibilidad de complementos:

• La transición a la ejecución de los trabajadores del servicio en forma de procesos en segundo plano, lo que requerirá que los desarrolladores cambien el código de algunas adiciones.
• Nuevo modelo granular para solicitar permisos: el complemento no podrá activarse para todas las páginas a la vez (se ha eliminado el permiso «all_urls»), pero solo funcionará en el contexto de la pestaña activa, es decir el usuario deberá confirmar el trabajo del complemento para cada sitio.
• Cambia el procesamiento de solicitudes de origen cruzado: de acuerdo con el nuevo manifiesto, los scripts de procesamiento de contenido estarán sujetos a las mismas restricciones de permisos que para la página principal en la que están incrustados estos scripts (por ejemplo, si la página no tiene acceso a la API de ubicación, entonces el script los complementos tampoco tendrán este acceso).
• Evita la ejecución de código descargado de servidores externos (cuando el complemento carga y ejecuta código externo).

Finalmente si quieres conocer más al respecto de la nota, puedes consultar la publicación original en el siguiente enlace.