Off-topic: I really wish uMatrix was brought to life again. It had such a beautifully simple and efficient UI. uBO's filetring is close, but... not the same.
Big thank you to gorhill (and co.) for making the net useable!
I also want to take this opportunity to thank the faceless and relentless contributors who maintain the blocking lists. Thanks to their efforts, I don't need to know how to add manual rules or really do anything more advanced than install uBlock Origin to safely browse the web.
> I wish umatrix's UI would just be an option inside ublock origin. Press the box, UI appears. It's too great.
Yes, very much. I'd love to be able to contribute money somewhere to make this happen!
UBO seems to work ok as long as you don't need to tweak anything, but then falls apart. The uMatrix UI is so much superior, I can't ever imagine being able to live without it.
I'm also using it. It's not maintained. It might stop working with any of the next browser updates and has been like that for years. I've been told that uBO can do the same things and I started looking into it weeks ago, then got stuck. The UI of uMatrix is so much better than the one of uBO at selecting the scripts to run and block that it could become a case study in interaction design.
uBO can also do things that uMatrix can't (on Firefox at least) - like CNAME uncloaking[1]. This is where a resource is hosted/maintained on third-party servers, but is addressed using a first-party subdomain. As a completely hypothetical example, instead of loading content from homedepot.disqus.com, you load it from disqus.homedepot.com. The relationship between Home Depot and Disqus and the privacy implications are similar in both cases, but uMatrix would consider the former to be third-party content and the later to be first-party. uBO however will treat both as third-party content (when CNAME uncloaking is enabled).
Enabling this in uBO really opened my eyes to how fuzzy the distinction between first-party and third-party is. Sites can have all types of business arrangements with different privacy implications, ranging from relatively harmless (hosting), to moderate (CDN), to invasive (ad tracking). uMatrix and other blockers have used the domain name as a proxy-variable to measure whether something should be trusted or not, but it is increasing becoming a poor metric.
With CNAME uncloaking enabled, maintaining default deny, and allow only what is needed approach becomes quite a bit more work, as it ends up blocking a bunch of necessary content. But without you are allowing a fair bit of tracking you shouldn't.
After a few months of trying to use uBO like uMatrix, I found that using the curated deny-lists was a more tractable approach than maintaining my own allow-list, and thus don't miss the uMatrix interface as much as I expected.
Just to confirm, uBO can do the same things, mostly (and I've switched to it myself), but the UI is not on the same level when trying to block css / images / scripts separately. uMatrix really is an incredible UI achievement.
Both extensions are FOSS, so anyone with enough time and skills could say extend the uBO engine with the more powerful uMatrix interface, where the latter could be accessed through an "expert" option for more granularity, then submit the result to gorhill for evaluation, so that he would have a single codebase to maintain.
Do you actually know that gorhill would be open to receiving that work, or are you just guessing?
That's an enormous amount of work (for someone totally unfamiliar with the codebase that would have to learn) to undertake on the off chance that it would be accepted.
Just guessing of course; I'm sure the amount of work involved would be significant, but I also wouldn't underestimate the power of teamwork on the Internet, especially when something so important (I''d dare to say vital these days) as a content blocker is involved.
As for the implicit "then why don't you do the work yourself?" - Heh, I wish I had both the skills and capacity to focus on a project of such complexity.
Note that the lack of adblocker in nativefier has nothing to do with the lack of libraires to do the blocking but rather technical challenges with preload scripts, etc. (Not impossible but someone needs to implement it). See here for relevant issue: https://github.com/nativefier/nativefier/issues/177
> The core filtering engines used in the uBlock Origin ("uBO") extension, and has no external dependencies.
When it says that they are no external dependencies in the first line of the README, that sounds like it's not very likely to change.
Note this: you can develop the core of something complex and widely used like uBlock Origin, without external dependencies, during your free time, for years.
(edit: to be fair, it embeds 2 libraries, Regex.Analyzer and publicsuffixlist)
There are also architecture principles (e.g. onion architecture) which make the core of applications free of dependencies because there are the essence of your business logic.
Without having read anything here with uBlock, this could be the url matching and the calculation if a block is applicable. Then you build your hosting, UI, testing, database, etc.. as layers around it which consume the exposed interfaces of the internal domain model.
This produces highly portable modules. I have for example implemented a communication protocol against a stream interface. With this architecture we bound it later in 3 applications (Service, Cordova App, Windows App) to up to 3 different IO methods (USB, BT, TCP/IP) in even 3 programming languages (C++, .NET and JavaScript) doing communication with the same device. And 3-4 years ago, we even played with WebAssembly ... but that was not yet ready.
Well I'm sorry to be a broken record, but I think the best answer is to switch to a browser (and/or browser engine) that isn't trying to kill content blocking & user choice for profit.
But we do not, and we need to work with what we have.
I do use Firefox for all my personal browsing, but on my work machine I am more or less required to use Chrome.
And it's not even a Manifest v2/v3 issue for me, but our corporate security policies include a whitelist of allowed extensions, and ad blockers are not on the list.
Don't get me started on how dumb that is from a security standpoint, given the crap that can sometimes come in via ad networks, but it is what it is.
Manifest v3 doesn't kill content blocking. It's the chrome web store that doesn't want to accept extensions that have broad permissions like being able to read and modify data from any site from install.
But with a big privacy risk if anyone ever gets their hands on the root CA (which I hope is generated fresh in every install).
Also, Android blocks user-installed CAs by default now, apps have to opt in to accept user-added ones. That makes it pretty useless. Not sure how iOS deals with this.
Blocking ads on mobile has been a non-supportes use-case for a while.
If you really want to get rid of ads on android, rooting enables you to patch system SSL routines to disable certificate pinning and more. IOS is an apple product.
MITM for HTTPS means you'll need to set up each machine with an additional cert. And for this project, you need to configure each machine to funnel through the proxy anyways.
Personally, I use NextDNS which allows you to block categories, IPs, and use blocklists.
It's set up on the network level, and I have two separate NextDNS "networks" configured. One for the entire network, one for "privileged" users/devices.
Now, if you, personally, wanted to install it I believe there's a locally signed cert issued by Xcode that only your machine trusts, but as far as distributing uBO in the Mac App store, that's actual money (and who knows, maybe even disallowed by Apple's policies)
Big thank you to gorhill (and co.) for making the net useable!