Read this article in 日本語.
June 17, 2024: for an update about this topic, read our latest blog.
**************************************************
Back in 2019, we were loud and clear: Ad blockers or not – your choice matters.
In 2020, Vivaldi’s Ad Blocker was built as a response to the deprecations announced in Manifest V3, with the intention that it would keep working when existing ad-blocking extensions would become inoperant. The goal is to keep it working regardless of what happens regarding the extension code.
Will the Vivaldi Ad Blocker be affected by the Manifest V3 changes?
I made some architectural choices early on that I believe should keep it functional, regardless of the Manifest V3 changes. Of course, there is always a possibility that the underlying Chromium architecture will change now or in the future, forcing us to do some extra work to keep this working.
Hopefully, a more in-depth description of the architecture and some of the facts surrounding the Manifest V3 changes should help to show why I believe that our implementation is safe for the time being.
How is Vivaldi’s Ad Blocker built?
The Vivaldi Ad Blocker available on desktop and Android and in cars is built on the same internal chromium API that is used by both the Manifest V2 version of webRequest and declarativeNetRequest.
It is also designed to allow Chromium/content embedders to interact with requests performed with the Chromium network service in general. The basic idea is that the requests from the network service get proxied through some piece of code provided by the embedder that can examine or modify the request through its different stages, pretty much like webRequest currently does.
What happens after the Manifest V3 changes?
The concern of course would be that, since webRequest is going away, this particular API would become useless and disappear with it.
This is unlikely for a few reasons:
- webRequest isn’t completely going away. Only the ability to block requests from webRequest is disappearing. So, at the very least, a mechanism to proxy requests from the network services through extensions there needs to keep existing.
- declarativeNetRequest is currently built on top of webRequest. It is conceivable that it would be rebuilt later on to handle the blocking at a deeper level. If this ever happens, it will use a new set of hooks to handle blocking that our Ad Blocker should be able to use, as well. But there doesn’t seem to be much reason for that to happen yet.
- The blocking ability of webRequest is being kept for enterprise users (at least for the time being). So, all the underlying code for webRequest including the blocking abilities will have to remain intact.
So, to the best of my reckoning, I can say that it looks very likely that the Vivaldi Ad Blocker won’t suffer any adverse effects from the Manifest V3 changes. And, if it does, there should be relatively simple ways to fix it.
Could we keep using our ad-blocking extensions in Vivaldi?
But, “Wait”, I hear you say, “Doesn’t that mean that basically, Vivaldi might be able to keep webRequest intact just by bypassing the checks for enterprise environments? Could we keep using our adblocking extensions in Vivaldi?”
This certainly sounds plausible, but it is not something that we can promise without seeing what ends up happening in the code itself. If there is an easy way to keep webRequest functioning as it did for a while longer, we’ll consider doing it.
However, it is important to note that extension ad blockers often depend on other APIs that are removed in Manifest V3 (and probably much harder to bring back), so there is no guarantee that simply keeping the blocking version of webRequest alive is going to be enough, without some work from extension maintainers.
The road ahead
The move to Manifest V3 makes it more difficult to run content blockers and privacy extensions in Chrome. While some users may not notice a difference, users who use multiple extensions or add custom filter lists may run into artificial limitations set by Google. Perhaps, wise to move away from Chrome?
As Vivaldi is built on the Chromium code, how we tackle the API change depends on how Google implements the restriction. The assurance is, whatever restrictions Google adds, in the end, we’ll look into removing them.
Our mission will always be to ensure that you have the choice.
