Google Plans to kill Chrome Adblocker API's
Earlier this year, Google got the internet riled up when it tentatively planned to remove the APIs that content blocking extensions — including ad blockers — use. The proposed replacement API wouldn't be as powerful or flexible, so both users and developers forwarded their complaints to Google. However, the company is mostly sticking to its guns.
First, let's rewind a bit. The current platform used by Chrome extensions is called Manifest V2, which was introduced in 2012. Google has been working on Manifest V3 for a while now, with both new functionality and changes to existing browser features.
The change that received the most (negative) publicity was Google's intention to replace the existing webRequest API, used by every content blocking extension, with a more limited declarativeNetRequest API. Instead of extensions doing the network filtering themselves, they would provide a filter list that Chrome itself would parse. Many developers, most notably the creator of uBlock Origin and uMatrix, spoke out against the proposed changes.
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).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.