Chrome Extension Manifest V3 (MV3) was first introduced by Google back in 2018. Since then, Google has repeatedly adjusted the deprecation schedule for Manifest V2 (MV2), opening a new wave of controversy with each announcement and update. (As of this writing, the timeline states that all Manifest V2 extensions will be removed from the Chrome web store by January 2024).

Despite Google’s claim that the MV2 to MV3 migration is to improve Chrome’s security, privacy, and overall performance, opponents have deemed the migration as user-hostile. Some Chrome users have gone as far as to declare they will switch browsers in protest. Further, many theorize that a hidden motive is to restrict the capabilities of ad blockers. After all, it’s no secret that advertising is Google’s main bread and butter. Over the years, Google has launched multiple initiatives to sustain their advertising revenue, from incorporating the Better Ads Standards, to investing in a built-in Chrome ad blocker, and introducing ad block walls to YouTube. And, while it’s true that MV3 concerns all Chrome browser extension developers, it’s also true that ad blockers are especially impacted. Read on to learn more about the technology behind MV3, why it matters for adblockers, and how adblockers are responding.

‍

What is Manifest V3 (MV3)?

‍

Chrome Manifest is an application programming interface (API) for developing Chrome extensions. These Manifest APIs are the systems governing how Chrome extensions interact with your browser. Chrome Manifest V3 is the latest version of the Chrome extension platform. Currently, most extensions employ either Manifest V2 or V3, but (as of the current timeline) all extensions must migrate to Manifest V3 by mid-2024. Like its predecessor, V3 dictates what actions extensions can take, what changes they make to your settings, and where they store code and data.

‍

What are the differences between V2 and V3?

In relation to ad blockers, the three most important changes are network request modification, remotely hosted code, and scripting API.

‍

1. Network request modification

‍

What is network request modification?

Manifest V2 used the webRequest API to modify, intercept, and block requests. This is known as “network request modification”. V3 replaced the webRequest API with the declarativeNetRequest API, which requires declarative “rules” for network request modification. While webRequest API had no usage limitations, the declarativeNetRequest API is limited to 30,000 rules. In other words, all Chrome extensions in MV3 can only modify/intercept/block 30,000 requests.

‍

How does this impact ad blockers?

Ad blockers use filters to block ads, and filters require network request modification. With MV3, because extensions are limited to 30,000 rules, adblockers are limited to 30,000 filters. At least 300,000 network block requests - ten times the limitation - are required for ad blockers to function effectively, meaning they'll be much less effective in V3. Furthermore, the “rule” system seriously hinders ad blockers’ network filtering functionality, making it difficult to develop advanced rules capable of blocking traditional adblock circumvention.

‍

2. Remotely hosted code

‍

What is remotely hosted code?

In V2, extensions could load remote code, including remote logic and remote filters. Due to a “key security improvement”, extensions in V3 cannot load remote code, logic, and/or filters. All logic must be included from the get-go in the extension package.

‍

How does this impact ad blockers?

Publishers like Facebook constantly update their ad circumvention methods to bypass ad blockers. With V2, ad blockers relied on remote filters to maintain pace with the latest circumvention methods. Without remote filters, developers must update the extension package whenever a new filter is required. As a result, ad blockers’ ability to swiftly circumvent ad block circumvention has been rendered obsolete.

‍

3. Scripting API

‍

What is scripting API?

Scripts could be executed freely in V2 with the Tabs API. In V3, the new Scripting API limits an extension’s executions to script files and functions. Essentially, dynamic script executions are no longer possible in V3.

‍

How does this impact ad blockers?

Similar to the issue with remotely hosted code, the dynamic execution of scripts is necessary for ad blockers to consistently block dynamic ads and ad block circumvention.

‍

The ad blockers (kind of) strike back

Despite many delays, the transition from MV2 to MV3 is well underway. Accordingly, ad blockers have already planned workarounds for the updates and restrictions. To tackle the rule limit, AdBlock is shifting from a “one-size-fits-all” to a customized adblock experience. Instead of automatically running all filters (which would exceed the limit), users can prioritize and choose filters based on categories like country and language. With the loss of remote filter updates, blockers have resorted to frequently releasing new versions of the extension. And, across the board, ad blockers are investing in VPN/environment-based blocking methods to combat MV3’s changes. But these workarounds are precisely that: workarounds. These changes are neither improvements nor long-term solutions.

‍

Although V2’s complete deprecation isn’t until 2024, the sustainability of adblockers’ workarounds is already in question. Constantly developing new versions of extensions is time-consuming, and the mandatory Chrome Store review process will further delay releases. MV3’s changes make it far more difficult for adblockers to bypass traditional circumvention, and it’s become virtually impossible to counter next-gen adblock recovery solutions like Ad-Shield.

‍

The war is far from over, but it appears that this latest round of Google vs. ad blockers goes to Google.

‍