What I really liked about ZoneAlarm wasn't just that it was a very nice technology - and it was; but also that it got the user expectations and training right from a very early stage.

It was quite insistent on the fact that it would be "noisy" at first as it queried all the programs you ran, but would then quieten down once it had been "trained". It got that across in clear, simple language.

I think it was so successful because it got the soft side of its security job right as well as the hard part. It's certainly why I recommended it to anyone at the time...

I wrote a program similar to this for AmigaOS many, many years ago. I would have been inspired by ZoneAlarm or a program like it.

I've just found it and uploaded it to github. Looking at the code, I can see my horrible C style of the time. There's probably bugs galore.

https://github.com/JetSetIlly/Direwall

If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.

It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.

> [ZoneAlarm] I always found it weird that Linux never really had anything like it.

There was simply no need for it. GNU provided most of the software, spyware was unknown.

Only since comercial vendors package for linux and bring their spyware along, the desire to inspect network rose.

Completely forgot about ZoneAlarm. I remember using it in the early 2000s!

This reminded me of running Kerio Personal Firewall. When Kerio ended I switched to either ZA or Comodo firewall, one of them introduced a neat feature of running executables in containers. Made clicking random things so much easier. But the best part with all of these was restricting windows to where it could barely do anything. "RandomXYZ.DLL wants to execute random what and connect to random where? I dont think so MS." lol

Who remembers BlackICE Defender tho?

https://archive.org/details/BlackICE_Defender

I ran ntop on a router in 2001. It had a highly insightful overview of traffic with nice looking diagrams and everything. There hasn't been anything like that since as far as I'm aware.

ZoneAlarm otoh, was snakeoil. Programs that ran at the same privilege level (typically everything) could bypass it in various ways.

Wow. Insane throwback. I think I first learned about ZoneAlarm from some PC magazine my parents bought for me. Completely forgot about this great piece of freemium!

Back in the Halo 2 days ZoneAlarm and Cain and Abel were the go-to host bridging and bluescreen programs.

A simpler time lol.

Used to use Outpost Firewall Pro, too.

For me it was Sygate personal firewall back on windows xp

It's interesting hw lng it took for linux to get a user friendly application firewall like OpenSnitch

There was also Tiny Firewall which got bought by Computer Associates around 2005. Probably the most complicated or fine grain control for me at that time in Windows XP.

i loved zonealarm! and also pained myself with all the little rules and upkeep lol

It was problematic, so we moved to blackice defender iirc

isn’t this essentially built into Windows these days? although it seems to come with a lot of programs pre-approved.

[flagged]

The year of the Linux Desktop will always be $CURRENT_YEAR + 1

  > ## Accelerating Change [One School]
  >
  > Our intuitions about change are linear; we expect roughly
  > as much change as has occurred in the past over our own
  > lifetimes. But technological change feeds on itself, and
  > therefore accelerates. Change today is faster than it was
  > 500 years ago, which in turn is faster than it was 5000
  > years ago. Our recent past is not a reliable guide to how
  > much change we should expect in the future.
  >
  > Strong claim: Technological change follows smooth curves, 
  > typically exponential. Therefore we can predict with fair
  > precision when new technologies will arrive, and when they
  > will cross key thresholds, like the creation of [AI].
  >
  > Advocates: Ray Kurzweil, Alvin Toffler(?), John Smart

  https://www.yudkowsky.net/singularity/schools

> 2026 can without irony be named as Year of Linux Desktop, right?

For whom? Average desktop users? Average users don't know what LittleSnitch is, let alone calling it "popular software."

I think there is a lot of talk (and this is good), but very little action. Market share is still incredibly low for LNX. I believe only a small subset of people actually attempt the jump from WIN to LNX (since most just want to play their games and run their programs without hassle) and then quickly realize that its tougher than they anticipated and swiftly return to WIN.

2026 is the year of the linux phone. We need to embrace that the year of the linux desktop (2025) was successful.

