On November 21, the AMO catalog (addons.mozilla.org) will start accepting and verifying extensions using the third version of the Chrome manifest with a digital signature. These extensions can be tested in the nightly builds of Firefox. The stable releases will include support for the third version of the manifest in Firefox 109, scheduled for January 17, 2023. Support for the second version of the manifest will remain in the foreseeable future, but by the end of 2023, after evaluating the dynamics of the transition to the third version, the possibility of marking support for the second version as deprecated will be considered.
The Chrome manifest defines the capabilities and resources available for extensions written using the WebExtensions API. Starting from version 57, Firefox fully transitioned to using the WebExtensions API for extension development and discontinued support for XUL technology. The switch to WebExtensions allowed for the unification of extension development with Chrome, Opera, Safari, and Edge platforms, simplified the porting of extensions between different web browsers, and enabled the full use of multi-process mode (WebExtensions can run in separate processes, isolated from other parts of the browser). To unify extension development with other browsers, Firefox ensures almost complete compatibility with the second version of the Chrome manifest.
Currently, Chrome is working on the transition to the third version of the manifest, and support for the second version will end in January 2024. The main goal of the changes made in the new version is to simplify the creation of safe and high-performance extensions while complicating the possibility of creating unsafe and slow extensions. Since the third version of the manifest has faced criticism and will break many extensions for blocking unwanted content and ensuring security, Mozilla has decided to step back from full compatibility with the manifest in Firefox and 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.
Among the features of the new manifest implementation 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.
- The manifest defines a replacement for background pages with Service Workers, which operate as background processes (Background Service Workers). To ensure future compatibility, Firefox will implement support for Service Workers, but for now, a new mechanism called Event Pages is proposed, which is more familiar to web developers, requires no complete overhaul of extensions, and eliminates the limitations associated with using Service Workers. Event Pages will allow existing extensions with background pages to conform to the requirements of the third version of the manifest while maintaining access to all necessary functionalities for working with the DOM.
- 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.
A new button called 'Unified Extensions' has been added to the interface for managing permissions, which can now be tested in the nightly builds of Firefox. This button provides tools for directly managing which sites each extension has access to — users can grant and revoke access for any site. Permission management only applies to extensions based on the third version of the manifest; granular site access control is not available for extensions based on the second version.
- 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 supports this API and will move it into the 'chrome.*' namespace for the third version of the manifest.
- Prohibition of executing code loaded from external sources servers (referring to situations where an extension loads and executes external code). Firefox implements blocking of external code, and Mozilla developers have added additional techniques for tracking code loads that are proposed in the third version of the manifest. A separate content access restriction policy (CSP, Content Security Policy) has been introduced for content scripts.
Source: opennet.ru
