Raymond Hill, the creator of the ad-blocking system uBlock Origin, has released an experimental browser extension called uBO Minus, which implements a variant of uBlock Origin translated to the declarativeNetRequest API, as prescribed in the third version of the Chrome manifest. Unlike the classic uBlock Origin, the new extension utilizes the capabilities of the built-in browser engine for content filtering and does not require permissions to intercept and modify all site data upon installation.
The extension currently lacks a popup panel and settings pages, and its functionality is limited to blocking network requests. For operation without extended permissions, features such as cosmetic filters for replacing content on the page (‘##’), script injection into sites (‘##+js’), request redirection filters (‘redirect=’), CSP (Content Security Policy) header filters, and filters for removing query parameters (‘removeparam=’) are disabled. Otherwise, the default list of filters fully corresponds to the set from uBlock Origin and includes about 22,000 rules.
Additionally, a few days ago, an experimental version of the AdGuard ad-blocking extension—AdGuardMV3—was also introduced, which has been translated to the declarativeNetRequest API and is capable of operating in browsers that only support the third revision of the Chrome manifest. The prototype offered for testing provides all the necessary functionality for ordinary users to block ads, but it lags behind the extension for the second revision of the manifest in its extended capabilities, which may be of interest to advanced users.
In the new AdGuard, banner hiding, social media widget blocking, and intrusive elements will continue to operate, along with ad blocking on video platforms like YouTube and proactive blocking of tracking-related requests. Among the limitations is the flickering of ad inserts due to the delay in applying cosmetic rules for 1.5-2 seconds, loss of some features related to Cookie filtering, using regular expressions, and filtering query parameters (the new API provides simplified regular expressions), and the availability of statistics and logs for filter triggers only in Developer Mode.
There is also a mention of a possible reduction in the number of rules due to limitations introduced in the third version of the manifest. If only one extension that uses declarativeNetRequest is installed in the browser, there are no issues with static rules, as a common limit applies to all extensions, allowing for 330,000 rules. When multiple extensions are present, a limit of 30,000 rules is applicable, which may not be sufficient. A limit of 5,000 rules has been set for dynamic rules, and 1,000 rules for regular expressions.
Starting in January 2023, Chrome plans to discontinue support for the second version of the manifest, making the third version mandatory for all extensions. Initially, the third version of the manifest faced criticism for disrupting the functionality of many extensions designed to block unwanted content and ensure security. The Chrome manifest defines the capabilities and resources that extensions are granted. The third version of the manifest was developed as part of an initiative to enhance the security, privacy, and performance of extensions. The main goal of the changes made is to simplify the creation of safe and high-performance extensions while making it more difficult to create unsafe and slow extensions.
The main dissatisfaction with the third version of the manifest is related to the transition to a read-only mode for the webRequest API, which allowed the integration of custom handlers with full access to network requests and the ability to modify traffic on the fly. This API is used in uBlock Origin, AdGuard, and many other extensions for blocking unwanted content and ensuring security. Instead of the webRequest API, the third version of the manifest proposes a limited-feature API called declarativeNetRequest, which provides access to an internal filtering engine that processes blocking rules independently and does not allow the use of custom filtering algorithms or the creation of complex conditional overlapping rules.
Over three years of discussions about the upcoming third version of the manifest, Google has taken into account many community requests and enhanced the initially provided declarativeNetRequest API with features demanded by existing extensions. For example, Google added support for multiple static rule sets, regular expression filtering, modification of HTTP headers, dynamic rule changes and additions, removal and replacement of request parameters, tab-based filtering, and creating session-specific rule sets to the declarativeNetRequest API.
Source: opennet.ru
