Recent political events have pushed governments and organizations to seriously question their dependence on foreign-controlled software. The core issue is simple and uncomfortable: through automatic updates, a vendor can run any code, with any privileges, on your machine, at any time. Most people know this, but prefer not to think about it. Linux is the obvious candidate for reducing that dependency: no single company controls it, no single country owns it. So I decided to explore it myself.

I installed it on some older hardware we had around. Then installed apps. It turned out that I don’t need a lot: browser, mailer, text editor, development environment, git client, Signal, Wireshark and a couple of others. I can’t do Mac development on Linux, but that was to be expected.

Very soon after that, I felt kind of naked: being used to Little Snitch, it’s a strange feeling to have no idea what connections your computer is making. 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.

Little Snitch was clearly missing, so I started building it.

To make a long story short: I decided to use eBPF for traffic interception at kernel level. It’s high performance and much more portable than kernel extensions. The main application code is in Rust, a language I’ve wanted to explore for quite a while. And the user interface was built as a web application. That last choice might seem odd for a privacy tool, but it means you can monitor a remote Linux server’s network connections from any device, including your Mac. Want to know what Nextcloud, Home Assistant, or Zammad are actually connecting to? Use Little Snitch on the server.

Like an Old Friend on New Hardware

Now, having a variant of Little Snitch on Linux, how does it feel? Is Linux better than a Mac in terms of privacy?

There are two questions to answer: one is about the system itself, the other about the apps you install.

A Surprisingly Quiet System

I noticed a difference already during development: when testing on macOS, it takes at most 5 seconds before a process communicates and I see network traffic. When testing on Linux, on the other hand, it often takes a minute or more until I can spot a connection. It all depends on the Linux distribution you install, of course. I used Ubuntu just because it’s so widespread, and as a developer, it’s a good idea to use the same setup as your users.

Ubuntu is relatively calm on the network, but still sends feedback to Canonical via a declared metrics channel (ubuntu-insights connecting to metrics.ubuntu.com) and various software update channels. You can deny the metrics, but you won’t want to disable updates — and there’s the familiar problem again. You have traded dependence on one company for another. The difference with Linux is that you can choose: there are many distros, and you can choose whom you trust. And as a big organization, you could even maintain your own distribution.

But in summary: on Ubuntu, I found 9 system processes making internet connections over the course of one week. On macOS, we counted more than 100.

Not All Apps Phone Home

The first app installed on every computer is usually the web browser. Only after installing the web browser can you search for software other than the basics provided with your distribution.

My Ubuntu came with Firefox pre-installed, so I can mainly speak to that one. The first thing I did was to start Firefox, but not use it for browsing. To my surprise it immediately showed me ads, and Little Snitch confirmed that it connected to ads.mozilla.org, incoming.telemetry.mozilla.org and many more. Knowing this, I went into the preferences and disabled most of the ads and tracking. But it still connects to some of these servers.

My recommendation: If you use a browser, start it and let it sit unused for at least a day. Then check the connection history and decide what you can disable in the settings, what you want to keep and what you want to deny in Little Snitch.

The next thing I did was web browsing. Needless to say that news sites live from tracking and ads, otherwise they could not provide their content for free. But did you know that some of these sites use somewhere between 50 and 100 trackers? I don’t want to blame anyone here, so try it yourself.

As far as other apps are concerned: each app behaves more or less the same way on all supported platforms. If you install Thunderbird, Visual Studio Code or any other major player, expect the same kind of metrics you see on other platforms. I found one notable exception, though: LibreOffice. I started LibreOffice Writer just for testing, and it made no network connections at all! Quite unusual these days!

Free, Functional, and Open Where it Counts

From a feature perspective, Little Snitch for Linux sits somewhere between Little Snitch Mini and the full Little Snitch: functional and useful, but without all the polish and depth of the macOS version. Think of it as an honest first version. The Mac version remains where our deepest work lives, and that isn’t changing.

The kernel component, written for eBPF, is open source and you can look at how it’s implemented, fix bugs yourself, or adapt it to different kernel versions. The UI is also open source under GPL v2, feel free to make improvements. The backend, which manages rules, block lists, and the hierarchical connection view, is free to use but not open source. That part carries more than twenty years of Little Snitch experience, and the algorithms and concepts in it are something we’d like to keep closed for the time being.

