The developers of the Vivaldi browser, which comes with a built-in ad and tracker blocker, assured that ad blocking will continue to work even after the final entry into force of Google Manifest V3, which defines the possibilities and limitations for extensions.
Let me remind you that we also wrote that Opera, Brave and Vivaldi will not impose advertising on users after Chromium update.So far, Manifest V3 is extremely far from ideal, but very soon it will finally come into force. Developers have to reckon with this circumstance.
For example, the developers of the AdGuard ad blocker recently talked in detail about what the transition to Manifest V3 is fraught with at present, and what problems they had to face while creating a new version of the blocker. In short: there are not enough limits on filtering rules, the syntax of declarative rules is very limited, users cannot view filtering logs, and innovations cause performance problems.
Now the topic of the imminent “release” of Manifest V3 has also been touched upon by the developers of the Vivaldi browser, who have devoted a large post on the company’s blog to this problem.
Back in 2019, the Vivaldi team assured that they would give users a choice anyway. Back then, the developers wrote that there were many possible scenarios for reacting to the third version of the Google manifest, including even restoring API functionality, which the Vivaldi team had to do before.
According to the company now, the Vivaldi team intends to keep their word made a few years ago and keep their ad blocker, which was originally created as a response to the upcoming Manifest V3, working.
The engineers explain that even in the early stages of development, they made a number of “architectural decisions” in the blocker code that should support its functionality, regardless of the changes in Manifest V3. So, the Vivali blocker relies on both the webRequest from Manifest V2 and the new declarativeNetRequest, which has already been broken so many mines.
In general, developers are confident that with the departure of webRequest, this particular API will not become useless and will not disappear with it. There are several reasons for this, they say:
- webRequest doesn’t disappear completely. Only the ability to block requests disappears. So, at a minimum, there should be a mechanism for proxying requests from network services through extensions.
- declarativeNetRequest is currently built on top of webRequest. It is possible that it will be rebuilt later to handle blocking at a deeper level. If it ever does, it will use a new set of block handling hooks that the Vivaldi blocker should also use. But there doesn’t seem to be any reason for that yet.
- The ability to block webRequest remains for enterprise users (at least for now). Thus, all of the underlying code for the webRequest, including its blocking capabilities, must remain intact.
All this leads to a natural question, will it be possible to use other ad blockers in Vivaldi, especially given the mentioned nuance about corporate environments? The developers write that they cannot guarantee anything, but they promise that if there is at least some way to extend the performance of the webRequest, they will definitely consider it and try to apply it.
At the end of their message, the browser developers summarize:
User Review
( votes)
