Slashdot Mirror


Google Proposes Changes To Chromium Browser That Will Break Content-Blocking Extensions, Including Various Ad Blockers

"Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including various ad blockers," reports The Register. "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." From the report: 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. 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.

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 report notes that Adblock Plus "should still be available" since "Google and other internet advertising networks apparently pay Adblock Plus to whitelist their online adverts."

15 of 334 comments (clear)

  1. Calling the DOJ... by Etcetera · · Score: 4, Insightful

    If the DOJ (no particular friend of Big Tech in this Administration) wanted an excuse to probe Google with the FTC for some anti-trust discovery, this would be a quick ticket.

    The world's dominant browser requiring that the world's dominant ad network always be displayed would be a wonderful reason to force a divestiture of one or the other (or, preferably, split everything up into components).

  2. It's almost like... a monopoly? by locater16 · · Score: 4, Insightful

    Wow, the company that makes 90% of the its profits from advertising is trying to use the open source projects it near controls, that has a near monopoly on web browsers now... to stop adblockers from existing...

    It's a coincidence surely. *Hugs Firefox*

    1. Re:It's almost like... a monopoly? by Desler · · Score: 5, Interesting

      Yeah, and plenty of people pointed that out years ago but mosr Slashdorks wouldn't listen because Google open sourced some token projects that were never money makers and they used Linux.

    2. Re:It's almost like... a monopoly? by phantomfive · · Score: 5, Insightful

      It is a moral imperative to use ad blocking. Ads incentivize the wrong kinds of content to be created: things like click-bait and fake news.

      Even if you don't think ads are immoral, you should still use ad block as a practical matter: malware can be served to you from all the major ad networks, so if you don't want to be hacked, use ad-block.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:It's almost like... a monopoly? by Solandri · · Score: 4, Interesting

      It's open source. If enough people don't like it, they'll just fork Chromium and create a new ad-block-friendly browser without this "feature.".

      Need I point out that Firefox is based on a version of Netscape that was made open source?

    4. Re: It's almost like... a monopoly? by Ormy · · Score: 4, Informative

      There are many other software choices that are actually usable. For windows I use Hostsman (does deduplication in seconds for millions of lines, not hours or days like apk's stuff). For non-rooted android I use PersonalDNSfilter which is available on f-droid (again, processes files with many millions of entries in seconds). There are many other alternatives

  3. Re:In the future ... by Anonymous Coward · · Score: 5, Insightful

    Increasing browser speed by forcing you to download slow loading video ads

  4. Re:So it's back to using Proxomitron and Privoxy, by mattb47 · · Score: 4, Informative

    Run Pi-Hole instead and point your DNS to your Pi-Hole system?

    https://pi-hole.net/

    Pi-Hole doesn't have to run on a Raspberry Pi. Run a small VM, another Linux box, etc.

    I have a home server running a Ubuntu VM alongside a bunch of Windows systems, so Pi-Hole would work for me.

    Still, way more overhead and complexity than uBlock Origin.

  5. Re:Boo hoo. They need to update their extension by bytestorm · · Score: 4, Informative
    developers.chrome.com declarativeNetRequest

    The declarativeNetRequest API only allows extensions to block or redirect requests. The webRequest api is more flexible as compared to the declarativeNetRequest API because it allows extensions to evaluate a request programmatically.

    Seems to say all that needs to be said.

  6. WebExtensions in Firefox by DrYak · · Score: 5, Interesting

    You might have missed the bits where Mozilla took time to collaborate with extension authors (such as NoScript) in order to add extra functionality, so that critical things which were possible in XUL extensions could be ported to FireFox' flavour of Web Extension.

    The only extensions that didn't make the jump were either abandoned, or those whose authors preferred to loudly complain and join sone "anti-WebExtensions resistance" instead of trying to work out a solution.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:WebExtensions in Firefox by Artem+S.+Tashkinov · · Score: 4, Informative

      The only extensions that didn't make the jump were either abandoned, or those whose authors preferred to loudly complain and join sone "anti-WebExtensions resistance" instead of trying to work out a solution.

      ORLY?? Mozilla really "collaborated" (more like decided to make concessions) with only the most popular add-ons to save their face and they couldn't care less about less popular add-ons like DownThemAll, Hide Caption Titlebar Plus, Status-4-Evar, UnMHT, Tab Mix Plus and hundreds of others which integrate(d) deeply with the browser.

    2. Re:WebExtensions in Firefox by Luckyo · · Score: 4, Informative

      You might have missed the way that collaboration ended. Noscript on modern firefox is much closer to chromium version than original FF version, because capabilities needed by noscript of all were intentionally removed by FF team. Which was their part of the "collaboration" in question, to provide nice PR while destroying the add on in question, alongside many others that bothered them, such as classicthemerestorer.

      Because there is no "solution" to webextensions problem. They are intentionally crippled compared to XUL. That's the entire point of having them. And as noscript debacle proved, there is no "working out a solution", because the capability needed for functionality is simply not available in webextensions.

  7. Re: Use the source, Luke... by Anonymous Coward · · Score: 5, Informative

    Or you could use Firefox. Its web extensions already have more features than chrome, added for the express purpose of facilitating addons that increase privacy. Extensions like Cookie Autodelete and noscript are totally gimped in chrome by comparison.

  8. ANYONE READ THE SPECS? by nadass · · Score: 5, Interesting

    I fully respect the disdain for all things Alphabet Soup (formerly known as Google Inc) but the specs to chrome.declarativeNetRequest appear to suggest a different extension programming model to accomplish the same thing.

    Instead of loading a separate web document (as webRequest API does) the new API allows an extension to run through its rules at the onBeforeRequest stage -- in other words, instead of intercepting a separate network request mid-stream the API provides the means to evaluate the network request BEFORE going all the way through.

    Another way to look at it is like a (network routing) proxy service. The proxy runs through client-side rules first (whereby the rules.json may have "block" and "allow" and "redirect" action types) and reacts accordingly all BEFORE dropping mid-stream packets.

    As I ponder this a bit more, it seems that an ad-blocking extension that utilizes the new declarativeNetRequest API would actually DECREASE the amount of hits an ad-server would experience since the browser would never initiate a connection to the ad-server. To this end, the specs say that iframes and images blocked by the declarativeNetRequest API would collapse at the DOM (thus killing the html content within the iframe from ever being loaded).

    Question: Did I understand the SPECS correctly? (Yes, I am ignoring the brouhaha otherwise as well as the claim that [oh no] ad blockers have a new API at their disposal...)

  9. Re:Use the source, Luke... by r1348 · · Score: 4, Insightful

    Or, you know, just use Firefox.