One important note: unlike the macOS version, Little Snitch for Linux is not a security tool. eBPF provides limited resources, so it’s always possible to get around the firewall for instance by flooding tables. Its focus is privacy: showing you what’s going on, and where needed, blocking connections from legitimate software that isn’t actively trying to evade it.

And finally a word on compatibility: we developed on Ubuntu 25.10 with a 6.17 kernel, and have confirmed it works on kernel 6.12 and above. On older kernels we currently hit the eBPF verifier’s maximum instruction limit. In theory, compatibility down to kernel 5.17, where bpf_loop() was introduced, should be achievable, which would cover Debian 12 (Bookworm) and Ubuntu 24.04 LTS (Noble). If you have the expertise to help, that’s one of the areas where contributions would make a real difference.

You can find Little Snitch for Linux here. It is free, and it will stay that way.

Enjoy it.

There’s a lot not to like about the new “every menu item needs an icon” feature in macOS Tahoe.

• They add visual noise to the menus.
• They make menus more inefficient to scan.
• They often result in an inconsistent alignment of menu item titles.
• They are too small, and often blurry and hard to decipher.
• They are often inconsistent (different icons used for the same action).
• They are often ambiguous (the same icon used for different actions).
• Some menu items still don’t have icons, leaving weird gaps among other items that do have icons.
• And finally, nobody asked for them…

The Good News

There seems to be an undocumented, hidden user default that lets you turn them off:

defaults write -g NSMenuEnableActionImages -bool false

The Bad News

This works for many, but not all apps. Especially in many of Apple’s standard apps like Mail, Safari, Messages, Maps or Calendar you still get your menus cluttered with some (or many) of these icons – not all of them disappear.

But it does work in many other apps like Finder, Photos, Numbers, Preview, Xcode and in most third-party apps. So if you don’t like the icons, this is still way better than nothing.

LaunchBar Action

If you are using LaunchBar and want to experiment with this hidden system setting a little bit, here’s a convenient LaunchBar action for turning it on and off:

→ Download the Toggle Menu Icons action

Who doesn’t love a sequel to a good story? Hollywood has taught us that every blockbuster deserves at least one follow-up, and macOS won’t disappoint either.

Back in our pilot Deletion Impossible, you learned about a bug in macOS 15.3 where dragging an app to the Trash did not reliably uninstall its system extension. Despite macOS promising to “remove the associated system extension,” the extension often stayed behind.

With macOS 26 Tahoe, this problem has reappeared. Once again, moving an app to the Trash does not always remove its embedded system extension, even though the system dialog claims it will. The result: a system extension still running on your Mac long after you thought you had uninstalled the app.

What actually happens

• When you delete an app bundle that contains a system extension, macOS shows a dialog saying it will remove the extension.
• In many cases, this process fails silently on macOS 26. The extension remains registered in the system.
• Users then encounter confusing situations: the app is gone, but its system extension still loads or appears in System Settings.

How to check

You can confirm whether an extension is still present by opening a Terminal window and running the following command:

systemextensionsctl list

This lists all installed system extensions. If the extension from your deleted app still appears with [activated enabled], it hasn’t been removed.

How to remove it manually

1. Open System Settings.
2. Go to General > Login Items & Extensions.
3. Scroll down to the Extensions section.
4. Switch from “By App” to “By Category”.
5. Click the i icon next to “Network Extensions”.
6. Click the action icon (three dots) and choose “Delete Extension” from the menu.

Final episode, hopefully

We’ve already reported this bug to Apple, so there’s a good chance we’ll see a fix soon, in one of the next OS updates. Fingers crossed this stays a short two-episode miniseries with no further sequel…

But over time, this list can grow long. And then the question arises: Which of these connections are actually new? These are the ones you haven’t seen before – and therefore haven’t yet had the chance to decide whether you’re okay with them or would rather block them.

The Solution: “First Contact”

That’s exactly where the new “First Contact” feature of Little Snitch Mini 1.8 comes in. It helps you spot new connections without having to remember what was already there.

