Mozilla has released a plan to implement the third version of the Chrome manifest in Firefox, which defines the capabilities and resources available to extensions. The third version of the manifest has faced criticism for disrupting the functionality of many extensions designed for blocking unwanted content and ensuring security.
Firefox plans to implement nearly all features and limitations of the new manifest, including the declarative API for content filtering (declarativeNetRequest). However, unlike Chrome, Firefox will not discontinue support for the old blocking mode of the webRequest API, at least until the new API fully meets the needs of extension developers using webRequest. This approach will ensure compatibility with Chrome extensions without breaking compatibility with extensions reliant on the webRequest API.
It is important to note that the main dissatisfaction with the new manifest is related to the transition of the webRequest API to a read-only mode, which previously allowed developers to attach their own 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, a limited declarativeNetRequest API will be offered, which provides access to a built-in filtering engine that processes blocking rules independently, does not allow the use of custom filtering algorithms, and does not permit the creation of complex overlapping rules depending on conditions.
Firefox is planning to provide support for the third version of the Chrome manifest for testing at the end of 2021, with the implementation of the new manifest scheduled for early 2022. Key features of the new manifest implementation in Firefox include:
- The provision of the declarativeNetRequest API, while retaining the ability to use the old webRequest API.
- Changes to Cross-origin request handling — according to the new manifest, the same permission restrictions that apply to the main page where these scripts are injected will also apply to the content processing scripts (for example, if the page does not have access to the geolocation API, then the add-on script will not have that access either). Part of the changes related to Cross-origin request restrictions is already available for testing in Firefox nightly builds (developed as part of the Fission project, which can be enabled in about:preferences#experimental) and is planned for widespread implementation in the third quarter of 2021.
- Background pages will be replaced with Service workers operating as background processes. This change is not yet ready for testing.
- Promise-based API. Firefox already supports this type of API in the 'browser.*' namespace and will move it to the 'chrome.*' namespace for the third version of the manifest.
- New granular permission request model — an add-on will not be able to activate for all pages at once (the 'all_urls' permission has been removed) but will work only in the context of the active tab, meaning users will need to confirm the add-on's operation for each site. Mozilla is working on strengthening access control but intends to empower users to make their own decisions about allowing add-ons to work across different tabs.
- Prohibition of executing code loaded from external sources servers (referring to situations where an add-on loads and executes external code). Firefox already employs blocking of external code, and Mozilla developers are ready to add additional tracking techniques for code loading proposed in the third version of the manifest. A separate content access limitation policy (CSP, Content Security Policy) will be introduced for content processing scripts, and existing userScripts and contentScripts APIs will be redesigned to support Service worker-based extensions.
Source: opennet.ru
