Future Chrome update may kill some ad-blocking extensions

[Arthur]

It seems a coincidence this has happened now that almost all browsers are Chromium-based.

 

Sources: The Register, Chromium Bug Tracker

 

Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including various ad blockers.

 

Adblock Plus will most likely not be affected, though similar third-party plugins will, for reasons we will explain. The drafted changes will also limit the capabilities available to extension developers, ostensibly for the sake of speed and safety. Chromium forms the central core of Google Chrome, and, soon, Microsoft Edge.

 

In a note posted Tuesday to the Chromium bug tracker, Raymond Hill, the developer behind uBlock Origin and uMatrix, said the changes contemplated by the Manifest v3 proposal will ruin his ad and content blocking extensions, and take control of content away from users.

 

Content blockers may be used to hide or black-hole ads, but they have broader applications. They're predicated on the notion that users, rather than anyone else, should be able to control how their browser presents and interacts with remote resources.

 

Manifest v3 refers to the specification for browser extension manifest files, which enumerate the resources and capabilities available to browser extensions. Google's stated rationale for making the proposed changes, cutting off blocking plugins, is to improve security, privacy and performance, and supposedly to enhance user control.

 

"Users should have increased control over their extensions," the design document says. "A user should be able to determine what information is available to an extension, and be able to control that privilege."

 

But one way Google would like to achieve these goals involves replacing the webRequest API with a new one, declarativeNetRequest.

 

The webRequest API allows browser extensions, like uBlock Origin, to intercept network requests, so they can be blocked, modified, or redirected. This can cause delays in web page loading because Chrome has to wait for the extension. In the future, webRequest will only be able to read network requests, not modify them.

 

The declarativeNetRequest allows Chrome (rather than the extension itself) to decide how to handle network requests, thereby removing a possible source of bottlenecks and a potentially useful mechanism for changing browser behaviour.

 

"The declarativeNetRequest API provides better privacy to users because extensions can't actually read the network requests made on the user's behalf," Google's API documentation explains.

 

Whose privacy exactly?

But "better privacy" here means privacy as defined by Google rather than privacy defined by a third-party extension developer. That's fine in scenarios where Google is more trustworthy than a third-party developer; but if Google and its ecosystem of publishers and advertisers are the problem, then users may prefer allowing a third-party to filter network requests, even to the extent such intervention interferes with webpage functionality.

 

"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 and uMatrix, can no longer exist," said Hill.

 

The proposed changes will diminish the effectiveness of content blocking and ad blocking extensions, though they won't entirely eliminate all ad blocking. The basic filtering mechanism supported by Adblock Plus should still be available. But uBlock Origin and uMatrix offer far more extensive controls, without trying to placate publishers through ad whitelisting.

 

This is a key point to note: Google and other internet advertising networks apparently pay Adblock Plus to whitelist their online adverts, hence the special love for this particular plugin – and the middle finger to everyone else. Meanwhile, Google has bunged its own basic ad blocking into its browser.

 

Several other developers commenting on the proposed change expressed dismay, with some speculating that Google is using privacy as a pretext for putting the interests of its ad business over those of browser users.

Edited January 23, 2019 by Arthur

[DavidYoung]

I can see this potentially being a problem for filtering extensions to if they use the same API. Could be a big issue for 1:1 programmes with off-site filtering. I'm going to ask Netsweeper tomorrow when I see them to see if their extension uses that API.

[Arthur]

Bad news for schools? A Chrome Enterprise subscription is $50 per device per year!

 

Google relents slightly on blocking ad-blockers – for paid-up enterprise Chrome users, everyone else not so much

 

Google Chrome users will continue to have access to the full content blocking power of the webRequest API in their browser extensions, but only if they're paying enterprise customers.

 

Everyone else will have to settle for extensions that use the neutered declarativeNetRequest API, which is being developed as part of a pending change to the way Chrome Extensions work. And chances are Chrome users will have fewer extensions to choose from because some developers won't be able to rework their extensions so they function under the new regime, or won't want to do so.

 