The “First Contact” list only shows you network connections that you haven’t seen before – such as those from newly installed apps, or first-time connections to domains by apps you’ve been using for a while.

Once you’ve reviewed the list, you can mark it as “seen” with a single click. From that point on, Little Snitch Mini will remember which connections you’ve already looked at – and the next time you open the “First Contact” view, you’ll only see those that are truly new since your last review.

This gives you a focused, clutter-free overview of what’s been added recently – and lets you take immediate action to block new, unwanted connections.

Access via the Time Filter Menu

You’ll find the new “First Contact” list in the time filter menu, where you can usually choose between time ranges like “Last Hour”, “Last Week”, or “All”. The new “First Contact” option fits right in – and provides a smart way to keep track of fresh, previously unseen activity.

A Simple Habit That Pays Off

If you care about your privacy and want to stay informed about what your apps are doing online, it’s a good idea to check the “First Contact” list from time to time. It shows you what’s new – and gives you the power to take action right from the start.

With this new feature, Little Snitch Mini becomes even more helpful – while remaining just as simple and user-friendly as ever.

As much as we would like all software to be bug-free, it isn’t. But the least we can do as software developers, if we discover a bug in one of our apps, is to fix it as soon as possible and let users know that a new, fixed version is available.

To make this process work, it has become a de facto standard for software these days to automatically check at regular intervals if a newer version became available. So even if there’s a bug—no big deal, users will learn about the fix in a timely manner as soon as it’s released.

Or will they?

They won’t, if the bug affects that very automatic software update check itself. And that’s exactly what happened to us with our 6.2.1 release of Little Snitch.

Shortly after the release we noticed that a newer internal developer build wasn’t being announced on one of our test machines. After some investigation, we realized that there was indeed a bug that prevented the automatic update check from being performed under certain circumstances. We were able to quickly identify the cause of the problem, fix it, and release a fixed version 6.2.2.

But now we had—and still have—a problem. Exactly those users who are affected by this bug will never know that it has been fixed, nor will they learn about future updates—unless they manually check for updates in the meantime, in the worst case maybe only after a year or later, when they start wondering why there hasn’t been an update for such a long time.

That’s a rather unfortunate situation. For now we can only try to spread the word about this issue, hoping that sooner or later all affected users will somehow become aware that a newer version is available.

But this experience made us realize just how critical this particular component of our software actually is. Like so often in life, where you realize the value and the importance of a thing only when it’s gone.

Back in 2020, when Apple introduced the new Network Extension framework as a mandatory replacement for the previous, kernel extension based NKE interface, third-party firewall products were required to use it for being able to monitor and intercept all kinds of network traffic. However, we quickly realized that the new framework only worked for TCP/UDP-based connections, but not for packets transmitted using the ICMP protocol, which is used for example by the ping command line tool.

So we reported our concerns about this to Apple, arguing that a firewall should never have any holes or backdoors, but that it should be expected to reliably cover all types of network traffic.

And thankfully, they agreed and added ICMP support to the Network Extension framework.

Now, five years later, after upgrading our machines to macOS 15.3, we have once again noticed that ICMP traffic no longer reaches our network extension, so we cannot show it in Network Monitor nor can we intercept and block it.

And as always, this bug not only affects Little Snitch but also any other third-party macOS firewall that uses the Network Content Filter API (which is the only way to perform such kind of filtering on macOS).

We very much hope that ICMP support was not intentionally removed by Apple, but that this is merely “just another bug” that will be fixed in a future macOS update.

Of course, we have already reported our findings to Apple (FB16450831). If you agree that this should be fixed, you may also submit a report, referencing our existing feedback.

Update: This bug has been fixed in macOS 15.4.

Credits: Image by clipground.com licensed under CC BY 4.0

Good news first: In macOS 15.3, Apple has fixed some bugs introduced in 15.2 that affected Little Snitch users (such as AirPlay not working when used alongside the built-in firewall of macOS)! Or, perhaps more accurately, they’ve replaced them with new ones…

Applications hosting system extensions

Certain applications that provide functionality at the operating system level (such as Little Snitch) ship with an embedded system extension.

