A few weeks ago, Google announced a new timeline for retiring Manifest V2, its old platform for building extensions. According to the updated schedule, which appears to be final, extensions built on MV2 will be deprecated starting in June 2024, first in the Dev, Canary, and Beta versions of Google’s dominant Chrome browser, and then for all Chrome users. In fact, the impending switch to MV3 will affect not only Chrome users, but also users of all Chromium-based browsers, including Opera and Edge.
Google’s announcement has sent ripples through the tech world and reignited concerns that swept through the ad-blocking community when Google first unveiled its new Manifest back in 2019. Predictions that the new specification for extensions would “sound the death knell” for ad blockers are back, though not with a vengeance. And while I would have mostly agreed with that sentiment a few years ago, a lot of water has passed under the bridge since then. In short, MV3 turned out not to be as bad as I once feared, and no, ad blockers are far from dying.
Before I explain the reasons for our cautious optimism about the new API, let’s take a closer look at how this new Manifest V3 came to be and what its main differences are from its predecessor.
Co-founder and CTO of AdGuard
What is Manifest V3 and why Google is introducing it
As I’ve mentioned above, Manifest V3 is the new Chrome specification for extensions. As such, it defines what extensions can and cannot do in the browser. When talking about ad blockers, this primarily refers to an extension’s ability to inspect and modify the content of the page, including blocking it.
MV3 has been in development since 2018 and was first introduced in Chrome in November 2019. One of the stated goals behind the new API was to improve security and privacy for users of Chrome and all Chromium-based browsers, with Google claiming that the permissions extensions enjoy under Manifest V2 are too broad and allow them to potentially misuse user data. The other was to improve performance of the extensions. I think it’s likely that enhancing privacy and performance were Chrome’s real goals in introducing MV3. In terms of privacy and security, however, I do not see how MV3 will markedly improve the situation. From my perspective, so far we’ve seen only incremental improvements in this regard, as the solution to this problem lies more in improving the extension moderation process in app stores. As for performance, I will have yet to wait until the transition to the new platform is complete to draw any definitive conclusions.
What makes MV3 so controversial
The planned phase-out of MV2 and transition to MV3 dragged on for years, as the new platform faced strong resistance from developers, who argued it was excessively limiting.
One of the biggest issues for ad blockers and major differences between MV2 and MV3 is that the latter is more restrictive than the former. In MV3, Chrome removed the blocking version of webRequest API, which was used by all ad blockers as well as by many extensions designed to protect privacy and security. The webRequestAPI was replaced with the declarativeNetRequest API. The latter is much less effective at blocking ad and tracking requests, because it gives the browser the final say on modifying requests, rather than the ad-blocking extension. In the case of the declarativeNetRequest API, the extension simply announces or “declares” a set of rules by which the browser should respond.
The bottom line is that Google is tightening control over what extensions do. On the one hand, their motivation is clear: the Chrome Web Store is riddled with scam and malware, and Google have been getting increasingly bad press about it. It’s natural that they’d want to tighten the screws and increase control over what extensions are allowed to do. For ad blockers, this means that any innovations that we used to implement ourselves will now have to go through the WebExtensions Community Group (W3C) work group and then be implemented by the browsers themselves. For now, this mechanism works. But there’s always the risk that at some point, participating in the discussions within the W3C group will no longer be a priority for Google, and that could seriously hamper innovation.
Also, some functionality is still missing in MV3 because, while Google has tried to cover all the bases, they have not been able to provide adequate alternatives for some of MV2’s use cases. For example, the ClearURls extension, which automatically removes tracking elements from URLs, will lose a significant portion of its functionality in the transition to MV3. I believe that these issues can be fixed either in the medium or long term, but for now they still exist.
What has improved our opinion on MV3
Despite its shortcomings, I don’t see MV3 as an imminent threat to ad blocking, as I used to before. What has made a big difference in how I feel about the new API is Google’s response to the concerns of the web community. Google stepped up its engagement with browser and extension developers as part of the W3C workgroup, and, what is most important, actually acted on the feedback. It put MV3 implementation on hold until all major bugs and developer concerns had been addressed. With the release of Chrome 120, which is scheduled to go stable at the end of this month, almost all major issues, including the expansion of the number of filter rulesets, will have been resolved. The other thing we find encouraging is that Google has significantly increased its investment in MV3. The team at Google working on the new platform has grown considerably. In addition to fixing old bugs and closing known gaps with MV2, Google has also implemented new functionality, such as the new sidePanel API or the new API for user scripts (one could argue that the new APIs are only part of the process of closing the gap, but this is only partially true).
It would be unfair not to mention the benefits of MV3 that have been realized over the years of development. For example, a unified cross-browser platform is a boon for both developers and users. It would make it easier for developers to create and maintain extensions that work across browsers without having to deal with different APIs, standards, or compatibility issues. While users would enjoy a wider choice of extensions without having to worry about switching browsers.
Therefore one of the primary challenges for ad blockers in adapting to MV3 is the complexity of maintaining a unified ecosystem for filter lists that all ad blockers currently utilize. Filter lists are the backbone of ad blocking, as they contain the rules that tell the extension what to block or allow. To facilitate this process, we have developed a new tool called AGLint and a plugin for Visual Studio Code.
What’s next for Chrome’s extension platform and ad blockers
All in all, the MV3 in its current form is much better than it was when it was first introduced by Chrome. It’s our belief that despite MV3’s somewhat limited functionality, ad blocking extensions based on the new API will be able to maintain much of their features, and regular users will barely notice a difference when all extensions are forced to migrate to the new API.
However, it’s important to point out that MV3 is very much still a work in progress, and not something that is set in stone. Browser developers are working alongside extension developers on it, proposing new features and implementing them. It’s my hope that the pace of our work won’t slow down, and may even increase as time goes on.
For example, a long-time dream of mine is to implement an ad blocker WITHOUT permission to access web pages. Truth be told, I believe that Chrome’s goals in introducing MV3 are broader than Google developers have let on. One of them may be to prepare the browser extension platform for integration into the mobile version of Chrome. The restrictions that the platform puts on extensions are eerily similar to the ones that mobile operating systems put on their apps. For example, extensions in Manifest V3 have to always be ready for the browser to stop their work (for example, if they are idle for some time) and have to be able to quickly start up again. This is similar to how mobile apps have to behave, because the operating system can shut them down at any time and not let them run for a long time in the background.
Historically, ad blockers have been very powerful tools that require a high level of access to do their job. What MV3 has to offer in terms of capabilities is just not enough to implement an ad blocker that would not require web page access permission, but it may become possible in the future. An important note: It is critical not to throw the baby out with the bathwater. Users must still be able to increase the extension’s access level if they need to.
Finally, I hope that the ultimate goal of MV3 is not only platform unification, but also extension support on mobile platforms. Even if Chrome is going to drag its feet on implementing this support, I believe it will be easier for other Chromium-based browsers to do so once MV3 is fully rolled out.
We’ve featured the best business VPN.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
