Mozilla recently announced that intends to make your web browser "Firefox" is compatible with version 3 of the Chrome manifest and has published a roadmap, which defines the capabilities and resources to be provided to the plugins.
We must remember that the third version of the manifesto has been criticized for interrupting many of the security plugins and blocking inappropriate content, and we have even already talked about it here on the blog.
Mozilla comments that plans to implement almost all the capabilities and limitations of the new manifest in Firefox, including the declarative content filtering API (declarativeNetRequest), but unlike Chrome, Firefox will not stop supporting the old blocking mode of the webRequest API, at least until the new API will not fully meet the needs of plugin developers that use the webRequest API.
This approach will ensure compatibility with Chrome plugins without breaking compatibility with plugins that depend on the webRequest API.
The main dissatisfaction with the new manifest is associated with the read-only translation of the webRequest API, which allowed you to connect your own controllers that have full access to network requests and can modify traffic on the fly.
This API is used by uBlock Origin and many other plugins to block inappropriate content and ensure security. Instead of the webRequest API, the declarative NetRequest API is proposed, limited in its capabilities, which provides access to a built-in filtering engine that independently processes blocking rules, does not allow the use of custom filtering algorithms, and does not allow establish complex rules that overlap depending on the conditions.
In Firefox, compatibility with the third version of the manifest from Chrome is scheduled to be tested in late 2021 And the new manifesto is scheduled for early 2022.
Among the features of the implementation from the new manifesto in Firefox stand out:
- Provide the declarativeNetRequest API, but keep the legacy webRequest API.
- Change the processing of cross-origin requests: According to the new manifest, the content processing scripts will be subject to the same permission restrictions as for the main page in which these scripts are embedded (for example, if the page does not has access to the location API, the plugins in the script will not get this access either). Some of the change requests related to cross-origin restrictions are already available for testing in Firefox nightly builds.
- The background pages will be replaced with service workers, who work in the form of background processes. (The change is not yet ready to begin testing.)
- Promise-based API: Firefox already supports this type of API in the namespace «browser. * »And for the third version of the manifest it will move it to the namespace« chrome. * ».
- New granular model for requesting permissions: the plugin will not be able to activate for all pages at once, but it will only work in the context of the active tab, that is, the user will have to confirm the work of the plugin for each site. Mozilla is working to strengthen access controls, but it is intended to give users the ability to decide whether to allow plugins to work with different tabs.
- Prohibit the execution of code downloaded from external servers (we are talking about situations where a plugin loads and executes external code). Firefox already uses external code blocking and Mozilla developers are ready to add additional code download tracking techniques offered in the third version of the manifest.
- Additionally, a separate content security policy (CSP) will be introduced for content handling scripts and existing UserScripts and contentScripts APIs will be modified to support worker-based extensions to the service.