Because these extensions have elevated privileges to perform their tasks, both their installation and removal are subject to special security requirements managed by the operating system.

For example, these extensions are installed in a dedicated area of the file system protected from unauthorized modifications by SIP. Consequently, removing such software is more involved because you must remove not only the app itself but also its associated extensions.

Whenever you attempt to delete such an application by moving it to the Trash, macOS informs you that this action also affects the system extensions included with the app.

That’s actually quite nice. You don’t have to worry about removing these extensions yourself—your Mac takes care of it automatically and uninstalls all the extra bits. Or does it?

Starting with macOS 15.3, this automatic removal of embedded system extensions no longer works. Although the system still claims to remove them, they remain installed and active, so they continue to run in the background without users even noticing.

Note that this affects not only Little Snitch but also all third-party Mac apps that include a system extension, such as VPN and network filtering apps, endpoint security tools, and hardware drivers.

But wait, there’s more

If the application in question not only includes a system extension but also happens to be protected against unauthorized deletion by root ownership of its application bundle (as is the case with Little Snitch), there’s another problem.

Usually, when you attempt to delete an app that you don’t own, Finder presents a password dialog where you can authenticate as an administrator to authorize the deletion.

However, starting with macOS 15.3, this dialog is no longer shown when this app also hosts a system extension that’s currently installed. Instead, you just get this vague error message:

What to do?

Well, waiting for Apple to fix these bugs is probably not an option if you want to uninstall the app right away.

However, you can manually delete the installed system extension(s) prior to moving the app to the Trash.

To do this, follow these steps:

1. Open System Settings.
2. Select General > Login Items & Extensions.
3. Scroll down to the Extensions section.
4. Click the i icon next to “Network Extensions”.
5. Click the action icon (three dots) and choose “Delete Extension” from the menu.

If you also have the Endpoint Security extension installed, delete this extension as well by clicking the i icon next to “Endpoint Security Extensions” and deleting the extension there.

Now you should be able to move the app to the Trash, without even being prompted about the embedded extensions anymore.

Alternatives

Instead of deleting Little Snitch, you might, of course, also consider keeping it installed and letting it continue to protect your privacy. 😉

Apple has recently shown a noticeable tendency to collect, gather, transmit, and sometimes even store privacy-sensitive data – despite repeatedly emphasizing the importance of protecting such data and ensuring it remains solely on the user’s device.

This is, of course, always accompanied by assurances that it is done in an anonymized manner that prevents any connection to an individual. However, this increasingly occurs without users being asked in advance for their consent to this data transmission and storage.

While Apple usually provides the option to disable these features, they are often enabled by default.

Aside from the recently much-discussed Enhanced Visual Search functionality, which analyzes image content from personal photos and matches it against an Apple database, macOS Sequoia introduces another new feature labelled Help Apple Improve Search, which sends and stores various search queries from Safari, Spotlight, and other sources to improve search results.

This feature, too, is enabled by default and is well hidden at the very bottom of System Settings > Spotlight.

Apple describes it as follows:
“Help improve Search by allowing Apple to store your Safari, Siri, Spotlight, Lookup, and #images search queries. The information collected is stored in a way that does not identify you and is used to improve search results.”

For more details, users can click on About Search & Privacy, which makes for an interesting read. It describes in detail what kind of data Apple collects, including:

• Your location
• Your topics of interest (e.g., cooking or basketball)
• Your search queries, including visual search queries
• Contextual information related to your search queries
• Suggestions you have selected
• Apps you use
• Related device usage data
• The names and types of music or video services you subscribe to

Apple explains:
“Information sent to Apple related to your searches is used to process your request and to develop and improve search results, such as by using your search queries to fine-tune Search models. It is not linked to your Apple Account or email address.”

Even if the data sent is not directly linked to me as a person, the data itself may contain information I might not want to share with third parties. For example, if I intentionally or accidentally type one of my passwords into Spotlight, do I really want Apple to use that to train its search models, potentially spitting out that password in a future suggestion?

And even if the feature can be turned off – if users don’t even know that it exists or where to find it because it was quietly added in a system update, they cannot decide whether to use it or disable it.