Also unrelated, but more linux gamers proves my personal observation that on the spectrum of computer literacy gamers are just below powerusers and programmers. We see more less technical people migrate over to Linux gradually and now it's gamers turn. Well, that's kind of obvious for everybody except Microsoft apparently.

does wifi work yet? last year it didnt for me

No.

This gets even more involved when you consider things like loading libraries, there's also the impact of calls like OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land versions, though I'm sure similar exists elsewhere).

The "good" Windows firewalls like Outpost and Zone Alarm used to have features to catch this, they'd detect when a process tried to invoke or open a running process which had internet access. They'd also do things like detect when a process tried to write a startup item. This went by names like "Leak Control" but it was basically providing near-complete HIDS features with local control.

It depends. Little Snitch for Linux has a two level namespace for processes. It takes the process doing the connection and its parent process into account when evaluating rules.

Also: If an interpreter is run via `#!/bin/interpreter` in the script binary, it makes the rule for the script file path, not the interpreter. This does not work when running the script as `interpreter script`, though.

With the literal rules described it would not be blocked. A more detailed rule (in Open Snitch at least, not as familiar with the other variants) could match e.g. whether the process's parent tree contained the python binary rather than just if python is the process binding the socket.

The SELinux MAC policy should restrict which files and ports each process may access. In general, most modern distro have this feature, but normal users do not go through the rules training and default enable flag setup. =3

I just tried littlesnitch and it did not resolve very many ips to domains, which is pretty basic. It also failed to identify most processes, and they were grouped under "Not Identified". It appears these are known limitations of the Linux version [1]. So for that alone I need to stick with opensnitch.

[1] "Little Snitch for Linux is built for privacy, not security, and that distinction matters. The macOS version can make stronger guarantees because it can have more complexity. On Linux, the foundation is eBPF, which is powerful but bounded: it has strict limits on storage size and program complexity. Under heavy traffic, cache tables can overflow, which makes it impossible to reliably tie every network packet to a process or a DNS name. And reconstructing which hostname was originally looked up for a given IP address requires heuristics rather than certainty. The macOS version uses deep packet inspection to do this more reliably. That's not an option here." -- from https://obdev.at/products/littlesnitch-linux/index.html

Not sure, I was wondering the same, opensnitch is what I have installed but its not on currently, I probably got tired of it for whatever reason.

It is free, no subscription at all and truly open source.

As software should be.

"I researched a bit, found OpenSnitch, several command line tools, and various security systems built for servers. None of these gave me what I wanted: see which process is making which connections, and in the best case deny with a single click." https://obdev.at/blog/little-snitch-for-linux/

Sorry, we have not tested on Fedora before release. Did not expect so much interest in the first hours after release...

I have now installed Fedora in a VM (ARM64 architecture, though) and it does load, but cannot identify processes. I'm investigating this now.

The other issue seems to be with eBPF compatibility. That's a moving target and I'll investigate next. But resources are limited, I'll need some time to dig into this.

From the download page on the website:

"Note: Little Snitch version 1.0.0 does not currently work with the Btrfs file system! Btrfs is used by default on Fedora, so Little Snitch does not currently identify processes on Fedora. We are working on an 1.0.1 release to fix the issue as soon as possible!"

Someone already created an issue for it: https://github.com/obdev/littlesnitch-linux/issues/1

I was looking for a comment like yours. Same issue, in my case only eating up half of my cores but with 100% utilization, webUI not working.

Your average Linux experience.

And the second most upvoted comment is someone seriously asking if 2026 if the year of Linux desktop...

Many from linux crowd are slightly paranoid and ideological.

I'm as a linux user very reluctant to install anything proprietary that has such sensitive info as my network traffic and would rather use opensnitch or any other foss fork.

The same time I don't mind to pay for open-source, I donate several thousands USD per year to FOSS projects. But I guess I'm in a minority here and if you make the whole stack open-source you're not going to make many sells really.

As the author of Little Snitch for Linux, I can tell you what drives us: we are a small company where people (not investors) make the decisions. It was a personal choice of mine, driven by a gut feeling. I'm curious about the outcome...

