Google has scheduled June 3 as the start of the process to end support for the second version of the Chrome manifest, which defines the capabilities and resources available for extensions developed using the WebExtensions API. Initially, support for the second version of the manifest was planned to be discontinued in January 2023, but the deadlines were pushed back several times. Starting June 3, in the Chrome Beta, Dev, and Canary branches, notifications will begin to appear on the extensions management page (chrome://extensions) for installed extensions using the second version of the manifest, informing users about the upcoming end of support for these extensions. The second version of the manifest will also lose its
subsequently, a gradual process will begin to disable extensions using the second version of the manifest, and users will be prompted to install available alternatives from the Chrome Web Store that have transitioned to the third version of the manifest. For some time, users will be given the ability to revert disabled extensions; however, this functionality will be removed over time. The changes related to the discontinuation of support for the second version of the manifest will initially be applied to the test branches of Chrome (Beta, Dev, and Canary), but in the following months, they will also affect stable releases. The transition away from the second version of the manifest is planned to be completed by the beginning of next year. Corporate users will be allowed to postpone the discontinuation of support for the second version of the manifest until June 2025.
It is noted that Google resolved all major issues last year that hindered the transition to the third version of the manifest and took into account user feedback regarding its functionality; for instance, in the declarativeNetRequest API, the limit for static rules has been increased to 330,000 and for dynamic rules to 30,000. Currently, around 85% of extensions in the Chrome Web Store support the third version of the manifest, including the most popular content filtering extensions — AdBlock, Adblock Plus, uBlock Origin, and AdGuard.
The third version of the Chrome manifest has been developed as part of an initiative to simplify the creation of safe and high-performance extensions, while complicating the ability to create unsafe and slow extensions. The main dissatisfaction with the third version of the manifest stems from the transition of the webRequest API to read-only mode, which allowed for the integration of custom handlers with full access to network requests and the ability to modify traffic on the fly. Instead of the webRequest API, the third version of the manifest introduces a limited-feature declarativeNetRequest API, which provides access to a built-in filtering engine that autonomously processes blocking rules and does not permit the use of custom filtering algorithms.
The new manifest also transitions to executing Service Workers in the form of background processes, and utilizes a granular permission request model (the extension cannot activate across all pages at once but will only operate in the context of the active tab). The handling of Cross-origin requests has been modified — the same permission restrictions that apply to the main page into which these scripts are injected also apply to content processing scripts (for example, if a page does not have access to the location API, then the extension script will not gain that access either). The execution of code loaded from external sources is prohibited. servers (when the extension loads and executes external code).
Source: opennet.ru