It’s worth noting that the new option in System Settings only governs the storage of this data, not its transmission to Apple. If Include Safari Suggestions is enabled in Safari Settings > Search, inputs into the search field are still sent to Apple for providing suggestions. To prevent this, Include Safari Suggestions must also be disabled.

Additionally, users of Little Snitch can block connections from parsecd and parsec-fbf to apple.com. These daemon processes handle the transmission of search and analytics data for Spotlight Suggestions, Safari Suggestions, Siri Suggestions, and more.

Is it normal for the Little Snitch Network Extension to consume Gigabytes of memory? No it isn’t.

Unfortunately that’s another new bug in the Network Extension framework of macOS. It’s a memory leak in Apple’s framework, which developers must use to create a firewall for the Mac. This bug first occurred in macOS 15.0 Sequoia.

You can easily check if you are affected by this bug by running the leaks command in a Terminal window:

sudo leaks at.obdev.littlesnitch.networkextension | grep "total leaked bytes"

On macOS 14 Sonoma you may get a hand full of leaks with a total of a few Kilobytes. That’s OK (sort of). But on macOS 15 Sequoia this can easily grow to hundreds of Megabytes and more.

Once again, we rely on Apple to fix this issue in a macOS update.

This bug has already been reported to Apple (FB15552991), but if you are affected by this bug, feel free to send another report via Feedback Assistant (mentioning the existing report FB15552991). This might help Apple to find the cause of the issue and it increases the chance that Apple will prioritize the fix.

For the time being, if you encounter an unreasonably huge memory consumption, you may enforce a restart of the Network Extension. To do so, open the Activity Monitor app in Applications > Utilities, search for the at.obdev.littlesnitch.networkextension process (make sure that All Processes is selected in the View menu) and click the Stop button in the toolbar to quit the process. The extension will then restart automatically.

While one of the issues related to DNS lookups has been fixed in macOS 15.1, a new, even more serious one was introduced.

As a consequence of this new bug it can happen that Little Snitch doesn’t receive any network traffic information from Apple’s framework, hence no traffic is then shown in Network Monitor, no connection alerts are shown, and firewall rules for blocking connections are not applied.

For the time being, until Apple fixes this serious bug in macOS, we therefore highly recommend to turn off the built-in firewall of macOS when also using Little Snitch or Little Snitch Mini.

It’s worth mentioning that the Little Snitch firewall also works for incoming connections, providing the same functionality as the macOS firewall (except for stealth mode), so it’s usually not necessary to have them both running simultaneously anyway.

This issue has been reported to Apple (FB15699871) and we hope that they will resolve this problem with an update soon.

If you are affected by this bug, feel free to send another report via Feedback Assistant (mentioning the existing report FB15699871). This increases the chance that Apple will prioritize the fix.

• While our apps do process data that could provide insights into user behavior, this data is processed exclusively on-device and is never transmitted over the Internet.
• Our apps process data solely for the benefit of the user. No benefit to Objective Development or third parties is ever pursued.
• We operate under the assumption that our customers comply with the law and we do not see it as our responsibility to detect or report criminal activity to any authorities.

We believe other software vendors should make similar declarations, clearly stating what their apps may do. While the GDPR mandates transparency, it is evidently not sufficient. Even security experts failed to notice that their antivirus software had installed a rootkit to monitor their activity.

What was fixed?

There were two major concerns with the 15.0 version which affected Little Snitch as well as other third-party firewalls:

1. ssh connections failing or aborting due to corrupted data in the TCP stream.
2. Apple’s built-in firewall preventing DNS lookups of computer names.

The good news: According to our tests, the issue with the built-in firewall appears to be fixed.

However, the ssh issue was never consistently reproducible. For some users, it happened every time, for others, only sporadically. Most users were not affected at all. Since no one on our team experienced the issue firsthand, we lack direct experience with it. Recent user feedback indicates a shift of the situation: users who consistently encountered the problem no longer report it, while others, who were previously unaffected, are now experiencing ssh connections dropping after some time. We don't yet have sufficient data to determine whether this is coincidence or if the bug persists.

Are there new bugs?

We have received several reports from users of Little Snitch and Little Snitch Mini where the network content filter became inactive in the course of installing the macOS update. You’ll notice that you are affected if the Network Monitor stops displaying traffic or if connection blocking no longer works.

