If you don’t like closed source software and don’t trust the developer(s), then don’t use the software. Why waste time writing an article that all it does is critize the developer’s decision?
If you care so much about the software you run in your computer, then do what I do: open a disassembler and reverse engineer the code, inspect every single HTTP(S) call, every network packet, every system call, and then maybe you will feel at ease.
Pointing out that a "privacy" tool has a closed-source brain isn't an attack on the dev, it's just a heads-up for people who care about that sort of thing.
Also:
> Little Snitch is not there to replace OpenSnitch. It's just an additional option you can choose from. Some people might prefer it, others not.
https://news.ycombinator.com/item?id=47701918
> But I currently can't make the entire project Open Source. My other option would be to keep it completely private (wrote it mostly for myself in the first place).
> I think it's still better to make it public and only partially Open Source so that some people can benefit from it. If you don't trust us, that's completely reasonable, just don't install it.
OpenSnitch and PiHole are simply a must on every network.
To each their own, I guess, but that would be a hard pass from me. One example from mobile: FF on android keeps trying to connect to its various services (like firefox.settings.services.mozilla.net). For privacy reasons, I use NetGuard to block this and other similar domains. But there is a gotcha: there are sites (like seekingalpha.com) who refuse to load if access to these same domains is blocked - even on a completely different browser! With NetGuard I can still visit those sites in the secondary browser while blocking Mozilla tracking. With DNS blocking I wouldn't be able to do that.
I remember discovering remote kernel debugging across ethernet; it was magical.
I prefer to take the hit on those rare site-breaking edge cases if it means I have a single, transparent "source of truth" at the DNS level. It's definitely a trade-off, but I'd rather spend my time building things than perpetually tweaking firewall rules for every new service I spin up.
edit: In fact, every PHP file is being leaked, for example, this file [2] contains a $hash_salt , which is supposedly being used to “prevent[s] users guessing filenames and make data more secure”
You wrote as if you've made some kind of discovery: "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."
Strangely, your post does not even link to the product page https://obdev.at/products/littlesnitch-linux/index.html or the announcement https://www.obdev.at/blog/little-snitch-for-linux/ both of which are clear that a part of it is not open source. Indeed the blog announcement even mentions and links to OpenSnitch.
Security: BlockBlock, KnockKnock, RansomWhere...
System/Productivity: TaskExplorer...
Yes times 4
They’re doing the lord’s work.
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.