Zen Desktop: a system-wide ad blocker for Windows, macOS and Linux

The gap Zen Desktop targets: traffic that never reaches a browser extension

Browser extensions see one program. They cannot see the tracker inside an Electron chat client, the telemetry call from a desktop utility, or a request made by an operating system component. Zen Desktop takes the position that filtering has to sit below the application layer to cover those cases. The README states that Zen "works by setting up a proxy that intercepts HTTP requests from all applications, and blocks those serving ads, tracking scripts that monitor your behavior, malware, and other unwanted content." That is the whole pitch: one filter engine for the machine, not one per browser profile.

The audience follows from that. It is for people who run a mix of native and web-based desktop software and want a single blocklist applied to all of it, and for those who want to add their own lists rather than accept whatever a browser vendor ships. It is not for someone who wants a zero-configuration browser add-on, and it is not a network appliance: the proxy runs on the device, so every machine you care about needs its own install.

How the proxy, the root certificate and the filter lists fit together

The architecture visible in the repository is a Go core with a Wails front end. The go.mod file pins github.com/wailsapp/wails/v2 v2.14.0, and the tree contains main.go, internal/, frontend/, jslibs/ and a wails.json, which is the standard shape of a Wails application: Go code compiled into a native binary, the UI loaded from the frontend directory. Platform integration pulls in golang.org/x/sys, github.com/godbus/dbus/v5 for Linux, howett.net/plist for macOS property lists and github.com/hectane/go-acl for Windows ACLs. That dependency set tells you the app is doing real per-OS work rather than shelling out to a single cross-platform tool.

Plain HTTP is straightforward to intercept: the proxy sees the request and answers or drops it. HTTPS is not, which is why the README says that on first run "Zen will prompt you to install a root certificate" and that this "is required for Zen to be able to intercept and modify HTTPS requests." The certificate, per the README, "is generated locally and never leaves your device." This is the same trust model as any TLS-inspecting middlebox, and it is the single most consequential design decision in the project: once the certificate is trusted, the proxy can terminate TLS for any host, so the security of the private key is the security of everything the machine sends.

Filtering itself is list-driven. Zen ships with pre-installed filters and accepts hosts files and EasyList-style filters, added by URL. The request history screen, described in the README, lets you inspect any blocked request and see "which filter and rule blocked it," which is the practical way to debug an over-broad rule. The repository also contains a jslibs/ directory and dependencies on github.com/tdewolff/parse/v2 and github.com/spyzhov/ajson, consistent with parsing and rewriting web content in the request path.

Installing Zen Desktop and blocking your first request

On Windows, the README points at an installer or a portable zip for x64 and ARM64, and documents a Winget package. The package identifier is ZenPrivacy.ZenDesktop:

winget install ZenPrivacy.ZenDesktop

On macOS there are .dmg installers and portable tarballs for Intel and Apple Silicon, plus a Homebrew cask named zen-privacy:

brew install --cask zen-privacy

Linux has a shell installer that the README says covers most distributions, and an uninstall path through the same script:

curl -fsSL https://raw.githubusercontent.com/irbis-sh/zen-desktop/master/install.sh | sh

curl -fsSL https://raw.githubusercontent.com/irbis-sh/zen-desktop/master/install.sh | sh -s -- --uninstall

Piping a remote script into a shell is a real supply-chain decision, not a formality. The alternative the README lists is the AUR package zen-adblocker-bin, or the portable tarballs for x64 and ARM64, both of which let you inspect what you are running before it runs. If you go the script route, note that the same URL is used for install and uninstall, so the flags matter.

After installation, the first run prompts for the root certificate. Accept it, then open the filter list manager and confirm which lists are enabled. To test the proxy rather than the UI, open the request history screen and load a page you know carries third-party trackers. Entries should appear with the filter and rule that matched. If the list stays empty, the proxy is not in the path yet, which on Linux usually means the desktop is not GNOME or KDE, since the README states that automatic proxy configuration there "is currently only supported on GNOME- and KDE-based desktop environments."

