Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently
How many ad blocks could an ad slinger block if an ad slinger could block blocks?
By Thomas Claburn in San Francisco 22 Jan 2019 at 22:27
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 block 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 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 extensions 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 ('uBO') 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.
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."
https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/
How many ad blocks could an ad slinger block if an ad slinger could block blocks?
By Thomas Claburn in San Francisco 22 Jan 2019 at 22:27
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 block 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 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 extensions 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 ('uBO') 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.
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."
https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/
