Also from [0].
> You can find Little Snitch for Linux here. It is free, and it will stay that way.
Don't worry, the authors know that there's no point in charging Linux users. Unlike Mac users.
So you might as well make it $0 and the (Linux) crowd goes wild that they don't need to pay a cent.
However...
> 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.
OpenSnitch is open source. You don't need to trust it as you can see the code yourself. Little Snitch on the other hand, is completely closed source.
Do you still trust them not to do self-reporting or phoning home, even though it is $0 and closed source?
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.
Yep, I trust the obdev.at / Snitch guys.
I do wonder however, are they sufficiently careful about their processes and own machines to avoid a supply chain attack completely.
They must be a target for the various hacking groups out there.
We have not detected a targeted attack yet. On the Mac side, we are safe: No dependencies on any third party libraries. Only Apple.
On the Linux side, there is no single big vendor such as Apple who provides all the necessary libraries. I have tried to choose reputable sources from crates.io only, but to be honest, I don't know a secure solution to the problem.
This comment seems a bit confused.
A supply chain attack doesn't directly attack an end developer but rather a supplier of the developer. So who or what is the supplier in this case?
They don't build their own machines or write their compilers or write their own crpyto code or ... so many other things.
> They don't build their own machines or write their compilers or write their own crpyto code or ... so many other things.
An attack on any of these things has nothing specifically to do with the developers of Little Snitch and would have vastly more widespread and important effects.
Why would you even be talking about Little Snitch if a compiler were compromised?!? Your paranoia here is bizarrely narrow. Little Snitch would be the least of our problems in that case.
Their copy of the compiler. Just an example. ¯\_(ツ)_/¯
> Their copy of the compiler.
This doesn't even make sense. You have no examples.
That seems... not correct?
The comment was asking about preventing a compromised supplier for the developers.
A supply chain attack can be anywhere in the supply chain to the target. If I, the end user, am the target, then a supply chain attack compromising the developer of LittleSnitch is effective.
I may then be a conduit to compromising other software or components, and would both I and LittleSnitch would be part of the supply chain that could be attacked targeting them.
> If I, the end user, am the target
You're not a target, anonymous rando.
Many supply chain attacks aim to run malware on the end-users machine to harvest authentication tokens, etc. So pretty much everyone here who is a developer is the target.
> So pretty much everyone here who is a developer is the target.
Are you going to have this same discussion about every piece of software every mentioned on Hacker News? Why are we having it for Little Snitch specifically?
This seems pedantic and I think you know what they’re questioning and why.
If they trust the devs why would they not trust them to not yolo deploy new versions?
because a company worthy of trust doesn't yolo their versions. a company that does yolo versions is not trustworthy.
Because it might not be the developers doing the deploying, but a malicious actor?
> I think you know what they’re questioning and why.
No, not really. And I disagree with the premise, "They must be a target for the various hacking groups out there."
How would you even hack them? I'm a developer too; how would you hack me?
Options range from carefully targeted phishing or social engineering attacks to poor opsec and a five dollar wrench.
> a five dollar wrench.
I'm not even going to respond to this ridiculousness.
I still don't know why anyone thinks that, among all developers in the world, a little indie Mac developer is getting targeted specifically.
Some targets are more valuable than others. A firewall product has obvious security value. The fact that it requires high privilege is another reason.
I have the same thoughts about other Mac apps. e.g. iTerm2 - cause they "see" so much sensitive data.
[flagged]
Yeah just yolo install whatever, it’s not like applications or libraries such as axios which have a decade of trusted history would all of a sudden become malicious and do nasty things to developer machines, just chill, everything’s fine.
> Yeah just yolo install whatever
That's not even remotely what I said.
> it’s not like applications or libraries such as axios
iTerm doesn't use NPM. Little Snitch doesn't use NPM. I don't use NPM.
[flagged]
WTF? This is not an acceptable comment on HN, no matter who or what you're replying to. This style of commenting is not what this site is for, and destroys what it is for.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
> I'm not even going to respond to this ridiculousness.
Why is it ridiculous? If you have electronic access to something of value and broadcast that fact on the internet, you’re at risk of a physical attack. That’s not controversial? Companies make employees do training about this for a reason.
> If you have electronic access to something of value and broadcast that fact on the internet, you’re at risk of a physical attack. That’s not controversial? Companies make employees do training about this for a reason.
You're talking as if all all "value" and all "risk" is equal, when they're definitely not. You can't equate a megacorporation with a little indie developer. Nobody cares about the latter.
I am a software developer, and I broadcast that fact on the internet. But nobody is coming to Wisconsin to hit me on the head with a wrench. That's just a silly paranoid fantasy.
If anyone hits me on the head with a wrench, it would be not be a nation-state but rather a two-bit local mugger who has no idea who I am and just wants cash from my wallet. I live in a pretty safe area though.
Nobody that you know of.
The same people who targeted the open source uncommercial library axios *last week*?
Access to little snitch would be worth millions to the right party.
>> I still don't know why anyone thinks that, among all developers in the world, a little indie Mac developer is getting targeted specifically.
> The same people who targeted the open source uncommercial library axios last week?
axios is an NPM package. Little Snitch doesn't use NPM. Thus, these people must be pretty damn incompetent if they were trying to target Little Snitch.
> Access to little snitch would be worth millions to the right party.
This is a bold claim with no evidence. I don't think it's true.
Shell (and probably root) access to tens of thousands of development machines wouldn’t be worth millions to the right party?
?! The same way every other developer that has been hacked. You surely cannot be suggesting you're un-hackable. That seems ludicrously hubristic.
> The same way every other developer that has been hacked.
There's not one single way, so, no, you're just hand-waving here.
Just saying developers have been hacked. Underrated existence proof.
> Just saying developers have been hacked.
So are you going to have this same discussion in every HN submission that mentions any piece of software?
What software do you actually develop? You clearly don’t give a shit about your users and I want to make sure I’m not using your software .