Horror stories about Chrome extensions secretly copying user data, injecting ads into pages, or mining cryptocurrency in the background have become all too common. In October of last year, Google laid out its plans to make extensions safer, which included future changes to APIs. As it turns out, those changes may prevent most content blockers from working.

Chrome extensions use a certain manifest version that determines what APIs they can and cannot use — similar to how Android applications target a specific Android API level. The current manifest version, v2, was introduced in 2012. Manifest v3 is currently under development, and will include several breaking changes to APIs, including one that affects content blockers.

Raymond Hill, the developer behind uBlock Origin and uMatrix, explained in the Chromium bug tracker that one of the changes in Manifest v3 would break complex content filtering:

From the description of the declarativeNetRequest API, I understand that its purpose is to merely enforce Adblock Plus ("ABP")-compatible filtering capabilities. It shares the same basic filtering syntax: double-pipe to anchor to hostname, single pipe to anchor to start or end of URL, caret as a special placeholder, and so on. The described matching algorithm is exactly that of a ABP-like filtering engine.

If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist.

Beside causing uBO and uMatrix to no longer be able to exist, it's really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).

Key portions of uBlock Origin and all of uMatrix use a different matching algorithm than that of the declarativeNetRequest API. Block/allow rules are enforced according to their *specificity*, whereas block/allow rules can override each others with no limit. This cannot be translated into a declarativeNetRequest API (assuming a 30,000 entries limit would not be a crippling limitation in itself).

In summary, one of the proposed changes in Manifest V3 is to replace the webRequest API with a new declarativeNetRequest API, which has far more limitations. While this change has obvious performance benefits (Chrome no longer has to wait for extensions to allow/block every network request), it would break countless extensions that rely on heavily modifying network requests.

Manifest V3 is still under development, so there's a chance Google could decide to drop this specific API change. If not, Firefox is a pretty great browser these days.