Only the ability to block requests from webRequest is disappearing. webRequest isn’t completely going away.The concern of course would be that, since webRequest is going away, this particular API would become useless and disappear with it. What happens after the Manifest V3 changes? 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. It is also designed to allow Chromium/content embedders to interact with requests performed with the Chromium network service in general. 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. 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. 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. I made some architectural choices early on that I believe should keep it functional, regardless of the Manifest V3 changes.

Will the Vivaldi Ad Blocker be affected by the Manifest V3 changes? The goal is to keep it working regardless of what happens regarding the extension code. 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. Back in 2019, we were loud and clear: Ad blockers or not – your choice matters.

Brave youtube ad blocker