Mozilla has announced that it has started testing Firefox's implementation of the third version of the Chrome Manifesto, which defines the capabilities and resources available to add-ons written using the WebExtensions API. To test the third version of the manifest in Firefox 101 beta, on the about:config page, set the "extensions.manifestV3.enabled" parameter to true and the "xpinstall.signatures.required" parameter to false. You can use the about:debugging interface to install add-ons. The inclusion of the third version of the manifest by default is planned for the end of the year.
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 2023 of the manifest, and support for version XNUMX will end in January XNUMX. Since the third version of the manifest has been criticized and will break many add-ons for blocking inappropriate content and security, Mozilla decided to move away from the practice of 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.
Firefox's implementation of the third version of the manifest added a new declarative content filtering API, but unlike Chrome, they didn't stop supporting the old blocking behavior of the webRequest API. Other features of the implementation of the new manifest in Firefox include:
- The manifest defines the replacement of background pages with a variant of Service Workers that work as background processes (Background Service Workers). To ensure compatibility, Firefox will implement this requirement, but additionally, a new Event Pages mechanism is proposed, which is more familiar to web developers, does not require a complete rewrite 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. In the implementation of the manifest available for testing in Firefox, only Event Pages are currently supported, and support for a solution based on Service Workers is promised to be added later. The proposal was supported by Apple and implemented Event Pages in Safari Technology Preview 136.
- 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.
- 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 already 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 already 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