There is a bit of a stir in the Linux community this week. Little Snitch, the venerable gatekeeper of macOS network traffic, has finally made its way to our shores. On paper, it is an impressive bit of engineering. It utilises eBPF for high-performance kernel-level monitoring and is written in Rust, which is enough to make any technical enthusiast’s ears perk up. It even sports a fancy web UI for those who prefer a mouse to a terminal.
But as I looked closer, the gloss started to peel. While parts of the project are open, the core logic, the “brain” that actually decides what to block and how to analyse your traffic, is closed source.
For a FOSS enthusiast, this is a total non-starter. We don’t migrate to Linux just to swap one proprietary black box for another. If I cannot audit the code that sits between my binaries and the internet, I am not interested. A security tool that asks for blind trust is an oxymoron. In my home lab, if the code isn’t transparent, the binary doesn’t get executed. It is that simple.
However, beyond the philosophical “no-go” of proprietary code, there is a more practical reason I am passing on this: I have already solved this problem.
As I’ve detailed before on this blog in The DNS Safety Net, my primary line of defence is AdGuard Home. By handling privacy at the DNS level, I have a silent, network-wide shield that catches the vast majority of telemetry, trackers, and “phone home” attempts before they even leave my Proxmox nodes.
Running a central DNS blocker is fundamentally more efficient than managing an application firewall on every single VM and container. I don’t get interrupted by annoying pop-ups every time a system process needs to check for updates. I set the rules once at the edge, and my entire network, including devices that cannot run a Snitch client, benefits. It is a set-it-and-forget-it solution that actually respects my time and my privacy.
Even at the application level, I already have better alternatives in place. For this blog, I use Wordfence. It acts as a localised firewall, monitoring for malicious traffic and unauthorised changes right at the source. Between network-wide DNS filtering and application-specific security, the layers are already there. Adding a proprietary binary into that mix adds complexity without adding meaningful trust.
Now, the “security experts” will tell you that a DNS-style blocker is “too high level.” They will point out that it cannot see direct IP connections that bypass DNS. While technically true, I have to ask: in a well-curated FOSS environment, how often is that actually happening? And if it is, would I really want to use a closed-source tool to find it?
If I ever needed to track down which specific application is making suspicious outbound connections, I would turn to OpenSnitch, the fully open-source, community-driven application firewall for Linux. It is not as polished as the new Little Snitch port, but every line of its code is open for inspection and it does not ask for blind trust.
The arrival of Little Snitch on Linux is a sign that the mainstream is finally waking up to the “chatty” nature of modern software. But we do not need to import the proprietary culture of macOS to stay safe. We have better, more open ways to build our walls.
My network is quiet, my logs are clean, and my gatekeeper is a piece of transparent software I host myself. Until a tool comes along that respects both my privacy and the FOSS ethos I live by, that is not going to change. If you are serious about your own data, you should keep your gatekeepers open and your network controlled at the edge.
While I appreciate the author’s enthusiasm for FOSS, I’m no evangelist. I have a mix of both proprietary and open source components on my system at any given time. To each their own, I guess – but I’m glad that little-snitch joined the linux community with an offering. Their product on Mac is stellar. Hopefully, they will open it up completely at some point, but I don’t need access to source code to trust a product, I gladly used UltraEdit for a decade without it, and Little Snitch for almost as long.
Fair point, and I probably sounded a bit more like a zealot than I intended. I’m not entirely “pure” either, as much as I loathe the big tech grip, I’m still stuck with a few proprietary bits because, frankly, the modern world makes it exhausting not to.
Google Maps is my main “guilty pleasure” on Android. I’ve tried the FOSS mapping alternatives, but when it comes to real-time traffic and rerouting, Google is just… unfortunately better. It’s a total trap, but one I haven’t managed to escape yet.
My main gripe isn’t that proprietary software shouldn’t exist, but rather that we shouldn’t have to rely on it when a transparent alternative could do the job. I’d love to see a FOSS maps app that actually competes, but until then, I suppose we all have our compromises. I guess for me, security tools are just where I draw a harder line in the sand than, say, navigation!
Glad to have you reading the blog, though. Thanks for the perspective.
I found your blog while searching for solutions to an OpenSnitch (O.S.) problem. This may illustrate that developers beholden to supporting paid users (note: applicable to Little Snitch (L.S.) dev in a general sense, albeit not for Linux) may allow for a smoother experience, particularly so for the non-technical.
Despite this I happily take a more aggressive approach to the FOSS mandate. I would not use (or consider) L.S. Mostly this is due to its proprietary nature but, unlike similar comparisons made elsewhere, the addition of their Linux version reeks of motivation to squash the FOSS solution of similar scope. One that has been around for quite some time (I think I have used it for 5 yrs) but only has generated significant interest/publicity in the last year or so.
Nonsense because it too is free? Not when you consider the possibility that O.S. growth may logically result in resource expansion, thus potentially leave room for O.S. version(s) on L.S.’ paid product platform(s). Conspiracy theory? No, capitalism. This was a strategic decision by L.S. to draw boundaries around O.S. while leaving its own options open.
I agree with you that proprietary software is necessary on occasion. Doing so with software requiring SUID, however, is an exercise deserving of its outcome.
Peace,
honestJohn