Chromium developers recently shared the updates they are planning to do in Manifest V3, and one of them was limiting the blocking version of the webRequest API. They are introducing an alternative to this API called the declrativeNetRequest API.
After knowing about this update many ad blocker maintainers and developers felt that introduction of the declarativeNetRequest API can lead to the end of many already existing ad blockers.
One of the users at the Chromium bug tracker said:
“If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin (“uBO”) and uMatrix, can no longer exist.”
What is manifest version?
Manifest version is basically a mechanism through which certain capabilities can be restricted to a certain class of extensions. These restrictions are specified in the form of either a minimum version or a maximum version.
What Chromium states is their reason for doing this update?
The webRequest API permit extensions to intercept requests to modify, redirect, or block them. The basic flow of handling a request using this API is, Chrome receives the request, asks the extension, and then gets the result. In Manifest V3, the use of this API will be limited in its blocking form. While the non-blocking form of the API, which permit extensions to observer network requests, but not modify, redirect, or block them will not be discouraged. They have not yet listed the limitations they are going to put in the webRequest API.
Manifest V3 will treat the declarativeNetRequest API as the primary content-blocking API in extensions. What this API does is, it allows extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension. This allows Chrome to handle a request synchronously. As per the doc shared by the team, this API is more performant and provides better privacy guarantees to users.
What ad blocker developers and maintainers are saying?
After knowing about this update many developers were concerned that this change will end up crippling all ad blockers. “Beside causing uBO and uMatrix to no longer be able to exist, it’s really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone)”, commented an ad blocker developer.
He also stated that with the declarativeNetRequest API developers will not be able to implement other features like blocking of media element that are larger than a set size, disabling of JavaScript execution through the injection of CSP directives, etc.
Users also feel that this is similar to Safari content blocking APIs, which basically puts limit on the number of rules. One of the developers stated on Chromium issue tab, “Safari has introduced a similar API, which I guess inspires this. My personal experience is that extensions written in that API is usable, but far inferior to the full power of uBlock Origin. I don’t want to see this API to be the sole future.”
You can check out the issue reported on Chromium bug tracker. Also, you can join the discussion or raise your concern on the Google group: Manifest V3: Web Request Changes.
Read Next
Chromium blacklists nouveau graphics device driver for Linux and Ubuntu users
Chromium-based Brave browser shows 22% faster page load time than its Muon-based counterpart
DragonFly BSD 5.4.1 released with new system compiler in GCC 8 and more