Thus, if you're a paying enterprise customer, you'll be able to use web ad and content-blocking plugins that use the powerful webRequest API to filter out stuff from pages. If not, you'll have to settle for a neutered declarativeNetRequest-based blocker, which will limit how much can be filtered out, which may not exist anyway because some plugin developers can't or don't want to use the new interface.

 

[...]

 

There's some good news: Various APIs will get more support for dynamic modification of web requests, request headers and URL parameters. This will make content blocking a bit less bad than the initial Manifest v3 draft suggested. But the basic problem remains: Manifest v3 will make extensions less effective at blocking unwanted content.

 

In his update, Vincent clarified that the original flavor of webRequest isn't going away for paying customers and that the API will continue to exist for the masses in amputated form.

 

"Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments)," he wrote.

 

Vincent said appropriately permissioned extensions will still be able to observe network requests using the webRequest API, which he insisted is "foundational for extensions that modify their behavior based on the patterns they observe at runtime."

 

But developer Raymond Hill, who created popular content control extension uBlock Origin, contends blocking capabilities matter more than observing. Losing the ability to block content with the webRequest API is his main concern.

 

"This breaks uBlock Origin and uMatrix, [which] are incompatible with the basic matching algorithm [Google] picked, ostensibly designed to enforce EasyList-like filter lists," he explained in an email to The Register. "A blocking webRequest API allows open-ended content blocker designs, not restricted to a specific design and limits dictated by the same company which states that content blockers are a threat to its business."

 

Google did not respond to a request for comment. The ad biz previously said its aim with Manifest v3 is "to create stronger security, privacy, and performance guarantees."

 

But Hill, in a note posted over the weekend to GitHub, observes that performance problems arise more from bloated web pages stuffed with tracking code than from extensions intercepting and processing content. And he argues that if the blocking nature of the webRequest API really represents a performance concern, Google could just adopt Firefox's approach which uses a technique called Promises to return a non-blocking/asynchronous response.

 

Hill says he believes Google's technical changes represent an attempt to deal with the revenue threat posed by ad blocking.

[Arthur]

I'm going to ask Netsweeper tomorrow when I see them to see if their extension uses that API.

It does...

 

https://crxcavator.io/report/kdbgbpcphmnekmkhbcfmbdahceffhddn

 

Impero too.

 

https://crxcavator.io/report/elogpmdjmainnnjjkhdmihlekgfnifil

Edited May 29, 2019 by Arthur

[caffrey]

I think Smoothwall were going down the extension route due to upcoming issues with TLS 1.3 and MITM etc. etc. If this thing happens I guess it leaves filtering solutions in a bad place

[Arthur]

Assuming "Chrome Enterprise" is just Google's umbrella term for managing Chrome in an enterprise environment I think schools might be okay...

 

https://support.google.com/chrome/a/answer/2941083?hl=en

 

As an IT administrator for a business or school, you can deploy enterprise features for Chrome users across a range of devices—Windows, Mac, and Linux computers, Chromebooks, and other devices that run the Chrome operating system.

 

Edit. Just found this...

 

https://support.google.com/chrome/a/answer/188447?hl=en&ref_topic=4386908

 

How is Chrome Browser for the enterprise different than the consumer Chrome Browser?

The Chrome Browser for the enterprise (sometimes referred to as Chrome Enterprise) is the same Chrome Browser used by consumers. The difference is in how the browser is deployed and managed. Downloading the Chrome Enterprise Bundle, IT administrators can install the Chrome Browser via MSI, and manage their organization’s Chrome Browsers via group policy to enforce over 200+ policies.

Edited May 30, 2019 by Arthur

[Arthur]

Opera, Brave, Vivaldi to ignore Chrome's anti-ad-blocker changes, despite shared codebase

 

Despite sharing a common Chromium codebase, browser makers like Brave, Opera, and Vivaldi don't have plans on crippling support for ad blocker extensions in their products -- as Google is currently planning on doing within Chrome.

 

The three browsers makers have confirmed to ZDNet, or in public comments, of not intending to support a change to the extensions system that Google plans to add to Chromium, the open-source browser project on which Chrome, Brave, Opera, and Vivaldi are all based on.