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."
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."
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.
Local proxies are still allowed. And likely always will be if they want the corporate market share (this is the reason tls 1.3 got blocked for a year). Add your proxy's CA to your trusted certs and it can mogrify all the pages you send its way, regardless of security or origin. Granted, you can no longer see the original certificate from the origin webserver, but block ads it will.
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.
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.
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
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.
hundreds of others which integrate(d) deeply with the browser.
If an extension is deeply integrated into the interface of the browser, you might expect that when this interface change, there'll be some work involved.
Tab Mix Plus
is in the process of being re-written (but still isn't on par with the classic on)
Hide Caption Titlebar Plus
...is a function that is now directly supported into Firefox with client-side decoration. No need for extensions.
Status-4-Evar
The interface of Quantum is based on Servo, it's not using XUL anymore, it's written in HTML/CSS. You don't control it the same way any more.
It's like complaining that MS-DOS screen savers and always on top status-bar thingy don't work on the Windows desktop.
Quantum *does* support a permenent status bar, but currently there's no interface to configure it, you need to manually patch the CSS.
It's not ideal, but there's no practical way ever to make Status-4-Evar work in Quantum.
DownThemAll
And meanwhile, the Firefox extensions used by JDownloader 2 to communicate does work with Quantum.
In both directions (intercepts download pages and allows you to add them into JDownloader 2, or conversely has JDownloader 2 able to open pages in Firefox when a user interaction is needed).
For a download manager *IN* Firefox : the necessary API extensions are still being worked on.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
Never mind, I found it. It's not in API documentation, but in a Google docs proposal for Manifest V3:
(T>t && O(n)--) == sqrt(666)