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."
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).
Hire a Linux system administrator, systems engineer,
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*
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."
So there will still be an API that works, if you play their game..
Increasing browser speed by forcing you to download slow loading video ads
I wonder if there is a way to still block ads based on somehow modifying your host files? Does anyone make software like that, that will let us manage our host files?
Google introduces a quasi-ad-blocker. . Shocking that they want all other ad blockers to die by breaking compatibility. Then, figure that 90% of users never seek out another blocker, and Google's ads get back through.
Your ad here. Ask me how!
What goes around, comes around? Why does this not surprise me? Perhaps it's because the W3C has had fingers in corporate pockets and pants legs for as long as it's existed, and serves the corporate presences on the Web and not the "useless eaters" who consume it? The HTML spec has long been saddled with additions that benefit that corporate control of the Web. Why should it surprise anyone that one of the biggest corporate presences wants to take further control through use of its own browser?
So the Resistance is now back to using HTTP filtering proxies like the dead Proxomitron and Privoxy to try to take back the Web from corporate control. Good luck with that. Nobody really gives a shit any more. Instead of more such independent proxies and more refinements to them to make them truly user-friendly, we got the horrifically bad idea of BROWSER EXTENSIONS... and those extension developers got pwned even by Mozilla after the trap was sprung.
This should help get Firefox user numbers back up.
"When information is power, privacy is freedom" - Jah-Wren Ryel
And the second best time is today.
Cry me a river... We don't need the DOJ doing jackshit as long as Google is still providing the full source code to Chromium. Just make a few tweaks to the source code and boom, ad blocking is back in business. Sure, the change sucks for extensions like uBlock Origin, who will likely lose users as people find new ways of ad blocking, but it's not like the bad old days of closed source Internet Explorer.
Brave Browser is based on Chromium's rendering engine and provides ad blocking built-in, no extensions necessary. It's already here and works pretty darn good.
The browser has to do it because you can direct it using an extension to block html classes, ids, maybe even tags and domains. Blocking just domains (aka hosts blocking) doesn't work in the long run if the site is coded well enough that it uses the same origin for ads and regular files, so the extra power is partially up to the browser to handle everything else.
I use Firefox with uBlock Origin, and I also use the MVPS Hosts file... both on my home and work computers.
I stopped trusting Google when they were bundling Google Desktop with new computers.
Back to Privoxy/Promoiyton? Why do you think Google spent 5 years convincing everyone HTTPS was necessary, even for static, low-risk pages?
Your ad here. Ask me how!
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.
Firefox time.
While not perfect, it seems to me that a filtering proxy would take care of a lot of ads, at least those from 3rd party ad-servers.
-- Alastair
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.
Google is making this change because filtering malicious javascript and advertizing from web pages by the "web client" (ie, the browser) is ruining their business model which is completely and entirely based on the "web client" executing malicious javascript and displaying advertizing contrary to the interest of the owner of the device on which that malicious javascript is running and on which the advertizing is being displayed, at the expense of that owner (who is paying to transport that unwanted malicious javascript and advertizing).
Therefore, Google has two choices: Make is so that people using "Chrome" based crap cannot protect themselves from malicious javascript and advertizing (99% of which is promulgated by Google) or just close up shop and go out of business.
Because they are a bunch of greedy fucks who do not actually have a product any non-sleezebag would want to actually spend money on (and therefore no actual business model other than being a shitbag), the have decided to pursue the former course rather than the latter.
Of course, it also helps that 99.999999% of the people who use their products do not give a shit anyway and are too stupid to only use products which are not inherently malicious.
In other words -- follow the money.
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.
Forking Chrome?
It's a huge project. That someone needs lots of devoted developers and resources.
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 ]
Hey look, another naive Slashdork that still thinks that motto ever had any teeth to it.
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...)
Since websites will assume if you are using firefox, you must be blocking ads. This will be a fom of drm and more websites will be going chrome only to ensure thir ads will be seen. Chrome has acheived the browser monopoly after we fought so hard to get rid of Internet Explorer.
You don't seem to grasp how much flexible Proxomitron and Privoxy are than something as simplistic as Pi-Hole. They don't just block advertising: they can REWORK PAGES to display information in a fashion that is effective for you, and NOT display page elements that distract from your goal, regardless whether those elements are advertising, site self-promotion, sidebars you don't need, and far more.
Don't you get sick of having a widescreen monitor yet so many Web pages are imprisoned by their designer in a narrow column that only benefits that designer's "vision"? Don't you ever find yourself wanting to overrule the stupid or selfish decisions that Web designers make? You could do that are more with Proxomitron, because it was designed specifically to be more generalized than just an ad-blocker. Before Proxomitron's sole author died and the software lapsed into obsolescence, I used it for all of the above, and my Web experience was dramatically improved, because it was MY OWN.
Instead of promoting Pi-Hole, you should be promoting a revived open-source community edition of Proxomitron.
Browsers have started to implement DNS-over-HTTPS and it's only a matter of time before Google enforces it in the future.