On November 21, the AMO directory (addons.mozilla.org) will begin accepting and digitally signing add-ons that use the third version of the Chrome manifest. These add-ons can be tested in nightly builds of Firefox. In stable releases, support for the third version of the manifest will be enabled in Firefox 109, scheduled for January 17, 2023. Support for the second version of the manifest will be maintained for the foreseeable future, but at the end of 2023, after assessing the dynamics of the transition of additions to the third version of the manifest, the possibility of deprecating support for the second version of the manifest will be considered.
The Chrome manifest defines the features and resources available to add-ons written using the WebExtensions API. Starting with version 57, Firefox completely switched to using the WebExtensions API for developing add-ons and stopped supporting XUL technology. The transition to WebExtensions made it possible to unify the development of add-ons with the Chrome, Opera, Safari and Edge platforms, simplified the porting of add-ons between different web browsers and made it possible to fully use the multi-process mode of operation (WebExtensions add-ons can be executed in separate processes, isolated from other parts of the browser). To unify the development of add-ons with other browsers, Firefox provides almost complete compatibility with the second version of the Chrome manifest.
Chrome is currently in the process of migrating to version 2024 of the manifest, with version XNUMX deprecated in January XNUMX. The main goal of the changes made in the new version is to make it easier to create secure and high-performance add-ons, and to make it more difficult to create insecure and slow add-ons. Since the third version of the manifest has been the subject of criticism and will break many add-ons for blocking inappropriate content and security, Mozilla decided to move away from ensuring full compatibility with the manifest in Firefox and implement some changes differently.
The main dissatisfaction with the third version of the manifest is related to the transfer to the read-only mode of the webRequest API, which allowed you to connect your own handlers that have full access to network requests and are able to modify traffic on the fly. This API is used in uBlock Origin and many other add-ons to block inappropriate content and ensure security. Instead of the webRequest API, the third version of the manifest offers a limited declarativeNetRequest API that provides access to a built-in filtering engine that processes blocking rules on its own, does not allow the use of its own filtering algorithms, and does not allow setting complex rules that overlap each other depending on conditions.
Among the features of the implementation of the new manifest in Firefox:
- A new declarative content filtering API has been added, but unlike Chrome, support for the old blocking behavior of the webRequest API has not been dropped.
- The manifest defines the replacement of background pages with a variant of Service Workers that work as background processes (Background Service Workers). For future compatibility, Firefox will support Service Workers, but now they are replaced by a new Event Pages mechanism that is more familiar to web developers, does not require a complete overhaul of add-ons, and eliminates the limitations associated with the use of Service Workers. Event Pages will bring existing background page add-ons up to the requirements of the third version of the manifest, while maintaining access to all the features necessary to work with the DOM.
- New granular permission request model - the add-on will not be able to be activated immediately for all pages (removed the "all_urls" permission), but will only work in the context of the active tab, i.e. the user will need to confirm the operation of the add-on for each site. In Firefox, all requests to access site data will be treated as optional, and the final decision on granting access will be made by the user, who will be able to selectively decide which add-on to grant access to his data on a particular site.
To manage permissions, a new "Unified Extensions" button has been added to the interface, which can already be tested in nightly builds of Firefox. The button provides the means to directly control which sites each add-on has access to - the user can grant and revoke the add-on's access to any site. Permissions control applies only to add-ons based on the third version of the manifest, for add-ons based on the second version of the manifest, granular access control to sites is not performed.
- Changing the processing of Cross-origin requests - in accordance with the new manifest, content processing scripts will be subject to the same permission restrictions as for the main page into which these scripts are embedded (for example, if the page does not have access to the location API, then the script add-ons won't get this access either). This change is fully implemented in Firefox.
- API based on Promise. Firefox supports this API and for version XNUMX of the manifest will move it to the "chrome.*" namespace.
- Prohibition of execution of code loaded from external servers (we are talking about situations when the add-on loads and executes external code). Firefox uses blocking of external code, and Mozilla developers have added additional code download tracking techniques offered in the third version of the manifest. For content processing scripts, a separate content access restriction policy (CSP, Content Security Policy) is provided.
Source: opennet.ru