El 21 de noviembre, el directorio AMO (addons.mozilla.org) comenzará a aceptar y firmar digitalmente complementos utilizando la versión 109 del manifiesto de Chrome. Estos complementos se pueden probar en versiones nocturnas de Firefox. En las versiones estables, la compatibilidad con la versión 17 del manifiesto se habilitará en Firefox 2023, prevista para el 2023 de enero de XNUMX. El soporte para la segunda versión del manifiesto se mantendrá en el futuro previsible, pero a finales de XNUMX, después de evaluar la dinámica de transferir adiciones a la tercera versión del manifiesto, se descarta la posibilidad de dejar de ser compatible con la segunda versión del manifiesto. será considerado.
El manifiesto de Chrome define las capacidades y recursos disponibles para las extensiones escritas utilizando la API WebExtensions. A partir de la versión 57, Firefox pasó por completo a utilizar la API WebExtensions para desarrollar complementos y dejó de admitir la tecnología XUL. La transición a WebExtensions hizo posible unificar el desarrollo de complementos con las plataformas Chrome, Opera, Safari y Edge, simplificó la transferencia de complementos entre diferentes navegadores web y permitió utilizar completamente el modo multiproceso de operación (los complementos de WebExtensions se pueden ejecutar en procesos separados, aislados del resto del navegador). Para unificar el desarrollo de complementos con otros navegadores, Firefox proporciona compatibilidad casi total con la segunda versión del manifiesto de Chrome.
Chrome está trabajando actualmente para pasar a la versión 2024 del manifiesto y la compatibilidad con la versión XNUMX dejará de ser compatible en enero de XNUMX. El objetivo principal de los cambios realizados en la nueva versión es facilitar la creación de complementos seguros y de alto rendimiento, y hacer más difícil la creación de complementos lentos e inseguros. Debido a que la tercera versión del manifiesto ha sido criticada y romperá muchos bloqueos de contenido y complementos de seguridad, Mozilla ha decidido dejar de ser totalmente compatible con el manifiesto en Firefox e implementar algunos cambios de manera diferente.
El principal descontento con la tercera versión del manifiesto está relacionado con la traducción al modo de solo lectura de la API webRequest, que hizo posible conectar sus propios controladores que tienen acceso completo a las solicitudes de red y pueden modificar el tráfico sobre la marcha. Esta API se utiliza en uBlock Origin y muchos otros complementos para bloquear contenido inapropiado y brindar seguridad. En lugar de la API webRequest, la tercera versión del manifiesto ofrece una API declarativaNetRequest de capacidad limitada, que proporciona acceso a un motor de filtrado integrado que procesa de forma independiente las reglas de bloqueo, no permite el uso de sus propios algoritmos de filtrado y no permiten establecer reglas complejas que se superponen entre sí dependiendo de las condiciones.
Entre las características de implementar el nuevo manifiesto en Firefox:
- Se agregó una nueva API de filtrado de contenido declarativo, pero a diferencia de Chrome, la compatibilidad con el antiguo modo de bloqueo de la API webRequest no se ha interrumpido.
- El manifiesto define el reemplazo de páginas en segundo plano con la opción Service Workers, que se ejecuta como procesos en segundo plano (Background Service Workers). Para garantizar la compatibilidad en el futuro, Firefox admitirá Service Workers, pero actualmente están siendo reemplazados por un nuevo mecanismo de páginas de eventos, que es más familiar para los desarrolladores web, no requiere una reelaboración completa de los complementos y elimina las limitaciones asociadas con el uso de trabajadores de servicios. Las páginas de eventos permitirán que las adiciones de páginas de fondo existentes cumplan con los requisitos de la tercera versión del manifiesto, manteniendo al mismo tiempo el acceso a todas las capacidades necesarias para trabajar con el DOM.
- El nuevo modelo de solicitud de permiso granular: el complemento no podrá activarse para todas las páginas a la vez (se eliminó el permiso "all_urls"), pero solo funcionará en el contexto de la pestaña activa, es decir. el usuario deberá confirmar que el complemento funciona para cada sitio. En Firefox, todas las solicitudes para acceder a los datos del sitio se considerarán opcionales, y la decisión final sobre conceder el acceso la tomará el usuario, quien podrá decidir de forma selectiva a qué complemento otorgar acceso a sus datos en un sitio en particular.
Para administrar los permisos, se agregó un nuevo botón "Extensiones unificadas" a la interfaz, que ya se puede probar en las versiones nocturnas de Firefox. El botón proporciona un medio para controlar directamente a qué sitios tiene acceso cada complemento: el usuario puede otorgar y revocar el acceso de un 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 basados en la segunda versión del manifiesto, no se realiza un control de acceso granular a los sitios.
- Cambio en el manejo 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 permiso que para la página principal en la que están incrustados estos scripts (por ejemplo, si la página no tiene acceso al API de ubicación, los complementos del script tampoco recibirán este acceso). Este cambio está completamente implementado en Firefox.
- API basada en promesas. Firefox admite esta API y para la tercera versión del manifiesto la moverá al espacio de nombres "chrome.*".
- Prohibir la ejecución de código descargado de servidores externos (estamos hablando de situaciones en las que el complemento carga y ejecuta código externo). Firefox utiliza bloqueo de código externo y los desarrolladores de Mozilla han agregado técnicas adicionales de seguimiento de descargas de código que se ofrecen en la tercera versión del manifiesto. Para los scripts de procesamiento de contenido, se proporciona una política de restricción de acceso al contenido separada (CSP, Política de seguridad de contenido).
Fuente: opennet.ru