I am the same, used Little Snitch for a few years back in the late 2000s, I think like 2010 until a few years back when I moved fulltime to Linux. Back then, my parents had an iMac and I was the designated "IT" person to keep it running efficiently. My siblings had a bad habit of installing games and hack software on it for their games. I ended up purchasing a license and after the first few hours/days of configuring allow/block lists, it worked pretty well. It earned the label of "Little B*ch" from them since it would stop their gaming hacking apps from connecting and wrecking havoc. Eventually I learned to keep them on a standard user account and separate admin for installing software.

Long story you didn't ask for. Like I said, I haven't used Little Snitch in a while. I'll give this a whirl this weekend. What I have done over the past few years is run AdGuard Home on a min home server. This has helped keep ads undercontrol in our hoursehold and I have an easy "turn off adguard for 10 mins" in homeassistant for the wife so she can do some shopping online since it can occasionally break some sites, but overall they tolerate adguard and think it's a good middle ground. I have a few block lists, nothing too crazy or strict to avoid breaking most sites. On the desktops/laptops, they all run FireFox w uBlock origin.

How deep it was in the OS was exactly what I liked about it. I only wished it were open source so I know what exactly is happening with that level of access.

I’ve also wanted something like this. The challenge is with an external appliance you lose awareness of which process is initiating the request.

This is solvable to some degree but requires varying degrees of new complexity depending how smooth of a user experience you’re aiming for.

Very nice, I will give it a try later

It just depends on the UI frameworks available to developers and their interest in building something good-looking. Different UI frameworks are available for different platforms, and there are only a few good ones that are cross-platform. Qt and GTK are pretty common for linux apps and typically don't look great.

Disclaimer: I'm the developer of Little Snitch for Linux. Regarding MITM concerns: The eBPF component, which actually sees all the traffic, is Open Source (GPLv2). You can review it on Github and verify whether it sends any data to user space: https://github.com/obdev/littlesnitch-linux

But the trust issue is still real, the daemon has to run as root because it needs to watch for new mounts and keep a table of file system roots up-to-date, even after loading all the eBPF programs. As a root process, it can technically do whatever it wants. Unless you limit it with a kind of mandatory access control (SELinux or similar).

This is the very first release and we will probably come up with a more restricted permission requirement in the future. For the moment, I try to catch up with bug reports. There seems to be more diversity in the Linux landscape than I had expected.

> All a long way to say, anyone know anything about this company?

Yes, they are indie Mac developers who have been in business for more than 20 years, and Little Snitch for Mac is beloved by many users for a long time.

disclaimer: I co-develop (FOSS) Little Snitch / Open Snitch inspired firewall but for Android

> little snitch given its a full kernel extension

On macOS, don't think Little Snitch needs kernel exclaves / extensions. Apple provides userspace ("Network Extension") APIs (however limited) for apps like Little Snitch to use (instead of pf).

> effectively able to MITM your whole network stack

"MITM" means something else, anywho... if network observability (not firewall) is the primary need, cross-platform (GUI) sniffers like Sniffnet exist: https://github.com/GyulyVGC/sniffnet

I'd be curious to hear additional details if you can share - got a timeline, or somewhere I can enter my email address for updates? I'd love to alpha/beta test if you're looking for testers.

I've been a GlassWire user for years, which partially fills the role of LS, but not very well. Aside from the many performance issues I've seen, it's missing a lot of LS essentials. To be fair, I think the focus of GlassWire is more about visualizing traffic on your Windows computer, but I definitely believe there is a need for better Windows network software for power users.

eBPF is very limited in the code complexity you can achieve. DPI on QUIC, for example, needs a lot of cryptography. That's simply not possible in eBPF. DPI on ordinary TLS still requires that you collect enough network packets to get the name, hold them back until you have a decision and then re-inject them. Holding back packets is not even possible at the layer where we intercept. And even if we find a layer to do this, it adds enough complexity that we no longer pass the verifier.

Yeah I thought that was one of the primary use cases of eBPF. Not an expert though, just read about some of these things.

