Google responds to Chromium Adblock-blocking concerns

In January we wrote of a growing furore due to Google’s plans to deprecate the webRequest API and replace it with a new declarativeNetRequest API which is much less powerful and which limits the number of rules developers can use to filter out ads.

At the time the developer of one of the best adbock apps, uBlock Origin, has said on bugs.chromium.org:

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.

Now a Google engineer working on Chromium has responded to concerns and has agreed to some concessions, though it is not clear if these go far enough.

Google remained determined to get rid of  the webRequest AP, saying it is a source of increasing abuse, but has agreed to improve the declarativeNetRequest API in the following manner:

• Dynamic Rule Support: We agree that this is valuable in creating sophisticated content blocking extensions, and will be adding support for declarative rules that can be added or removed at runtime to the declarativeNetRequest API.
• Increased Ruleset Size: We will raise the rule limit from the draft 30K value.  However, an upper limit is still necessary to ensure performance for users.  Block lists have tended to be “push-only”, where new rules are added but obsolete rules are rarely, if ever, removed (external research has shown that 90% of EasyList blocking rules provided no benefit in common blocking scenarios).  Having this list continue to grow unbounded is problematic.
• Additional Actions and Conditions: We plan to add support for matching based on more conditions, such as resource size, and will provide actions to modify parts of a request instead of just blocking it, such as stripping cookies.  We are also investigating other conditions and actions that may make sense to add, such as matching based on top-level domain.  (One additional note: While we are investigating adding support for CSP modifications, adding a CSP header to disable JavaScript was frequently mentioned as a use-case; this is already possible through the contentSettings API.  If this is insufficient, please let us know why.)

Google said they would continue working with developers and would not remove the webRequest API before the replacement is ready and mature, saying:

Once again, we are committed to supporting extensions in Chrome.  We will continue to work with developers. We won’t launch Manifest V3 until it is ready, and there will be a migration period in which we can continue to address feedback and issues.  We will not remove support for Manifest V2 until we are confident in the platform.

Many remain sceptical however Google’s real aim is to more tightly control the user experience to enable tracking and ad serving of their billions of users.

Do our readers think Google will use its increasing control of the world’s web rendering engines via Chromium to boost their ad business further, or is there enough browser competition to keep them honest? Let us know below.

Via The Register