Mozilla has announced the start of testing the implementation of the third version of the Chrome manifest in Firefox, which defines the capabilities and resources available for extensions written using the WebExtensions API. To test the third version of the manifest in the beta version of Firefox 101, the setting "extensions.manifestV3.enabled" should be set to true, and the setting "xpinstall.signatures.required" should be set to false on the about:config page. The about:debugging interface can be used to install extensions. The default enabling of the third version of the manifest is scheduled for the end of the year.
Starting from version 57, Firefox fully switched to using the WebExtensions API for extension development and discontinued support for the XUL technology. The transition to WebExtensions has allowed for the unification of extension development with Chrome, Opera, Safari, and Edge, simplified the porting of extensions between different web browsers, and enabled full use of the multiprocess mode (WebExtensions can run in separate processes, isolated from other parts of the browser). To unify extension development with other browsers, Firefox offers almost complete compatibility with the second version of the Chrome manifest.
Currently, Chrome is working on transitioning to the third version of the manifest, and support for the second version will be discontinued in January 2023. Since the third version of the manifest has been criticized and will lead to the malfunctioning of many extensions for blocking unwanted content and ensuring security, Mozilla has decided to move away from the practice of ensuring full compatibility with the manifest in Firefox and to implement some changes differently.
The main complaint about the third version of the manifest is related to the transition of the webRequest API to a read-only mode, which previously allowed the integration of custom handlers with full access to network requests and the ability to modify traffic on the fly. This API is used in uBlock Origin and many other extensions for blocking unwanted content and ensuring security. Instead of the webRequest API, the third version of the manifest introduces the limited declarativeNetRequest API, which provides access to a built-in filtering engine that processes blocking rules independently and does not allow the use of custom filtering algorithms or the definition of complex overlapping rules based on conditions.
In the proposed implementation of the third version of the manifest in Firefox, a new declarative content filtering API has been added, but unlike Chrome, support for the old blocking mode of the webRequest API has not been discontinued. Among other features of the new manifest implementation in Firefox:
- The manifest defines the replacement of background pages with a Service Workers option that operates as background processes (Background Service Workers). For compatibility, this requirement will be implemented in Firefox, but a new Event Pages mechanism has also been proposed, which is more familiar to web developers, does not require a complete overhaul of add-ons, and eliminates limitations related to the use of Service Workers. Event Pages will allow existing add-ons with background pages to conform to the third version of the manifest while maintaining access to all necessary DOM functionalities. Currently, only Event Pages are supported in the test implementation of the manifest in Firefox, and support for the Service Workers-based solution is promised to be added later. This proposal has been supported by Apple, which has implemented Event Pages in Safari Technology Preview 136.
- The new granular permissions request model means that an extension cannot activate for all pages at once (the "all_urls" permission has been removed) and will work only in the context of the active tab. This means users will need to confirm the operation of the extension for each site. In Firefox, all requests for site data access will be treated as optional, and the final decision to grant access will rest with the user, who will be able to selectively decide which extension can access their data on a particular site.
- Changes to Cross-origin request handling — according to the new manifest, the same permission restrictions that apply to the main page will also apply to content script processing (for example, if the page does not have access to the geolocation API, then the extension script will also not gain this access). This change is fully implemented in Firefox.
- Promise-based API. Firefox already supports this API and will move it to the "chrome.*" namespace for the third version of the manifest.
- Prohibition of executing code loaded from external sources servers (referring to situations where an add-on loads and executes external code). Firefox already implements blocking of external code, and Mozilla developers have added additional techniques for tracking code loads proposed in the third version of the manifest. A separate policy for content access restriction (CSP, Content Security Policy) has been introduced for content processing scripts.
Source: opennet.ru
