Acknowledgments: This article was made possible by contributions and collaboration from the entire engineering team at eyeo. Thank you for the long coffee-fueled working days filled with countless tickets, memes and innovative problem-solving, without which we could not have achieved this monumental milestone.
AdBlock and Adblock Plus, among some of the most popular ad blockers on the market, are both powered by eyeo’s ad-filtering technology. These consumer-facing products help us transform the internet into a trusted, sustainable and accessible place where users have control over their experience, publishers are rewarded for their content and advertisers can connect with users on mutually agreeable terms.
Our extensions block disruptive ads, using a filter list to allow only lighter, nonintrusive ads that meet the Acceptable Ads Standard. In this way, advertisers can effectively reach this audience and publishers can monetize while respecting the user experience. Our engineers met each challenge head-on, thoroughly testing each feature, so we could become one of the first web extensions to adopt Manifest V3 and our users can continue to use their favorite extensions regardless of the browser they choose.
A few years ago, when Google Chrome unveiled plans for Manifest V3 (MV3), the new Chrome extensions API, it was met with a considerable amount of criticism from the developer community due to potential consequences for extensions, especially ad blockers. The initial proposed changes raised several concerns and the million-dollar question: will ad blockers even be able to work the same?
Keeping our ad-filtering technology up-to-date is paramount to our user base for their experience and privacy, and our numerous partners who rely on it for a fair value exchange. As soon as MV3 was announced our team of dedicated engineers got to work to ensure our tech would stay best-in-class.
The goal was that once MV3 was finally implemented, our users and partners wouldn’t even notice the difference. But in the background, our teams put in years of hard work, overcoming various challenges to accomplish this monumental feat.
Initially, MV3’s fundamental changes to how ad blocking works could potentially disadvantage end users. Our engineering team accepted the challenge and proposed a timeline that required transition well before June 2023 (the original release date). However, following backlash from the community of web extension developers highlighting numerous issues with the new platform, the timeline was postponed, affecting our plans as well.
By November 2023 the team resumed the transition to MV3 after addressing some issues with the new API. We needed to be ready and switch to Manifest V3 well before June 2024.
Let’s take a look at three of the most significant changes Manifest V3 introduced.
Manifest V3 introduced an important change that phased out background pages in favor of service workers. For the most part, this is fine – most of the things our extensions needed to do in a background page could be done by the new service worker. However, there is one major difference: service workers are event-driven and may be suspended by the browser at any time the browser decides they are not in use.
Random service worker suspension posed several new challenges, including obstacles with data persistence, lack of an API in the browser to suspend it easily, and testing all features to ensure functionality even if interrupted. But our engineers developed innovative ways to overcome each obstacle.
(If you’re interested in a deep dive into those methods, check out the guest blog written by some of our engineering team for Google’s Developer Blog.)
Another major Manifest V3 departure from V2 is network request modification. Previously handled by the webRequest API, extensions now need to use the declarativeNetRequest API to block requests.
The webRequest API used in Manifest V2 (MV2) lets extensions modify (and in our case, block) network requests. In V2, Chrome effectively sends network request information to the extension. This allows the extension to inform Chrome what to do with the request. As the browser sends the request in its entirety to the extension and then has to wait for its response, Google believes this has a detrimental effect on performance.
Manifest V3 provides a different system called declarativeNetRequest API to achieve the same objective but it operates on very different principles. Rather than allowing the extension to make ad-hoc decisions, the extension is required to provide Chrome with DNR rules in advance. Chrome is then in control of enforcing the rules, and extensions no longer get to decide on a case-by-case basis what happens to a request.
There are two types of DNR rules: static rules (bundled with the extension during the build process via JSON ruleset files) and dynamic rules (which the extension can dynamically include or exclude at runtime). For rulesets (the equivalent of a filter list in MV2), as well as static and dynamic rules, Chrome enforces certain limits in Manifest V3.
That means we have to be more cautious about how often we add or update rules. Our team invented a new filter list delivery system to still deliver dynamic updates without needing to update the entire extension or launch a new release, effectively providing our users with the same ad-filtering quality, regardless of the limitations Google has introduced.
In addition, certain types of regular-expression rules are no longer supported. We have been able to improve the support in cooperation with our partner Igalia, but it is still not the same as it was in Manifest V2. Therefore, we will continue working to further improve the regex rule support in MV3.
We believe in user choice – including the agency to choose which browser to use. As Google has begun to depreciate support for MV2 extensions, our ad-filtering extensions needed to transition seamlessly to the new framework. The fruits of our labor paid off and we are proud to be one of the first web extensions to adopt Manifest V3 so we can continue offering our users the same quality experience across all their devices and platforms.
If you are an engineer and interested in diving deeper into our approach, we would like to welcome you to our first office hour call with the engineers who worked on the Manifest V3 transition on Wednesday, the 17th of July, at 4 pm CET. Add the event directly to your calendar and see you there!