!!Credit
2019-01-26 04:56:43 UTC
How many ad blocks could an ad slinger block if an ad slinger could block blocks?
<https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/>
Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including ad blockers.
If the overhaul goes ahead, Adblock Plus and similar plugins that rely on basic filtering will, with some tweaks, still be able to function to some degree, unlike more ambitious extensions, such as uBlock Origin, which will be harder hit. The drafted changes will 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 behavior.
"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 to some degree. But uBlock Origin and uMatrix offer more extensive controls, without trying to placate publishers through ad whitelisting, and thus have a little more to lose.
Don't forget, Google and other internet advertising networks pay Adblock Plus to whitelist their online adverts. 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.
Hill, who said he's waiting for a response from the Google software engineer overseeing this issue, said in an email to The Register: "I understand the point of a declarativeNetRequest API, and I am not against such API. However I don't understand why the blocking ability of the webRequest API – which has existed for over seven years – would be removed (as the design document proposes). I don't see what is to be gained from doing this."
Hill observes that several other capabilities will no longer be available under the new API, including blocking media elements larger than a specified size, disable JavaScript execution by injecting Content-Security-Policy directives, and removing the outgoing Cookie headers.
And he argues that if these changes get implemented, Chromium will no longer serve users.
"Extensions act on behalf of users, they add capabilities to a 'user agent', and deprecating the blocking ability of the webRequest API will essentially 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," he said.
"With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical 'user agent' will still be a proper category to classify Chromium."
Google, however, may yet be willing to address developers' concerns. "These changes are in the design process, as mentioned in the document and the Chromium bug," a Google spokesperson told The Register via email. "Things are subject to change and we will share updates as available." ®
Updated to add
Following a huge outcry from plugin developers and netizens, Google has reiterated that the proposed changes are not set in stone, and are subject to revision. While the internet goliath wants to rein in the level of access granted to Chrome browser extensions, it is prepared to work through the messy matter with third-party coders – who will have to rewrite parts of their software if this all goes ahead.
Also, we're happy to clarify that while Adblock Plus is affected by the draft changes, it will not be whacked quite as hard as other more featureful extensions, such as uBlock Origin.
Indeed, the proposed API appears to promote ABP's simple filtering mechanism, rather than support the advanced content blocking other extensions offer. The sticking point is whether or not the proposed limit of 30,000 filter rules will be enough for the likes of Adblock Plus. ADP developers say it won't: their filter list has more than 70,000 entries.
"Adblock Plus is, of course, affected by this proposed change, because it would replace the main API that we (and almost all other content blockers) use to block requests with something a bit watered down," a spokesperson said.
"Even though we don't know the exact plans for this proposed change, should it get implemented we'll make sure ABP is available for Chrome users."
<https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/>
Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including ad blockers.
If the overhaul goes ahead, Adblock Plus and similar plugins that rely on basic filtering will, with some tweaks, still be able to function to some degree, unlike more ambitious extensions, such as uBlock Origin, which will be harder hit. The drafted changes will 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 behavior.
"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 to some degree. But uBlock Origin and uMatrix offer more extensive controls, without trying to placate publishers through ad whitelisting, and thus have a little more to lose.
Don't forget, Google and other internet advertising networks pay Adblock Plus to whitelist their online adverts. 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.
Hill, who said he's waiting for a response from the Google software engineer overseeing this issue, said in an email to The Register: "I understand the point of a declarativeNetRequest API, and I am not against such API. However I don't understand why the blocking ability of the webRequest API – which has existed for over seven years – would be removed (as the design document proposes). I don't see what is to be gained from doing this."
Hill observes that several other capabilities will no longer be available under the new API, including blocking media elements larger than a specified size, disable JavaScript execution by injecting Content-Security-Policy directives, and removing the outgoing Cookie headers.
And he argues that if these changes get implemented, Chromium will no longer serve users.
"Extensions act on behalf of users, they add capabilities to a 'user agent', and deprecating the blocking ability of the webRequest API will essentially 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," he said.
"With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical 'user agent' will still be a proper category to classify Chromium."
Google, however, may yet be willing to address developers' concerns. "These changes are in the design process, as mentioned in the document and the Chromium bug," a Google spokesperson told The Register via email. "Things are subject to change and we will share updates as available." ®
Updated to add
Following a huge outcry from plugin developers and netizens, Google has reiterated that the proposed changes are not set in stone, and are subject to revision. While the internet goliath wants to rein in the level of access granted to Chrome browser extensions, it is prepared to work through the messy matter with third-party coders – who will have to rewrite parts of their software if this all goes ahead.
Also, we're happy to clarify that while Adblock Plus is affected by the draft changes, it will not be whacked quite as hard as other more featureful extensions, such as uBlock Origin.
Indeed, the proposed API appears to promote ABP's simple filtering mechanism, rather than support the advanced content blocking other extensions offer. The sticking point is whether or not the proposed limit of 30,000 filter rules will be enough for the likes of Adblock Plus. ADP developers say it won't: their filter list has more than 70,000 entries.
"Adblock Plus is, of course, affected by this proposed change, because it would replace the main API that we (and almost all other content blockers) use to block requests with something a bit watered down," a spokesperson said.
"Even though we don't know the exact plans for this proposed change, should it get implemented we'll make sure ABP is available for Chrome users."