Where Zen Desktop breaks, and when it is the wrong tool

The root certificate is the first failure mode. Any application that pins certificates will reject the intercepted connection rather than fall back. Banking clients, some package managers and a number of games do this deliberately, and no filter list fixes it. The README documents the certificate prompt but does not describe a per-application bypass list, so a pinned app is likely to fail until you stop the proxy.

Second, the proxy is a single point of failure for all network traffic on the machine. If the Go process dies, is killed by an OS update, or is blocked by endpoint security software, every application that honours the system proxy setting loses connectivity until the proxy is restored or the setting is cleared. That is a heavier blast radius than a browser extension, which fails alone.

Third, platform coverage is uneven in ways the README admits. Linux automatic proxy configuration is limited to GNOME and KDE, so on a tiling window manager or a minimal desktop you configure the proxy by hand or not at all. Fourth, this is an early-stage project: the latest release listed is v0.25.1 from 2026-08-13, and a 0.x version number is a statement about API and behaviour stability, not modesty. If you need a filter engine with a long support window and a documented compatibility matrix, this is not that yet. And if all you want is fewer ads in Firefox or Chrome, a browser extension covers the same requests with none of the certificate work.

Zen Desktop compared with Pi-hole and with browser extensions

Pi-hole takes the opposite architectural bet. It is a DNS sinkhole running on a separate host, usually a Raspberry Pi, and every device on the network points its DNS resolver at it. Blocking happens before a connection is made, so there is no certificate to install and nothing to break on the client. The cost is granularity: DNS only sees hostnames, so it cannot block a path on a domain it otherwise allows, cannot rewrite page content, and cannot show you the rule that matched for a request that shares a hostname with legitimate traffic. Zen Desktop sits in the request path instead, which is why it can do EasyList-style rules and per-request history, and why it needs the certificate.

Browser extensions are the third option and the lightest. They run inside one program, need no system proxy and no root certificate, and cannot see anything outside the browser. The README makes this contrast explicitly, arguing that system-level operation "can protect against threats that browser extensions cannot, such as trackers embedded in desktop applications and operating system components." The honest summary is that the three tools trade reach against invasiveness, and Zen Desktop is the most invasive of the three by design.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-18, five days before this writing, so the project is being worked on now. Release cadence in the repository history is roughly one to three weeks between v0.24.1 on 2026-07-22, v0.25.0 on 2026-08-09 and v0.25.1 on 2026-08-13. A CHANGELOG.md sits at the repository root, which is where upgrade notes belong, though the README does not document rollback or a downgrade procedure, so pinning a known-good version before upgrading is your own responsibility. The go.mod pins a Go toolchain version and holds Wails one minor version behind latest, with a comment in the file explaining that choice; that is a maintenance posture worth reading before you build from source.

Licensing is MIT, per the repository metadata and the LICENSE file. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and licence text travel with it. That applies to the source. It does not automatically cover the filter lists Zen downloads, which come from third parties and may carry their own terms, and it says nothing about the privacy implications of routing your traffic through a local proxy. This is a description of the licence, not legal advice; if you plan to redistribute Zen inside a product, read LICENSE and COPYING.md and check the terms of each list you enable.

Editorial conclusion

Adopt Zen Desktop if you want blocking outside the browser, in desktop apps and OS components, and you accept installing a locally generated root certificate so it can read HTTPS. Do not adopt it if you cannot install a root certificate on the machine, or if you only need browser-level filtering, where an extension is lighter. Before trusting it, read docs/explanation/security-architecture.md to see where the certificate and private key are stored, and check whether your desktop environment is GNOME or KDE, because automatic proxy configuration on Linux is documented as supported only there.

Frequently asked questions

Official sources

1. irbis-sh/zen-desktop on GitHub
2. License: MIT
3. Project website
4. README
5. Releases