[Little Snitch 4.3.1 Serial
Alfonzo Liebenstein
I have been using LittleSnitch for 5+ years.....it is safe.......it lets you be in control of any apps or background processes that might want to call out to the Internet....gives you the choice to Allow or Deny the attempt.....
The primary, and really only, danger is that you can cut off some functionality of some applications if you deny the appication access to the network. So if you decide to try Little Snitch, you'll need to learn a it about how it works and about your applications. Worst case is that if it causes problems you can just remove it.
I've been using it since v1.0, I believe and it's very safe as long as you know what you are doing. I would also mention that it's a bit of a PITA to initially set up as it will ask your permission for almost every appication and process that needs to communicate over your network. You will find some processes that you aren't aware of that must be given permission or they won't work. You will probalby need to Google some of them to find out exactly what they are before making a decision.
Hi, many thanks for the advice, this goes to all who answered. As I have become so much more security minded thanks to you guys, yu advice. I will find out how to use litte snitch and also pass this information to my friend. thanks once again.
I needed to remove Little Snitch from a system that wouldn't boot (hence, couldn't use the uninstaller) and accomplished it by logging in to Single User Mode (hold down Cmd+S) then mounting the drive and running commands from a script posted at apple.stackexchange.com/questions/56481/remove-little-snitch-via-script
I found that using launctl alone wasn't enough - I guess the kext was still loaded, because I'd see LS(4050) Little Snitch Start in the verbose startup messages after I'd unloaded and rm'd all my /Library/LaunchDaemon/ scripts
I guess it literally goes without saying that this discussion was spurred by my blog posts. Another strange thing about their response was the timing, which was the morning after the WWDC keynote, so it mostly got lost in all of the other big news. I didn't have much time to look at it last week, so I'm coming back to it now.
In my follow-up blog post, I mentioned that I filed a bug report with Apple (FB12088655 "Privacy: Network filter extension TCP connection and IP address leak"). I've received no response from Apple to my bug report. However, the developer of Little Snitch (Objective Development) claims that this behavior is by design, not a bug, and indeed defends the design.
Before I address the defense, I want to emphasize that IP address leaks are a serious privacy problem. It's one of the reasons that VPNs exist. Apple's own iCloud Private Relay, which is similar to a VPN in some ways, is also designed to hide your IP address. Thus, I think we need to start with the assumption that network filter extensions ought to avoid leaking your IP address, if possible.
I feel that bringing up browser benchmarks is a red herring that doesn't help the argument at all. Every browser on the Mac is affected equally by a network extension like Little Snitch; it makes no difference whether you use Safari, Google Chrome, or Firefox. Perhaps Objective Development is referring to Mac vs. Windows comparisons, but that's still a red herring and makes little sense, because benchmarks would not typically be taken with a network filter extension installed. Little Snitch is not a built-in macOS component but rather an optional third-party app, used by only a small minority of Mac users. This small minority tends to care deeply about their privacy, which is why they spent the money to purchase Little Snitch.
I'm not persuaded that performance over privacy is a good tradeoff for network extension users. And we don't even get the choice. Apple is imposing its decision on everyone, with no options. And speaking of performance, do you know what else can degrade it? iCloud Private Relay! Apple essentially admits this while trying to dance around the fact:
Additional latency may be the price of protecting your privacy, and that's a price I'm willing to pay. Moreover, network latency due to the distance between client and server, especially for intercontinental connections, may dwarf whatever local process latency exists between kernel and network extension. Although I do wonder whether Apple's design here is inherently flawed. Why is the kernel waiting on user space?
Compare network content filter extensions with Safari content blocking extensions. With the latter (my own StopTheFonts is an example), the content blocking extension declares a set of static blocking rules, and then Safari itself does all of the work of applying the rules, in Safari's own process space; the extension process doesn't even need to be running at the time. Whenever the user changes the content blocking rules in the app, the app simply tells Safari to reload the rules. Safari is never waiting on the content blocking extension to provide a verdict on individual URL loads.
It seems to me that Apple could do network content filter extensions the same way. Why couldn't Little Snitch provide its rules to the kernel in advance and let the kernel itself do all of the filtering, without having to switch contexts? Of course, when there's an "Ask for Connections" rule, the kernel would have to call out to user space, but in that case there's no reason for the kernel to optimize by starting the TCP 3-way handshake, because presenting a dialog to the user and waiting for a manual response already introduces a huge, potentially unbounded amount of latency. (For those not familiar with Little Snitch, it has 3 types of rule: "Allow Connections", "Deny Connections", and "Ask for Connections".) A design analogous to Safari content blocking extensions would seem to mitigate some of the latency that Objective Development mentioned, without sacrificing privacy. Even in those cases where deep packet inspection is required to associate the IP address with a URL host, that work could also be performed directly by the kernel instead of the user space process.
One of the questions I raised in my blog posts was not answered by Objective Development: why does Little Snitch leak your IP address on every TCP connection attempt, when LuLu and my own sample network filter extension do not? Describing the implementation of the earlier version 4 of Little Snitch, which was based on their own kernel extension, Objective Development explains why the TCP 3-way handshake was allowed in some limited circumstances:
The necessity of deep packet inspection in some cases doesn't explain the current behavior of Little Snitch 5, which allows the 3-way handshake in all cases. And regardless, I would like the option, as a user, to enable or disable this behavior, so that I can control my own privacy level. I don't want Apple or Objective Development deciding that for me.
Hello all,
Little Snitch is is essentially a tool that allows you to monitor inbound and outbound connections on your Mac and control whether those connections are allowed or not.
You can learn more about Little Snitch at:
I have for several years attempted to encourage the developers of Little Snitch to please consider making the app accessible to VOiceOVer users.
With sighted help, you can configure Little Snitch to be more accessible by acting an option used for scripting the UI. The argument by the developers is that enabling the option makes Little Snitch more insecure because someone could, in theory, hack into your machine and take over control of Little Snitch. My counter argument has always been that if the machine is configured correctly this is not a concern. And honestly, if someone has gained control of your machine, it really doesn't matter what they do with Little Snitch at that point.
With all that said, I had an open and honest email conversation with one of the team managers who has tried advocating for VOiceOver accessibility. They could easily implement a mechanism to determine if VOiceOVer is enabled and activate the UI hooks for VOiceOVer users. I'm sure there are other things they can do. The point is, accessibility can be balanced against security.
What I would appreciate is if you have any interest in this app, please reach out to the developers via their support page: =LS or via Twitter, @littlesnitch.
Most developers start to pay attention when they realize there is interest from the community. I hope you will take a look at this app and consider sending a note asking for greater support for VOiceOVer users.
It's kind of interesting how a company like objective development can make both a very accessible app (Launchbar) and a not very accessible one (LS). While I personally don't use a firewall with my Mac, a friend uses an app called hands off and he's very happy with it. It's fully accessible and has all the features of little snitch.
I concur, but in all fairness, I think they truly believe that somehow accessibility in this specific instance would compromise security. Of course, I'm not entirely sure if they are the same team or different teams under the same umbrella. I tried Hands Off, which is mostly accessible. There are a few key areas that are not and repeated attempts to reach out to the developer have not received a response, even via Twitter. At least Johannes at Objective Development does respond and seems really interested in helping. He just needs our help to help him. I'm mostly interested in these types of solutions when I'm on unknown and untrusted networks. They also help control what apps can access the network if I need to tether to my iPhone. DOn't want to chew up bandwidth unnecessarily. :)
There was a problem with the code signature that was fixed in Malwarebytes for Mac version 3.0.2. However, just in the last couple days, we've seen a handful of people with a similar problem. Can you verify if you're using version 3.0.1, or a newer version? If you're not sure, open the Malwarebytes app and choose About Malwarebytes from the Malwarebytes menu.
795a8134c1