El 21 de noviembre, el catálogo de AMO (addons.mozilla.org) comenzará a aceptar y certificar con firma digital las extensiones que usan la tercera versión del manifiesto de Chrome. Estas extensiones podrán ser probadas en las versiones nocturnas de Firefox. En las versiones estables, la inclusión del soporte para la tercera versión del manifiesto se realizará en Firefox 109, que está programado para el 17 de enero de 2023. Se mantendrá el soporte para la segunda versión del manifiesto en un futuro cercano, pero a finales de 2023, tras evaluar la dinámica de la transición de las extensiones a la tercera versión del manifiesto, se considerará la posibilidad de trasladar el soporte de la segunda versión a la categoría de obsoleto.
El manifiesto de Chrome define las capacidades y recursos disponibles para las extensiones escritas utilizando la API WebExtensions. Desde la versión 57, Firefox ha migrado completamente al uso de la API WebExtensions para el desarrollo de extensiones y ha dejado de soportar la tecnología XUL. La transición a WebExtensions permitió unificar el desarrollo de extensiones con las plataformas de Chrome, Opera, Safari y Edge, simplificando la portabilidad de extensiones entre diferentes navegadores web y permitiendo el uso completo del modo multiproceso (las extensiones WebExtensions pueden ejecutarse en procesos separados, aislados del resto del navegador). Para unificar el desarrollo de extensiones con otros navegadores, Firefox ofrece casi total compatibilidad con la segunda versión del manifiesto de Chrome.
Actualmente, se está trabajando en Chrome para la transición a la tercera versión del manifiesto, y el soporte para la segunda versión se eliminará en enero de 2024. El objetivo principal de los cambios introducidos en la nueva versión es simplificar la creación de extensiones seguras y de alto rendimiento, y dificultar la posibilidad de crear extensiones inseguras y lentas. Dado que la tercera versión del manifiesto ha sido objeto de críticas y provocará fallos en muchas extensiones dedicadas a bloquear contenido no deseado y proporcionar seguridad, Mozilla decidió alejarse de garantizar la plena compatibilidad con el manifiesto en Firefox y aplicar algunos cambios de forma diferente.
La principal insatisfacción con la tercera versión del manifiesto se relaciona con el cambio del API webRequest a un modo de solo lectura, que permitía conectar controladores propios con acceso total a las solicitudes de red y la capacidad de modificar el tráfico al vuelo. Este API se utiliza en uBlock Origin y muchas otras extensiones para bloquear contenido no deseado y garantizar la seguridad. En lugar del API webRequest, la tercera versión del manifiesto propone un API declarativeNetRequest, que tiene capacidades limitadas, proporcionando acceso a un motor integrado para filtrado que procesa reglas de bloqueo por sí mismo, sin permitir el uso de algoritmos de filtrado propios, ni la creación de reglas complejas que se superpongan entre sí según las condiciones.
Entre las características de la implementación del nuevo manifiesto en Firefox:
- Se ha añadido una nueva API de filtrado de contenido declarativa, pero a diferencia de Chrome, no se ha interrumpido el soporte para el antiguo modo de bloqueo del API webRequest.
- En el manifiesto se define la sustitución de las páginas de fondo por una variante de Service Workers, que funcionan como procesos en segundo plano (Background Service Workers). Para garantizar la compatibilidad futura, se implementará soporte para Service Workers en Firefox, pero actualmente, en su lugar, se propone un nuevo mecanismo de Event Pages, que es más familiar para los desarrolladores web, no requiere una reestructuración completa de las extensiones y elimina las limitaciones relacionadas con el uso de Service Workers. Event Pages permitirá adaptar las extensiones existentes con páginas de fondo a los requisitos de la tercera versión del manifiesto, manteniendo el acceso a todas las funcionalidades necesarias para trabajar con el DOM.
- Un nuevo modelo granular de solicitud de permisos: el complemento no podrá activarse de inmediato para todas las páginas (se ha eliminado el permiso "all_urls"), y solo funcionará en el contexto de la pestaña activa, es decir, el usuario deberá confirmar la funcionalidad del complemento para cada sitio. En Firefox, todas las solicitudes de acceso a los datos del sitio se considerarán opcionales, y la decisión final sobre la concesión de acceso será tomada por el usuario, quien podrá decidir selectivamente a qué complemento otorgar acceso a sus datos en un sitio dado.
Se ha añadido un nuevo botón «Unified Extensions» en la interfaz para gestionar los permisos, que ya se puede probar en las compilaciones nocturnas de Firefox. Este botón proporciona herramientas para gestionar directamente a qué sitios tiene acceso cada complemento; el usuario puede otorgar y revocar el acceso del complemento a cualquier sitio. La gestión de permisos se aplica solo a los complementos basados en la tercera versión del manifiesto; para los complementos de la segunda versión del manifiesto, no se realiza una gestión granular del acceso a los sitios.
- Cambio en el manejo de solicitudes Cross-origin: de acuerdo con el nuevo manifiesto, las restricciones de permisos se aplicarán a los scripts de procesamiento de contenido de la misma manera que a la página principal en la que se implementan estos scripts (por ejemplo, si la página no tiene acceso a la API de definición de ubicación, el script del complemento tampoco obtendrá ese acceso). Este cambio ya se ha implementado completamente en Firefox.
- API basado en Promesas. Firefox admite esta API y para la tercera versión del manifiesto la trasladará al espacio de nombres «chrome.*».
- Prohibición de la ejecución de código cargado desde fuentes externas servidores (se refiere a situaciones en las que un complemento carga y ejecuta código externo). En Firefox se aplica un bloqueo de código externo y los desarrolladores de Mozilla han añadido técnicas adicionales de seguimiento de descargas de código, propuestas en la tercera versión del manifiesto. Para los scripts de contenido se presenta una política separada de restricción de acceso al contenido (CSP, Política de Seguridad de Contenido).
Fuente: opennet.ru
