His past post[0] was reposted and generated quite a discussion on HN [1].
For further details on why uBO is conflict free, this is the README.md on github repo[2] says:
---
Free. Open source. For users by users. No donations sought.
---
0: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
The reason why I cannot do away with uBlock Origin is because its not just an Ad-blocker as its philosophy states, I need it to make websites usable by blocking elements like auto pop-up news video player, Blocking side bars to resize the websites to preferred width (When playing videos), Disable tracking and often just to load the websites faster.
[1] https://web.archive.org/web/20210924045611/https://github.co...
the ublock origin repo actually has a video linked how it works: https://youtu.be/2lisQQmWQkY?t=294
uBO covers most of uMatrix (and more).
Some of that uMatrix coverage is a hell of a lot harder/more awkward in uBO.
Basically every uMatrix user always also ran uBO too, for the more DOM/'content blocking' aspects (primarly 'cosmetic filtering' as it calls it iirc).
uMatrix lets me block all third-party, allow only first-party scripts/XHR/iframes by default, and then in two clicks (including opening the extension's popover menu) allow some specific host's scripts or whatever, while still blocking its cookies/frames/XHR/media/et al.
uMatrix is more advanced than uBO 'advanced mode', and just as easy to use; i.e. easier to use than 'dynamic filtering' or whatever people suggest that's buried in the full-page settings and not something I'm going to be doing 'on the fly' while visiting a site.
I still use uMatrix (and uBO!) and remain thankful for it - I just hope it lasts, not obsoleted by browser API changes or whatever. (nuTensor was forked to take on that burden, but itself now archived. Apparently - I read in another HN topic on this recently - because uMatrix actually did receive some maintenance update.)
However it's not equivalent, because in uMatrix you have even more fine-grained control which content a certain domain in a certain context can load (i.e. scripts, images, css and xhr requests).
with uBlock origins UI you can block by content type and then whitelist the domains which are still allowed and that feels less granular then the uMatrix configuration dialog.
But if you check the generated dynamic rules in the settings you'll see that it supports the same granular controls as uMatrix
Exactly. I use uBlock to "detoxify" websites and rid them of such nonsense elements.
I do not claim to know what motivates gorhill, but so far none of his motivations in building uBO seem to be against my own motivation to use it, so it is fine.
No, he has to be able to support himself somehow. Food costs money. Plenty of people have great motives, few have the means to execute on them.
Sure. Not plenty, but still a lot of people have the means, and few of them choose to execute. Larse Ingebrigsten was a CTO of startup that got acquired and now maintains GNU Emacs. Bram Moolenaar has had consistent job since forever (not sure what % of paid time is dedicated to Vim maintenance). Richard Stallman quit and made his first money selling Emacs tapes. Some open source devs rely on consulting work. Some (Like Drew DeVault) have actual sustainable business model that are not donations (and still give away their services when it makes sense). I do not know of gorhill, but my first guess would be that he has a stable job that pays well enough and doesn't encroach on his private life and hobbies, which I believe uBO is one of.
Oh, and to add to it, it becomes incredibly easier if you find likeminded people to join in. Linus Torvalds is able to take weeks off because GKH is more than capable to handle the work in his absence. Andreas Kling has Linus Groh as co-maintainer to review PRs even considering ginormous scope of SerenityOS. As with everything, more capable minds share the load.
On top of that, uBlock Origin is still just an engine. A large bulk of work (as admitted on uBO README.md) is done in the lists like fanboy's. They are also largely contributor driven (and sometimes donations).
> Free. Open source. For users by users. No donations sought.
We'll now need to rely on Chrome team for implementing what we need. But they do it painfully slow or not do at all.
Also, where will we get the new ideas if every browser follows that path? Take Safari for example, every little improvement that we requested [1] was inspired by what we already did in other browsers long ago.
Anyways, a working content blocker on MV3 is possible. I even think a casual user won't feel much difference. But there is a big difference under the hood and to feel the consequences we have to wait a few years.
[1]: https://bugs.webkit.org/ (search for those reported by @adguard.com). Just a very small part of what we requested was implemented, content blocking is not a priority I guess, and it won't be a priority for Chrome.
To those who argue that chrome is faster and therefore you prefer using it. You should ask yourself, what is more important to you, to see a website a few ms faster or preventing Google to to dictate how the Internet of the future works (apart from the fact that in my experience browser's are so close in performance, that I don't think anyone can consistently pick which browser their on).
But people recommended Firefox anyway for most browsing since it was a better experience on the open web. Eventually it up ended the dominance by giving a better browsing experience except when forced to use IE through bad code, which eventually forced more developers to improve the experience outside of IE.
I personally never stopped using Firefox for Chrome, since there was always some extension that just didn't work quite as well on Firefox for the longest time. I've always found it worked it well.
A popular opinion of a vocal contingent of users on this site always say that Chrome is so fast, without any benchmarks other than their personal feelings for the most part. If Google is going to be openly hostile to extensions like UBlock working as intended I really wonder if they would feel Chrome is much faster if the developers of such extensions stopped looking for work arounds in an actively hostile environment and simply let them experience the garbage that is the current state of the web. They've already shown their hand as being a terrible steward of the web by blocking extensions like AdNauseum that try to destroy all the tracking and privacy violations they've created.
I personally believe all the people who don't have their jobs tied to creating ad garbage would do another exodus. Although I'm sure a vocal minority would create noise on sites like this since their jobs are tied to making the world a worse place.
Only to people like us. The amount of tech-savvy people I see not using an ad blocker is surprising. As a user of an ad blocker, I definitely feel like I’m in a small minority in the real world.
> Without us chrome would likely not be in the position it is today and google could not dictate the terms like they do.
I kind of disagree with this. Google Chrome's current popularity stands on two things:
1. It is a great browser and it does its job very well.
2. Google in the first years was very active with its distribution. And this is not only about the link on their homepage. I remember how 10 years ago every piece of software you were trying to install was bringing Chrome alongside.
Engineers recommending Chrome to their friends and relatives shouldn't be discounted, but I tend to think that it's less important that the two other points above.
Good ad blocking is an essential part of a browser. Even Google who is actively slow boiling the frog knows they can't just hard cut it off because the users will jump ship immediately.
Why should we let Google get away with this? I feel the right move is to proactively take steps that make Chrome very obviously noncompetitive. By not providing ad blocking at all or at least making it a much inferior experience. It needs to be obvious to the users, not just to tech folks.
Consider checking for the Chrome user agent on your personal website. When you detect it, either:
1. Display a screen that encourages to use a browser that respects their privacy, such as Firefox.
2. Show a popup explaining that "for an ad-free experience, try Firefox + uBlock" and add a bunch of fake (or real) ads to a special Chrome-exclusive piece of the site.
If enough of us do this with personal websites, more and more people will stop using Chrome and start using Firefox. You don't even have to cut Chrome users off from the content -- just annoy them a little, and suggest Firefox.
After all, if Google refuses to fix bugs introduced by Google developers who don't test software in browsers other than Chrome (https://support.mozilla.org/en-US/questions/1069227), the least that the rest of us can do is fight back in some small way.
It's a nice idea, but your personal website doesn't matter. Most people go to a Google website at least a few times a day, and they already tell you to switch to Chrome for the best experience. And almost all of the top non-Google websites also have a vested interest in less adblockers, so none are going to riot over this.
Devs of adblockers should all, suddenly, stop supporting Chrome. Make it a specific date (Jan. 1st 2023?) and make it known.
The web is unusable without strong, efficient adblocking. All power users would stop using Chrome in an instant. Even if they are a minority, the move would become visible on usage charts.
Anyway, it doesn't really matter what percentage of all users, just what percentage of techie word-of-mouth types use ad blockers. And that is a very significant percentage.
Maybe your mom can't change it herself but come Thanksgiving she's going to complain about it to you and you are going to fix it so she has an ad free experience again.
(posted from Firefox on Android)
MV3 will slowly make adblocking more and more useless, like boiling the frog
at which point most people who formerly used adblockers will become accustomed to the ad-infested web again
so.... Utopic best case scenario, 30% of the users? and that's if 100% of People using AdBlocking across the entire Planet were to make a move. and those are the users that don't provide any Revenue back to the Owner, anyways. the average user is using official Chrome, with very few Plugins, maybe like Reddit Enhancement, extra Twitch Emotes, Et Cetera.
I switched back to Firefox a few years ago. Firefox has improved a lot and the overall experience is just far better.
One of the nicest small things is that I've got the full URL back in the URL bar, including http/https!
If Google says, that they value speed of their browser as the main attribute, that mindset if adopted by the fanboys. If Google says you don't need more powerful ad blocking, then that idea is adopted by the fanboys. Google says it, so it cannot be wrong. Anyone saying something different is just being jealous, that they are not as good a developer to work at Google. Google! Oh please! Tell us what to think!
This kind of thinking also proliferates into non-developer communities and people, who look at it from the financial success side of things. Google, one of the biggest tech companies evaaar! Surely they must be doing something right! This developer friend, what do they know, compared to the knowledge of Google employees?! Better listen to Google.
Google has managed to twist the minds of many, who are too open for authority arguments and developers are no exception to that.
As long as we still in some way think, that Google has our wellbeing at heart, I think things will not change. However, I support not supporting Chormium-based browsers any longer. People only learn the hard way, which is, when they have to fight through jungle of ads to use even the simplest websites. Some learn not even then.
Those comparisons never take into account the runtime costs of ads. Yay, code runs 10% faster. It runs 3x as much code and has to wait on a dozen ad servers, but yay!
I just switched to Firefox. I'm typing this on Firefox.
I used to use Ungoogled Chromium.
No doubt it would. Google essentially advertised Chrome at the very top of the search results page. No amount of personal boycotting is ever going to win against that.
Just one example of how it is not safer, that I thought I should mention, on the background of such a blanket statement as "Chrome is safer" : )
Fixed that for you.
A lot of people even conflate Google Chrome, Google Search and other Google services (understandable, as Chrome's home page is a big Google logo with a search box), so they think that they cannot use Google anymore if they install Firefox.
The stats [1] speak for themselves: only 3.3% of users use Firefox. Even Edge has more users.
I don't know how to solve that problem, since those two outcomes are at odds with one another, but wanted to raise awareness
I can't understand why we have not seen strong regulatory/antitrust action on this front considering the precedent with MS.
The real danger to having a single codebase for the whole web is spec validation. Most web standards rely on two independent implementations. For newer technologies we could technically count WebKit and Blink as separate, but Gecko was providing an entirely separate codebase that isn't a fork of anything.
Remember how WebSQL was basically put out to pasture because it was just SQLite, warts and all, shoved inside the web sandbox? That's the sort of problem we'd rather avoid. Single-implementation standards tend to pick up bugs and misbehaviors from their implementation, since everyone winds up depending on implementation bugs rather than getting them fixed to match spec.
Yes. But adding back in Manifest v2 isn't. Even MSFT claims that it's too much work for them.
https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&b...
[1]: https://github.com/w3c/webextensions/blob/main/_minutes/2022... (CTRL-F for "mv4")
[2]: https://github.com/w3c/webextensions/blob/main/_minutes/2022... (CTRL-F for "mv4")
I haven't heard of this plan. Do you have more information?
The only piece of reliable information is this: I once asked Google engineer whether they plan to support declarative cosmetic rules (that's what we do ourselves in MV3 and that's why the extension still requires wide permissions) and the answer was that they definitely do plan to do that in the future.
And then people use and rely on information like this to further ignite their cognitive biases. Seems more like promoting misinformation than anything.
The difference between that and the traffic modification API is the threat model. The third party were to compromise uBlock Origin's servers, they would have a frightening amount of power over millions of machines because uBlock Origin essentially self-modifies; it downloads new rules for what should be blocked. So that breaks the security guarantees Chrome wants to provide; they can't say that the lock icon on a website means anything if a Chrome extension is allowed to arbitrarily modify traffic back and forth as a man in the middle on the last mile and Chrome web store maintainers haven't looked at the source code it's running.
I don't think there's a similar security threat for cosmetic changes.
The only option here it seems is to switch browsers.
Stop being at the whims of the Google-controlled browser monopoly --- by filtering content before it gets there.
I'd love to be proven wrong though! Right now I run DNS-based filtering because, no, it's not perfect, but I really like having network-wide blocking.
Not being able to look at scripts is another issue, although at least for some purposes you may be able to inject scripts which change the JavaScript objects in order to disable or change some features.
Maybe some sort of "remote browser" remote desktop or browser-in-browser type thing will work.
What's different is the classical permissions. Previously you could use the webRequest permission to execute custom JS functions in response to network activity. In MV3 you must now write a declarative rule instead using the declarativeNetRequest permission. By moving from an imperitive model to a declarative one, Google now has exacting control over what ad blockers can and can't do.
Gorhill's argument is that the stated reasons for MV3 do not align with the implementation. The example he gives is that Google claims the new API is more private. However you still need <all_urls> so the extension is as un-private as its MV2 equivalent. The only difference is that now Google controls what blocking you're allowed to declare and how much of it you're allowed to do.
There's a similar community discovery where MV3 implementation is provably counter to Google's claims of performance enhancement - MV3 extensions need to rehydrate state every 5 minutes as Chrome shuts down their service worker and for highly active extensions such as ad blockers this is actually less performant than the MV2 implementation with a long-lived background.
Basically, Google is full of shit.
Not completely full of shit. Declarative rules are a good idea in the general case. Random browser extensions really should not have unrestricted access to the network requests. This is how we get malware.
It's just that uBlock Origin is so important and trusted that these limitations should not apply to it. I'd even say ad blockers should be a built in browser feature but the conflicts of interest prevent that.
They left alone other imperative-but-dangerous aspects of extensions, such as the ability for any extension to watch what you type into password or credit card fields on any website. Actually that sort of extension is even easier to write in MV3 and Google will still need JS-reviewing wizards to give a guarantee an extension isn't snooping your passwords.
I don't think there's a consistent position from Google if the claim is they want to improve security via declarative syntax. I think Google is full of shit.
The heavily depends and I would disagree here. Yes, JS execution is unpopular, but it enables you to make your app behave like you want to. Otherwise it behaves like Google wants to. Google is no scammer at least, but the end result is suboptimal.
If you could implement a declarative language as powerful as an imperative one you could solve the halting problem.
So the switch from imperative to declarative is not free to make and Google has thrown the baby out with the bathwater. They just so happen to lose money every second that baby is alive. On the one hand, the decision to implement this specific declarative language is a malicious exertion of market force. On the other hand it's a stunning display of implementation incompetence. The language can't even reimplement the most popular existing extensions.
Hah. The default is to reject changes from the community. I would not pin my hopes on Chromium accepting any adblocking community changes.
> our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data
This MV3-based AdGuard extension still requires a broad permission to "read or modify host data" on all sites[2]:
So what you have now is the same required permission to "read or modify host data" as with MV2, but with a network filtering engine capabilities gated by Google (an advertising company).We can't innovate anymore the filtering capabilities of our content blocker engines as we have been constantly doing over the years.
For a recent example, there has been discussions lately with filter list maintainers of whether uBO should support AdGuard's proposed capability of being able to support pattern-matching for `domain=` filtering option[3] (uBO supports AdGuard lists).
That sort of proposition is not possible to entertain with MV3 since only Google get to decide how the filtering engine will evolve, if at all. All content blocking issues will have to be resolved with the Google-controlled filtering engine, and left unaddressed if the solution can't be shoehorned in the declarativeNetRequest API.
* * *
[1] https://blog.chromium.org/2020/12/manifest-v3-now-available-...
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[3] https://github.com/AdguardTeam/CoreLibs/issues/1550
* * *
Edit: removed stray `[` character.