The Google developers who are in charge of the "Google Chrome" web browser have announced the inclusion in Chrome 88 (expected to launch on January 19, 2021) of the third edition of the manifesto, which has caused a lot of conflict among browser extension developers, due to the violation of the work of many additions to block inappropriate content and security.
Note that compatibility with plugins that use the second version from the manifesto will stay for some time. End of support for Manifest V2 has not been determined yet, but the migration period to the new manifest will last at least one year.
As a reminder, The Chrome manifest defines the capabilities and resources provided by the plugins.
The new manifesto is part of an initiative to improve safety, privacy, and plug-in performance. The main goal of the changes is to make it easier to create high-performance and safe plugins, and to make it harder to create slow and unsafe plugins.
With the introduction of Manifest V3, we will not allow remotely hosted code. This mechanism is used as an attack vector by bad actors to bypass Google's malware detection tools and represents a significant risk to user privacy and security.
The main dissatisfaction with the new manifesto is related to the end of support for the webRequest API working lock mode, which will be limited to read-only mode.
An exception will be made only for the Chrome for Enterprise edition, which will continue to be supported by the webRequest API. Mozilla has decided not to follow the new manifest and will keep Firefox fully using the webRequest API. Instead, the webRequest API for filtering content in the new manifest proposed a declarative API declarativeNetRequest.
The new declarativeNetRequest API provides access to an out-of-the-box universal built-in filtering engine that independently processes blocking rules, does not allow the use of custom filtering algorithms, and does not allow setting complex and overlapping rules depending on conditions.
As a reason for the transition to the declarativeNetRequest API, Privacy concerns are noted: With the new API, plugins will lose unlimited access to all data streams, which may include sensitive user information.
Google has tried to mitigate some of the problems expressed During discussion with plugin developers, who will be affected by the declarativeNetRequest API (for example uBlock Origin, whose author considers the declarativeNetRequest functionality insufficient for the plugin to function properly), it will stop working.
In accordance with the wishes of the plugin developers, se has added support for using declarativeNetRequest for various static rule sets, filter by regular expressions, modify HTTP headers, dynamically change and add rules, remove and replace request parameters.
The new manifest also introduces the following changes that affect plugin compatibility:
- The transition to running service workers in the form of background processes, which will require developers to change the code of some additions.
- New granular model for requesting permissions: the plugin will not be able to be activated for all pages at the same time (the "all_urls" permission has been removed), 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.
- Cross-origin request processing changes: According to the new manifest, 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, then the script plugins will not have this access either).
- Prevents the execution of code downloaded from external servers (when the plug-in loads and executes external code).
Finally if you want to know more about it of the note, you can refer to the original post In the following link.