Fortunately, there appears to be a simple workaround. Open System Settings > Network > VPN & Filters and check the Filters & Proxies section. Little Snitch should be enabled and marked with a green dot. However, if the content filter is inactive, it will display a yellow or red dot:

In that case, select the inactive content filter and click the Minus-button at the bottom to remove it. Then open Little Snitch or Little Snitch Mini and re-enable the network filter. It should then be up and running again.

Conclusion

In summary: If you have already upgraded to Sequoia, we recommend installing the 15.0.1 bugfix release. If you’re still on Sonoma, it’s a trade-off between accessing new features and maintaining system stability. We don’t have a definitive recommendation — it depends on your personal preferences.

In any event, check the Filters & Proxies section in System Settings after the upgrade to ensure that your network content filters are still active.

If you have already upgraded or if you want to upgrade for other reasons, here is a list of issues related to Little Snitch or networking in general:

Data corruption in TCP connections

As far as we can tell, this bug is rare and primarily affects ssh connections. Users report various protocol violation errors from ssh and that they are no longer able to connect to servers when a network extension (any network extension) is active.

The error messages are either “Connection corrupted” or complaints about wrong key size. We experienced that problem only once, but in a more severe way: A file transferred via ssh arrived corrupted.

There are individual reports of websites aborting loading midway. We believe this is a general problem with TCP connections, not only ssh, but ssh seems to trigger it most frequently.

Apple’s built-in App Firewall blocks DNS lookups and Firefox

This bug is not related to Little Snitch, but since it’s a firewall topic, we include it here. If you have configured Apple’s firewall to block incoming connections, it blocks all incoming UDP packets, even if they are responses to requests, e.g. responses to DNS name lookups.

macOS performs name lookups in different ways, depending on the programming interface used by the process. Safari and Chrome will still work when blocking incoming connections, but Firefox will not.

On Sequoia 15.0, we recommend that you disable Apple’s firewall until the problem is fixed.

If you still use Little Snitch 5

Our previous major version, Little Snitch 5, is not yet fully compatible with Sequoia. This is not a bug in Sequoia, but a last-minute change shortly before the final release: Little Snitch up to version 5.7.6 no longer has access to the name of the current Wi-Fi network. This breaks Automatic Profile Switching on network change. We will release version 5.8 soon which fixes the problem. Little Snitch 6.1.1 already contains this fix.

What was the problem with Little Snitch 6.1?

Soon after releasing version 6.1 (which brought compatibility with Sequoia), we noticed that DNS name lookups were leaving the machine unencrypted although Little Snitch was configured to encrypt DNS traffic. An analysis showed that some of the lookups were not sent to our DNS proxy network extension, but rather left the machine directly. We therefore suspected another macOS bug.

We were a bit concerned because such a code path existed at all: There are conditions under which the system can bypass a configured DNS proxy.

However, it turned out that this code path is necessary. If the DNS proxy network extension just wants to forward a lookup to a “normal” DNS server, the lookup should not be re-routed back to the DNS proxy again, as that would cause an infinite loop. In fact, we even rely on this behavior for handling configured exceptions from DNS encryption.

But: Why would that code path be taken for lookups done by Firefox? There was another improvement in version 6.1: Server names provided by Apple are sometimes incorrect, often returning a CNAME instead of the actual hostname that was entered by the user. In order to improve this, we used a man-in-the-middle technique between processes and the mDNSResponder daemon, responsible for name lookups. We already used this same technique in previous versions of Little Snitch for many years, before Apple began providing server names via API. Our improvement, however, made mDNSResponder think that all requests originated from our network extension! And therefore it sent them out directly, bypassing the DNS proxy.

In version 6.1.1, we reverted to using the server names provided by Apple's API. Maybe we can come up with an improvement in a future release.

UPDATE: Spoke too soon…

The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It has already been fixed in Little Snitch 6.1.1.

See the end of the article for details.

DNS Encryption 101