In linux, I trust most distro apps to run with network access without any sort of firewall. And for apps from internet, just put them in bubblewrap or run with flatpak without access to homedir, network, audio, video etc. depending on program.

[dead]

portmaster is the tool i use for upgrading installed ports on freebsd since… like… olden times.

>attention to detail

Why does LittleSnitch (Mac) pre-resolve IP addresses, before user presses Accept/Deny?

IMHO DNS queries shouldn't initiate without user input.

You are referring to the TCP three way handshake problem here. The macOS version is bound by the API provided by Apple: We get the API call for filtering only after the three way handshake has started.

The Linux version is limited in complexity. It has to decide immediately. This has the consequence that no packet leaves the machine if the connection is denied, but on the other hand it means that it's easier to trick. The macOS version can inspect the first packet sent (deep packet inspection) to find the remote host name in TLS headers. The Linux version relies on heuristics: The most recent lookup seen which returned the IP address determines the name. This part is Open Source and you can inspect the algorithm.

Something almost no firewalls get right is pausing connections (NOT rejecting them) until I've decided whether to allow or not. The only firewalls I've seen do this are Little Snitch for Mac, and Portmaster for Windows (before they made it adware / started locking existing local features behind the subscription).

Is that true? If so, that’s not a good sign. I remember how impressed I was by ZoneAlarm in the early 2000s asking permission for itself to connect to the Internet, using the exact same dialogue it presented for any other program, with no dark patterns suggesting that the user should give preferential treatment to it.

Any proofs for this claim?

It does… and if it didn’t it would be trivial to prove.

I would say it's better.

Fort Firewall is my tool of choice. Each connection requires explicit approval.

On macOS, it requires access to /dev/bpf. That's why we added filter rules for bpf there.

On Linux, we intercept at a level where packets already have an Ethernet header. I hope that Paqet injects before* this layer, but only a test can give the proof.

Thanks for sharing Open Snitch

This is correct, of course. 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.

Same.

They are still restricting iCloud Private Relay to Safari for the most part. iOS is really wanting for privacy improvements to close the gap between marketing and reality.

Fun fact: iOS lets developers spy on when you _dismiss_ notifications:

https://developer.apple.com/documentation/usernotifications/...

Ever instantly angry-swipe-to-clear a DM notification soon as it hits your lockscreen from someone who upset you? Zuck knew y'all had beef.

Clear notifications before bed and in the morning? All those companies could know a bit more about your routine than you would've otherwise revealed if weren't in the habit of using those apps at those times.

--

The kinds of tiny things that would be pretty inconsequential on their own but that you figure maybe the Apple tax would help you avoid.

(edited with additions)

I’m not aware of flatpaks specifically having th capability to run system software, daemons, etc. Some other immutable packaging formats should be able to (systemd-sysext at least, and snap iirc).

As far as I can tell, Flatpak does not allow a daemon running as root early during system boot.

An operating system is roughly broken into three parts: the kernel, the core system tools, and the shell (the desktop environment and/or the CLI shell). Linux: Linux kernel, GNU coreutils (usually), KDE/Gnome/etc + CLI shells. macOS: XNU, BSD userland + launchd/etc, Aqua/Cocoa. Windows: NT kernel, Win32/WinRT/etc, Windows Shell.

The systems LittleSnitch uses to do packet inspection are very much OS-specific. There's no generic standard for doing high-performance packet inspection. XNU and Linux are *very* different kernels. Linus Torvalds built Linux from scratch as a monolithic kernel because he wanted a Unix-like OS that wasn't encumbered. XNU is based on the Mach microkernel though XNU is a hybrid or monolithic kernel, not a microkernel. The point is, they have very different heritage and very different systems for... well pretty much everything. So "just *nix under the hood" is kind of true but also completely besides the point as far as packet inspection goes. And even then, while there are a lot of similarities between the core system tools of Linux and macOS, they're still quite different and unless you're limiting yourself to POSIX-standard interfaces (which are only a fraction of the system), you're not going to be able to use the same code on both systems.

