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.
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.
This is solvable to some degree but requires varying degrees of new complexity depending how smooth of a user experience you’re aiming for.
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]
[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
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.
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.
Use a filtering proxy instead and no gateway / route to the internet.
2) You're advising security through obscurity instead of a network namespace + firewall.
or DNS stubs with filtering capabilities.
Where LittleSnitch is definitely ahead is showing process connections over time after said process has been allowed.
As software should be.
I think it's fair to ask that a developer choosing to build a thing that requires that kind of access should be expected to err on the side of transparency.
https://github.com/evilsocket/opensnitch?tab=readme-ov-file#...
If users consider this software important they should donate so they can keep using it.
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
> 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.
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!
Anything new to get much better performance from low-spec machines that is idiot-proof is a game-changer.
Congrats to Objective Development for expanding their well-loved tool to a new platform. You guys rock.
Why does LittleSnitch (Mac) pre-resolve IP addresses, before user presses Accept/Deny?
IMHO DNS queries shouldn't initiate without user input.
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.
I've been telling people about ya'll's DNS leaks for over a decade [3] — 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 discovered above leakage so stopped using entirely [v3 user 33TEWP20B0-724KY-5XE522FEAC [2]]
[2] Go ahead and blacklist/cancel the above registration (it's a manyyearsold version, barely used) – my current mailing address is in my user profile (no longer use email/phone). Would love to help/feedback to make your product better. Would also love a refund (all these years later, on principle)
[3] e.g: <https://news.ycombinator.com/item?id=35363343> (/hn/2023)
Please see my response to OD [I presume /u/littlesnitch is OD representative]. Nobody is disputing their "greatness" — I'm just criticizing a flaw in their approach to domain name filtering.
Hopefully OD will refund my original license (unused for many many many years, after I discovered this flaw). That would be good, in principle; good business. Hopefully OD will be more forthcoming in this vulnerability (or better disclose it) — or better yet: fix the unbelievable behavior.
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.
If you or I guess anyone is curious sereno[hyphen]alpha[dot]ramble[thenumberoftechn9ne'sfavoriterum]@passinbox.com