Question for devs, not me.

Did the "attention to detail" phrase come from devs or you?

From me. OD is a great dev firm. Do you understand my statement?

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?

>OD is a great dev firm

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.

Are you blaming me for promoting software that I didn't write?

No, I'm pointing out (against your initial claim) that OD's attention to detail might be lacking, here... at least they ought'a disclose the described/known vulnerability.

Instead, /u/LittleSnitch just commented elsewhere "Little Snitch is not a security tool" — interpret accordingly.

Ok, so what was this?

> Did the "attention to detail" phrase come from devs or you?

It sure sounds like you're accusing me of something like being a schill.

Chill, dawg.

That comment wasn't mine.

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.

>in principle we could filter lookups

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)

The eBPF filter in Linux Snitch decides immediately, so no TCP handshake leaks. But, as a consequence, we cannot inspect packet headers to verify the remote name and it's easier to trick it to show a false name. Little Snitch for Linux is not a security tool.

>Little Snitch for Linux is not a security tool.

What is it, then?