A Firewall That Asks You Questions Does Not Work
The approve-or-deny prompt is the defining feature of most Mac firewalls, and it is the reason most people stop using them. Not because the prompts are badly made, but because the question they ask cannot be answered well by the person being asked, at the moment they are asked, with the information provided.
This is an opinion, and it is the reason MiniFirewall is built the way it is. Here is the argument.
What the prompt actually asks
A window appears. It says a program, often one you have never heard of, wants to connect to an address, often one you have never heard of. Allow or Deny.
To answer well you would need to know what that program is, what it legitimately needs, who owns that address, and whether this particular connection is normal for it. You have none of that. You have a name and a number, and something else you were in the middle of doing.
The prompt presents itself as informed consent. It is closer to a coin flip with a stern face.
What people actually do
Three things, in roughly this order.
First they read them. For a day or two, every prompt gets attention. This is the period the design is optimised for, and it works: you genuinely learn things about your own machine.
Then they start guessing. The volume is the problem. A normal Mac makes hundreds of distinct connections a day across dozens of programs, most of them parts of macOS with names that mean nothing. The prompts keep coming and the information does not improve.
Then they click Allow. Not as a decision, as a reflex to clear the window. At this point the firewall is installed, running, showing a reassuring icon, and protecting nothing at all. Everything got approved.
The people who avoid that outcome mostly uninstall instead, which is the more honest end state.
This is not a criticism of Little Snitch
Little Snitch is a genuinely excellent piece of software and has been for twenty years. For someone who wants control over every connection and has the patience to exercise it, nothing else comes close, and the prompting is exactly the right design for that person.
The problem is that this person is rare, and the software is recommended to everyone. Someone who read that an app phones home and wants to stop it is handed a tool that requires them to become a part-time network administrator. They do not become one. They click Allow.
What is the alternative?
Record, do not interrogate. Watch what happens, keep the record, present it in a form a person can read, and let them act on it whenever they like.
The difference is when the decision happens. A prompting firewall makes you decide at the worst possible moment: mid-task, with no context, under time pressure, about a thing you have never seen. A recording firewall lets you decide when you are curious: at your desk, with the whole picture, when you went looking on purpose.
The same decision, made calmly, is a much better decision.
What does that design give up?
Something real, and it should be stated rather than glossed over.
A firewall that never interrupts you will not tell you about something you never thought to look at. If a program starts contacting a server tomorrow and you do not open the app for a month, nothing will alert you. A prompting firewall would have caught it at the moment it happened.
That is the trade. Prompting catches more and costs attention you probably will not keep paying. Recording catches what you go looking for and costs nothing. Both are defensible; what is not defensible is pretending the trade does not exist.
Why not just prompt less?
This is the obvious middle path and it has a subtle failure. A firewall that prompts only for “suspicious” connections has to decide what suspicious means, and it cannot, because it does not know what you consider acceptable. What it can do is guess, which means either prompting often enough to become noise again, or staying quiet often enough that the prompts stop meaning anything.
Worse, a rare prompt trains a worse habit than a frequent one. Something that appears once a month gets clicked through without reading, because you have no practice at reading it.
Choosing a position and holding it consistently is more honest than a threshold nobody can set correctly.
The design rule underneath all this
If a security tool’s correct operation depends on the user making frequent judgements they are not equipped to make, it will be defeated by ordinary human behaviour, and its failure will be silent.
Silent is the important word. A firewall that has been Allow-clicked into uselessness looks identical to one that is working. There is no error, no warning, and no moment where anyone finds out. It is worse than no firewall, because no firewall at least does not make you feel protected.
Sources
- Little Snitch, Objective Development, on the connection alert design
- LuLu, Objective-See, which uses the same model