More the opposite. macOS is a veneer of nix, but underneath it is the XNU microkernel. Lots more nuance since Apple took over and added a lot of their own performance and API improvements to

From what I understand, macOS uses weird kernel implementation, which is almost open source, but not 100%

BSD family with fewer GPL parts each year

In theory, it could be possible to get the requirement down to 5.17, but I don't get around the verifier constraints on pre 6.12 kernels. Maybe somebody who is more experienced with eBPF and the verifier can help. This part is Open Source and you can replace it.

Little Snitch must be running when the process starts in order to identify it correctly. You get less "Not Identified" if you run it for a while, or you should get none if you reboot and Little Snitch can start before everything else.

I would love to fix this requirement, but have not found a way yet.

eBPF is extended in every kernel version. There is a layer where you get network packets and return a verdict. Little Snitch uses this type of eBPF function. You can look at the sources on Github.

There is currently no treatment of errors because I would not know how to handle them anyway. There are two tables which can overflow affecting the filter: the table of open flows and the table of recent DNS lookups. The table of flows just fills up, meaning that we cannot store state about new flows. Without state, we can't attribute a process to them and end up evaluating rules on each packet. I guess that blocklists would still work, but more specific rules would not be applied (and the default decision would be taken, whatever you have configured).

The DNS lookups, on the other hand, are LRU. If the table overflows too soon, we won't be able to derive names for IP addresses and name-based rules would fail.

Just because I did not port the parser for it to Rust. And I thought that the lsrules format is rare for blocklists. If there is popular demand, we can add it.

Probably because it relies on eBPF rules on Linux?

It barely has any of the features of the MacOS version, there is no shortage of cracks for Little Snitch, and there is Lulu. Other than that, I am not sure.

I don't think it'll have access to the macOS connections, and certainly cannot act at the kernel-supported level as a firewall on the Mac side.

Little Snitch requires packet inspection. If you ran it in a Linux VM, it will inspect packets within the VM. So... kind of useless for monitoring connections on the host.

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.

then it pretty obviously is not better?

Which one? Mac or Linux? For the Linux Snitch, just stop the service. For the macOS Snitch, you need to move the app to the trash via Finder. Only Apple can remove the network extension and they do this only when deleted via Finder.

eBPF limits the size of the code, its complexity and how data can be stored. You cannot just implement any algorithm in eBPF for that reason.

That's not only a weakness, it's also a strength of eBPF. This way it can provide security and safety guarantees on the code loaded into the kernel.

Two of the three components of LittleSnitch for Linux are open source. The eBPF (kernel portion) and UI are fully open source.

> Do you still trust them not to do self-reporting or phoning home, even though it is $0 and closed source?

If you trust Little Snitch on Mac, then yes.

They've been in business for over 20 years. They're not going to blow their entire business and reputation for a few Linux users.

Linux maybe, not so true of all the DEs and apps installed on it

This is different. This shows you what in your operating system is making connections out and to where.

I run both (LS on Mac, at least), they do different things - pi.hole is a great ad blocker which applies to all of the devices on your network. Little Snitch is doing something different - it tells you every call that every app you use is making, and allows you to approve or deny each one. So, you can block telemetry for apps, or you can block certain apps from contacting certain servers, or you can just use it to watch what apps on your system are calling out to where.

LittleSnitch isn't for ad blocking (only), it is for tracking/blocking/allowing ALL connections from various processes. PiHole only blocks DNS requests to known ad servers.

Completely different thing. A littlesnitch type thing is for all traffic. Pihole is a DNS query thing that prevents various ad content from being loaded. It's also trivially easy for a malicious application with network access to bypass any instance of pihole on your LAN by doing its own DNS over HTTPS lookups to its own set of server(s) by IP.

eBPF programs are able to accuratly process network traffic in high performance, but the amount of CPU instructions you can use is limited. Otherwise it would not be high performance. This limits the complexity of in-kernel processing.

I guess you haven't actually implemented anything in eBPF.