It's a really compelling project, with webextension support I could easily see myself moving over to a scriptable browser built on something like Servo.
To get to the point where I would feel comfortable having my OS handle browser blocking, a reasonable chunk web browser functionality would need to be moved out of the browser and onto the OS. I just don't see that happening any time soon, and I'm not sure that's the direction we would want to move with browsers anyway.
Ublock Origin will do things like stub Javascript methods on the page. A Piihole can't do that. And even for simple things like blocking requests based on the current domain -- the movement towards DoH and SNI are going to make that harder and harder as time progresses. You really need an interface that has insight into not just what requests you're making, but where/why you're making them.
Not to say that system wide blockers don't have value, but they're really there for the apps that can't handle their own adblocking. They're a defense in depth for the requests that slip through other parts of your setup, but they're not a good replacement for a browser extension.
It can be used as an adblocker based on domain, request path, HTTP headers, etc, but it can do much more. It can redirect requests (for example, replacing assets from a CDN with a local cache), modify headers (stripping or making cookies temporary, changing user agent, etc.) and even rewrite the content of web pages using regular expressions or any external program.
By default, it has only a basic configuration that blocks tracking and ads, but there are tools[2] that convert adblock rules to the Privoxy format, so it will be functionally equivalent to adblock.
It acts as a CONNECT proxy, so you can run it locally or on a router and if combined with a NAT rule, it can also work transparently (obviously, you need to manually trust a CA certificate for https).
All those things are trivial to do in a browser plugin but probably a total workaround-filled pain on any other layer in the system.
The best it can offer is a CGI editor to change its configuration from the browser. I don't see how you could implement something like this: it's either interactive or a passive network element, but not both.
> Can it block content of a website without interfering with a `curl` request or a file download from a random messenger app?
This is really trivial, just don't proxy them (ie don't set the http_proxy variable).
If you mean hiding an element, yes it's possible: you can either inject CSS into the page or write a filter to remove the HTML entirely. For example, adblock2privoxy generates both Privoxy rules to block requests and stylesheets to hide elements (you need a local webserver for this, though).
> And do I have to disable DoH to make it work?
It's Privoxy, not the browser, that will do the DNS queries. So, no: it will work regardless of DoH.
1) The converter you link has 62 stars and hasn't been updated in 2 years. Additionally I'm seeing multiple issues about basic adblock rules not taking effect. Short version, I would not trust this repo to convert rules.
This is kind of exactly what I'm talking about with the difficulty of keeping pace with what is essentially a shared standard in the adblocking community. It's not enough to write one converter that gets updated every 2 years, in the space of those 2 years, Ublock Origin has expanded the syntax it supports. Adblocking is a cat-and-mouse game, there isn't a single set of features that can implemented once and then the software marked as "done".
2) Even assuming that converter does work (which I am doubtful of), Ublock Origin uses a superset of the adblock rules format, so you have to target what Ublock Origin supports, not just what adblockers in general do.
And obviously I'm not going to try and recreate those lists myself manually, I don't have the time or energy to do that. They have to be 100% consumable from upstream.
----
Okay, moving on to Privoxy itself:
1) On the community aspect again, I don't see dedicated Reddit groups devoted to finding every single broken website on this software. I don't see a public issue tracker. It seems to be following the old FOSS philosophy of developing software primarily on mailing lists someplace, which is fine for some software but not fine for something that is highly community dependent like adblocking.
You say the software is being actively developed again, I don't see any way to easily confirm that. I don't see any way to easily figure out how many people are using this and verifying that it works.
2) As far as I can tell, this doesn't support DoH. That is also kind of a dealbreaker for me, I don't want to make myself less secure in one area to make myself more secure in another. This is a solveable problem: if Privoxy was being set up as a local DoH server as well, and it was using DoH itself to query/cache results, then the issue would almost completely go away.
However, am I correct in guessing that Privoxy is also going to struggle in the future with encrypted SNI, or with the fact that my browser strips referrer headers from requests?
3) I'm looking at Privoxy's pattern documentation[0], and correct me if I'm wrong but it doesn't seem to support contextual blocking at all. In Ublock Origin I can do rules like:
$script,third-party,domain=imgbox.com
4) Privoxy seems to lack the ability to block iframes, or at most it seems to have the ability to strip them from the HTML itself. That's not enough, sometimes iframes get dynamically created after a page is loaded, and modifying the HTML is not enough to block that.
5) I don't see any way to mark sites as trusted (probably related to point #3). So there doesn't seem to be a way for me to disable Privoxy when I'm on a specific site.
6) I don't see anything in the docs about CNAME unmasking. And CNAME cloaking isn't a theoretical attack, there are websites in the wild using that technique.
7) Browser integration also seems to be lacking. This isn't the biggest problem, I can tolerate annoyance, but it's a little bit of a quality of life issue.
8) And so on. Most of UBlock Origin's dynamic filtering syntax[1] seems to be unsupported. It's very possible I'm misreading the docs, or the docs are out of date or there's a trick to make it work, but if that's the case, that's also a problem, because then the docs need to be clearer.
----
None of that is to say that Privoxy is bad software. It's just to say that it doesn't seem like it's an all-in-one replacement for what my browser does.
We often do defense-in-depth in this area. You can set up a Piihole, or a firewall, or a proxy server to handle adblocking for devices and applications that don't expose interfaces like the browser does. That's a good idea. But the farther away from the context of the application that you get, the harder it is to do really detailed blocking based on that context.
This is something fundamental about adblocking that people don't always seem to understand -- it's not an either/or proposition, it's not like you set up a proxy server and all of your browser configs become useless. The proxy server just adds another layer of defense.
[0]: https://www.privoxy.org/user-manual/actions-file.html#AF-PAT...
[1]: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax
Also uBlock Origin lets you block any HTML element on any site. This lets you (interactively!) cut out autoplaying videos, annoying popups and basically anything that you as an individual user find distracting.
Or how about the option to block loading of large images? Try implementing that system wide without accidentally breaking certain requests using `curl` and while still allowing the user to flip that switch in seconds.
There's no single abstraction layer where it makes sense to do everything at once.
Get everyone to add a cname or rotate the domains.
If they use the main domain and proxy the requests, you can’t block the domain without breaking the site.
That’s why there are lists that operate on selectors and the content on the pages too.
Gemini is a project that actually attacks the root of the problem by presenting an extremely stripped-down hypertext format and giving an alternative at the protocol level.
i highly recommend checking out Gemini https://gemini.circumlunar.space/docs/faq.gmi and the Lagrange Browser https://github.com/skyjake/lagrange if you find this interesting.
at least for my circle, there's a consensus that the web has calcified and become such a walled garden that we've reached a time where it makes sense to "start over" at a pretty base level; rather than trying to build on top of a platform that, by its nature, inevitably tends towards centralization and capitalization.
There's nothing "fundamental" about web bloat.
Here's a simple litmus test for Gemini: take a look at a few of the personal websites for people who've spoken highly of Gemini. How many of them have exercised restraint and eschewed with all the sorts of things that Gemini disallows? How many of them have embraced features of the Web that are not permitted in Gemini?
> rather than trying to build on top of a platform that, by its nature, inevitably tends towards centralization and capitalization
If we take it for granted that it's true of the Web (and that's being generous), why is Gemini going to fare better?
These all seem like a bunch of vague and empty talking points for a piece of tech who's main catalyst for coming into interest and capturing attention comes down to NIH, and not actually any fundamental correctness about its nature.
I assume a lot of the potential "early adopters" for any new browser are privacy/security focused and as neat as it is conceptually that's going to be a steep climb for any new project.
It's also doing CNAME uncloaking, request rewriting, stubbing functions in pages, it has syntax to handle CSS changes, it has rules that allow requests to only go through in certain contexts or if they're originating from certain domains. And most importantly, there's a giant community of people basically standardized on Ublock Origin who maintain all of these lists and who are constantly identifying new threats and proposing new features.
So a competitor to Ublock Origin would need to be constantly competing with it, it would need to be pulling in new features as they got released, and it would need to be consuming the same lists that Ublock Origin uses. It's just really hard to keep pace with that.
If Mozilla came out tomorrow and said they were going to do native adblocking, I would trust them less than Ublock Origin. I don't think even they would be able to keep pace if they were trying to build a community from scratch.
Sadly, I doubt that'll ever happen with the amount of funding they get from Google.
That being said:
> it has rules that allow requests to only go through in certain contexts or if they're originating from certain domains
I haven't personally seen a proposal for server-based blocking outside of the browser that could begin to tackle this problem, and contextual blocking is a huge part of what makes browser adblockers work so well. As far as I can tell, adblock-rust isn't an exception to that.
It's a very difficult problem. In order for you to have a rule like "block 3rd-party requests on a-bank-website.com", you need more information than just the request itself. Maybe this is something where sites could piggyback off of CORS requests? But browsers don't always send CORS requests.
I'm not sure what the solution would be, but regardless I don't think that blockit would be a replacement in its current state. Still looks like a promising project as a network-based blocker though.
It's hard to trust the smaller browsers to keep me private online if there isn't something that gives me that same level of control over blocking. And there's a huge adblocking community built around this software that maintains lists, fixes websites, and it's just a bunch of privacy-focused community effort that is hard for any small team to replicate.
But aside from webextension support, Nyxt looks really exciting, and I'm glad that people are building browsers that are actually innovating in this space.