Privoxy

Content blocking normally happens inside a browser, as an extension the browser permits and the browser can also disable. Privoxy takes the other approach entirely, sitting outside as a local proxy that every application can be pointed at, filtering traffic before it ever reaches whatever asked for it.

That placement is the whole argument. An extension protects one browser, and a proxy protects anything on the machine willing to use it, including applications with no extension mechanism, no settings and no interest in your preferences.

Traffic passes through, rules are applied, and the modified result continues to its destination. Nothing is cached, deliberately, because caching is somebody else’s job and mixing the two produces problems.

Rules are text, and that cuts both ways

Privoxy keeps its configuration in files with a syntax of its own, covering which patterns to match and which actions to take when they match.

The power is real. Requests can be blocked outright, redirected, or allowed through with modifications. Headers can be rewritten, so the identification your browser sends becomes something else. Cookies can be blocked, allowed for a session only, or permitted normally, per site. Tracking parameters appended to links can be stripped before the request goes out.

The cost is equally real. None of that is discoverable through an interface, and somebody wanting to block one annoying element on one site faces learning a pattern syntax rather than clicking on the element.

A local web page provides configuration and status, which helps, and the substantive work still happens in the files.

It filters for everything, not just browsers

This is the Privoxy advantage nothing in a browser can match. Any application with proxy settings can be pointed at it, and the same rules then apply to that application’s traffic.

That covers a great deal that extensions never touch. Applications phoning home, embedded browsers inside desktop software, update checkers, and anything else making requests you did not initiate.

For simply deciding which programs may reach the network at all, rather than filtering what they send, simplewall answers that with a firewall rather than a proxy, and the two address entirely different questions.

The encryption problem

Here is the limitation that has reshaped what this software can do, and it deserves the most space.

Almost all traffic is now encrypted, which changes what Privoxy can reach. A proxy handling an encrypted connection can see which host is being contacted and can pass the connection through, and it cannot read or modify what travels inside without decrypting it first.

That means the classic content filtering, the part that rewrote pages and removed elements, applies only where content is unencrypted, which is now very little.

Privoxy can decrypt, by generating its own certificate and having the machine trust it, which restores the filtering at the price of a component that reads all your traffic. That is the same arrangement debugging proxies use, and Fiddler is the tool where that trade is normally made deliberately for development work.

Blocking by destination still works regardless, since the host is visible before encryption begins. So request blocking survives intact while content modification largely does not, and understanding that division is the difference between expecting the right things and being disappointed.

Chaining it onward

A common arrangement puts Privoxy in front of something else rather than in front of the internet directly.

Traffic goes to the local proxy, gets filtered, then passes to another proxy or an anonymity network for the actual journey. That combination gives you the filtering of one and the routing of the other, and it is a long-established configuration precisely because each does what the other does not.

Managing which sites use which proxy is a related job, and FoxyProxy switches a browser between proxied and direct connections by rule, which keeps the arrangement practical rather than all-or-nothing.

Blocking by name instead

For anybody wanting the blocking without the Privoxy syntax, a simpler mechanism requires no proxy at all.

The file mapping names to addresses can send unwanted hosts nowhere, which blocks them for every application on the machine with no software running in between. HostsMan manages that file with curated lists, and the standing caution applies, since aggressive blocking there breaks things you actually use and produces failures that are hard to trace.

That approach blocks whole hosts and nothing finer. Where the requirement is modifying rather than blocking, the proxy remains the only route.

Conclusion

Privoxy remains a capable and maintained tool built on an idea that has aged in a specific way. Filtering outside the browser still covers ground no extension reaches, request blocking works as well as it ever did, and the rule language is expressive enough to reward anybody prepared to learn it.

The encryption question decides how much of it you actually get. Without decryption you have a precise request blocker for every application on the machine, which is worthwhile. With decryption you have the full filtering and a component reading everything you do, which is a considered trade rather than an obvious upgrade. Decide which of those you are installing before you begin, because the configuration effort differs enormously between them.