In the previous article we talked about the new Javascript engine in which the people of Mozilla have been working for the next version of Firefox 70 which will be arriving next October (you can read the note in the following link). In this article we will talk about the announcement made by Mozilla about using Firefox add-ons based on the WebExtensions API in which the Mozilla developers made their position known in which They do not intend to fully follow the upcoming third edition of the Chrome Add-on Manifesto.
With this they make known that in particular, Firefox will continue to support webRequest API blocking mode, which allows you to change accepted content on the fly and is in demand in ad blockers and content filtering systems.
The main idea of the transition to the WebExtensions API was the unification of the plugin development technology for Firefox and Chrome, therefore, in its current form, Firefox is almost 100% compatible with the current second version of the Chrome manifest .
The manifest defines a list of provided features and resources for the complements. Due to the introduction of restrictive measures negatively perceived by ldevelopers of plugins in the third version of the manifest, Mozilla will abandon the practice of fully following the manifest and will not transfer changes to Firefox that violate plugin compatibility.
Remember that despite all objections, Google plans to discontinue support for Chrome in the mode that blocks the WebRequest API mode, limiting it to read-only mode only and for offering new declarative content filtering features of the declarativeNetRequest API. .
If the webRequest API allowed you to connect your own controllers with full access to network requests and capable of modifying traffic on the fly, the new declarativeNetRequest API provides access to an out-of-the-box universal built-in filtering engine that independently processes the rules of blocking, does not allow the use of its own filtering algorithms, and does not allow complex rules to overlap each other based on conditions.
Mozilla is also evaluating the convenience of porting to Firefox to support some of the other changes. from the third version of the Chrome manifest, which violate plugin support:
- La transition to the execution of service workers in the form of background processes, what it will require is that the developers change the code of some additions.
Although the new method is more optimal in terms of performance, Mozilla is considering maintaining support for running background pages. - New granular permission request model: the plugin cannot be activated immediately for all pages (the "all_urls" permission is removed), but it will only work in the context of the active tab, ie the user will have to confirm the plugin work for each site. In this segment Mozilla is exploring ways to strengthen access control without constantly distracting the user.
- Change in cross-origin application processing: According to the new manifest, the same authority restrictions will apply to content processing scripts as to the main page these scripts are inserted into (for example, if the page does not have access to the location API, then the script plugins won't get this access either). The change is planned to be implemented in Firefox.
- Prohibition of 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 happy to enforce that protection by using additional code download tracking techniques offered in the third version of the manifest.
Source: https://blog.mozilla.org