When you enter a hostname in your web browser (e.g., apple.com), that name must first be translated into an IP address so your computer can connect to the server. This lookup is usually performed unencrypted, meaning your Internet provider and other parties monitoring your connection can see which sites you visit. To protect these lookups from prying eyes, Little Snitch 6 offers a new feature: DNS encryption. With DNS encryption enabled, all name lookups are routed through Little Snitch and performed in encrypted form.

For this purpose, Little Snitch registers a DNS proxy. macOS then sends all DNS requests to that proxy, which in turn performs the lookup in encrypted form. The key point here is that all requests must be routed through the proxy.

But…

While investigating a DNS-related issue on macOS 15 Sequoia, we discovered that some DNS requests—particularly those made via certain low-level legacy APIs—were not being received by our proxy!

There appears to be a bug in macOS Sequoia causing some requests to bypass the installed DNS proxy and be sent unencrypted to the system’s default name server instead.

Note that this bug likely affects any kind of DNS proxy, not just Little Snitch.

So, if you rely on the new DNS encryption feature of Little Snitch 6, or if you are using another third-party DNS proxy, be aware that some DNS lookups may bypass the proxy until Apple provides a fix in a future macOS update.

Note: DNS lookups performed via higher-level APIs do not appear to be affected by this bug. For example, your web-browsing in Safari or Chrome still fully benefits from encrypted lookups. Firefox, on the other hand, does seem to be affected.

How to Reproduce

1. Enable DNS encryption in Little Snitch > Settings.
2. Start Wireshark with a capture filter for port 53.
3. Run the following code in an Xcode playground:

import Foundation

let domain = "dnsproxytest.com"
var result: UnsafeMutablePointer<addrinfo>?
let status = getaddrinfo(domain, nil, nil, & result)

You will notice that the lookup for dnsproxytest.com can be seen in Wireshark in unencrypted form on UDP port 53 (the default for unencrypted lookups).

Additionally, you will see that Little Snitch Network Monitor does not display any traffic for the lookup because the lookup completely bypasses the network filter!

We have reported this bug to Apple and hope for a fix soon. Please stay tuned, we will keep you updated here.

Update 2024-09-17, 19:10

After further investigation, we found that this bug has already existed at least since macOS 14.5 Sonoma (maybe even earlier, but we currently don’t have access to an older 14.x system for testing).

Update 2024-09-18, 12:05

After further investigation, we found that this bug only affects the DNS proxy of Little Snitch 6.1. It’s not a general problem of DNS proxies in macOS. We will therefore be able to fix this issue at our end and provide an updated version of Little Snitch 6 later today.

Update 2024-09-18, 15:52

The issue has been fixed in Little Snitch 6.1.1.

How effective are blocklists actually? Let’s find out!

Blocklists are a fine thing. With just a few mouse clicks they are set up and immediately they effectively protect against unwanted Internet connections to tracking servers, advertising servers and malware sites.

From then on, they perform their duties quietly and unnoticed in the background. But sometimes it would be quite exciting to also watch them at work.

This was already possible with Little Snitch Mini. The red flashing in the menu bar icon or in the connection list serves as an indication that one of these unpleasant connection attempts has just been detected and prevented.

With Little Snitch Mini 1.3 there is now another exciting possibility to get a closer look at your blocklists: The blocklist statistics!

A counter is now displayed for each blocklist entry, indicating how often the entry in question has already been effective:

And a new filter option in the search field allows you to see only those entries that have been effective at least once:

The filtered view is sorted by frequency. So you can easily find the most often used entries at the top of the list.

Does “unused” mean “useless”?

With some blocklists, it is possible that even after months of use, not a single entry appears as used.

However, this should not lead you to the false assumption that this list is unnecessary and might therefore be removed.

If and how often a list takes effect depends a lot on what that list specializes in. Lists that specialize in tracking servers will potentially hit frequently, because user tracking for advertising purposes is a widespread evil.

On the other hand, lists that protect against malware servers should, in the best case, never take effect. Otherwise, this would be an indication that you were actually affected by a connection attempt to one of these potentially dangerous servers, but fortunately it was successfully detected and prevented by the blocklist.

You can compare this to the lock on your front door. Just because there are no traces of an attempted break-in on the door does not mean that you should remove the lock.

So enjoy using blocklists with Little Snitch Mini and see how often they take action for you!