Mozilla won't migrate all WebExtensions API restrictions from new Chrome manifest

Mozilla Company announced that despite Firefox's use of an add-on system based on the WebExtensions API, the developers do not intend to fully follow the future third edition of the manifest for Chrome add-ons. In particular, Firefox will continue to support the blocking mode of the API. WebRequest, which allows you to change the received content on the fly and is in demand in ad blockers and content filtering systems.

The main idea of ​​switching to the WebExtensions API was to unify the technology for developing add-ons for Firefox and Chrome, so in its current form, Firefox is almost 100% compatible with the current second version of the Chrome manifest. The manifest defines the list of features and resources provided by the add-ons. Due to the introduction of restrictive measures in the third version of the manifest that are negatively perceived by add-on developers, Mozilla will move away from the practice of completely following the manifest and will not port changes to Firefox that violate compatibility with add-ons.

Recall that despite on all objections, Google intends to end Chrome's blocking behavior of the webRequest API, limiting it to read-only and introducing a new declarative API for content filtering declarativeNetRequest. While the webRequest API allowed you to connect your own handlers that have full access to network requests and are able to modify traffic on the fly, the new declarativeNetRequest API provides access to a ready-made universal built-in filtering engine that independently processes blocking rules, does not allow you to use your own filtering algorithms and does not allow you to set complex rules overlapping each other depending on the conditions.

Mozilla is also considering porting support to Firefox for some other changes from Chrome Manifest Version XNUMX that break add-on compatibility:

  • The transition to running Service workers as background processes, which will require developers to change the code for some additions. Although the new method is better in terms of performance, Mozilla is considering retaining support for running background pages.
  • New granular permission request model - the add-on will not be able to be activated immediately for all pages (removed the "all_urls" permission), but will only work in the context of the active tab, i.e. the user will need to confirm the operation of the add-on for each site. Mozilla is investigating ways to enhance access control without constantly distracting the user.
  • Changing the processing of Cross-origin requests - in accordance with the new manifest, content processing scripts will be subject to the same permission restrictions as for the main page into which these scripts are embedded (for example, if the page does not have access to the location API, then the script add-ons won't get this access either). The change is planned to be implemented in Firefox.
  • Prohibition of execution of code loaded from external servers (we are talking about situations when the add-on loads and executes external code). Firefox already uses blocking of external code, and Mozilla developers are not opposed to strengthening such protection by applying additional techniques for tracking code downloads offered in the third version of the manifesto.

Source: opennet.ru

Add a comment