Chrome ad, content blockers beg Google: Don't execute our code! Wait, no, do execute our code – just don't kill us!

Worried devs list Manifest v3 problems they need tweaked

Firing squad

Makers of ad blockers, content filters, and privacy extensions for Google's Chrome browser have drawn up a list of desired technical fixes to undo the anticipated damage from pending browser platform changes.

The proposed API changes, collectively referred to as Manifest v3, would break many ad-blockers and other Chrome extensions, in some cases irreparably if implemented as described. After an outcry from developers last month, Google last week tried to reassure extension makers that it will work with them by describing an amended plan.

In answer, Adblock Plus, Ad Remover, AdBlock, AdGuard, Ghostery, Malwarebytes and the authors of the EasyList filter data set on Wednesday published a list of the major problems they anticipate based on Google's roadmap.

"We at Adblock Plus hope that any of the upcoming changes will respect a healthy and open web ecosystem that provides the user with agency through extensions," said Job Plas, director of industry relations for Adblock Plus, in a blog post. "We are positive that such changes can be done while increasing privacy, security and performance."

User agency – the power to determine how content gets displayed in one's browser and the ability to exercise that power through unfettered browser extensions – is what's at issue here.

In January, developer Raymond Hill, who maintains a content blocking extension called uBlock Origin, posted a note to the Chromium bug tracking system arguing that the proposed Manifest v3 changes will "decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

Google has cited privacy, security, and performance to justify its decision to rework the Chrome extension API. There's some validity to security concerns: The capabilities of the webRequest API, targeted in the Manifest v3 changes, do grant developers considerable power to intercept and alter requested content. They give developers access to information that could be abused.

However, Google's answer – the defanged declarativeNetRequest API and other changes – is paternalistic. It treats users as children incapable making their own decisions about which extension developers to trust. It also looks a lot like an attempt to alter a technical mechanism that interferes with Google's ad business.

The performance rationale looks shakier still. A study published last week by Ghostery and Cliqz rebuts Google's claim that content blocking extensions hinder performance.

As for privacy, breaking privacy extensions to improve privacy sounds rather suspect.

The feedback from the extension makers about contemplated changes in Manifest v3 focuses on the revised specifications for the webRequest API, its successor declarativeNetRequest and limits to the number of rules that can be applied for filtering. It does not address other contentious issues like changes to background pages.

The API objections include:

The MAX_NUMBER_OF_RULES parameter is too low.

Google has indicated its open to having more than 30,000 filtering rules but some ad blockers user 120,000 or more. And a hard limit makes it difficult to deal with ad companies that register new domains dynamically to rout around declared blocks. The extension makers suggest a limit of 300,000.

There's no way to know which requests and ads are blocked.

The extension makers say it's important to show users which ads are blocked and why. They want a telemetry mechanism to expose this data. Telemetry, they say, is also necessary to optimize filter lists and to counter malware.

"For example, heuristics based on prevalence are an important part of MalwareBytes’ arsenal for blocking of malicious sites," the extension makers explain. "But without telemetry, those approaches and techniques cannot be used as it is impossible to get a handle on false positives and false negatives."

There's no way to update rule_resources object in the JSON manifest file at runtime.

"Releasing a whole new extension version every time the filer list needs to be updated isn’t feasible," the extension makers say. They want support for dynamic rules – created on the fly rather than declared ahead of time. This would also allow custom filters.

Granular modification of requests (query parameters, cookies, etc.) would no longer be possible.

Privacy extensions need to be able to cull sensitive data from requests before they leave the browser. The extension makers want the declarativeNetRequest API to include this capability.

Google has indicated it will consider adding some request modification capability.

Upgrading unsafe HTTP requests to HTTPS would be negatively affected.

Extensions like HTTP Everywhere appear not to be possible under the current Manifest v3 plan. The extension makers want the declarativeNetRequest API to include this capability.

The extension makers also provide a lengthy list of filtering methods to address the limited rule processing capabilities in the revised API. These include support for regular expression matching, recursive whitelisting, popup/popunder blocking, and the like.

The aggrieved devs warn that Manifest v3 not only poses problems for current extensions but threatens future innovation.

Hippie peace, image via Shutterstock

After outrage over Chrome ad-block block plan, Google backs away from crippling web advert, content filters

READ MORE

"One major area where this could be especially problematic in the ad blocking space is ad blocking circumvention (the practice of getting around the ad blocker to force annoying ads on users who have an ad blocker installed)," they explain.

"This is a space where things move very fast, and both sides are heavily investing time and effort to get ahead in this cat-and-mouse game. The proposed changes (if implemented as they exist currently) could seriously affect the ability for ad blockers to counter ad blocking circumvention."

Google has expressed some willingness to revise its plan. In his post last week, Google software engineer Devlin Cronin said the API would be adapted to support declarative rules that can be added or removed at runtime.

However, Hill in a GitHub discussion of Manifest v3 has expressed doubt that Google really wants to address developer concerns. "My view is that I don't think there is a genuine exchange going on with their requests for feedback, the decision of Google-paid developers is made regarding the removal of the blocking ability of the webRequest API," he wrote, making reference to ad blocking companies that get paid by Google to let ads through filters.

"I rather not waste my time being part of a pretend discussion, the declarativeNetRequest API was designed to enforce EasyList-like filtering."

Hill observed that none of what Google said last week changes things for his extensions, uBlock Origin and uMatrix. ®

Sponsored: Becoming a Pragmatic Security Leader




Biting the hand that feeds IT © 1998–2019