Home
Posted By: artie505 Understanding Little Snitch - 12/04/15 01:27 AM
Comments by Pendragon and slolerner got me wondering about precisely how LS interacts with my other protections.

I've always assumed that even if I authorize a connection in LS it will nonetheless be blocked by either Ghostery or an entry in my hosts file if applicable.

I certainly hope that's correct!

Thanks.

Edit: My assumption is that LS can only allow a tracker to attempt to make a connection that Ghostery or my host file will stop.
Posted By: slolerner Re: Understanding Little Snitch - 12/04/15 01:45 PM
I too have pondered that but it made my head hurt so I tried not to think about it. Such things as Double-Click that Ghostery disabled and I told LS was ok, a lot of Google lead stuff, like, I get more ads on web pages because I don't know which things that pop- up on LS to deny because there are so many Google things it's nuts and if I deny the wrong thing I can hardly browse at all.
Posted By: Virtual1 Re: Understanding Little Snitch - 12/04/15 01:47 PM
Without inside knowledge of both apps (which I lack) I can only speculate.

Apps that modify default behaviors generally "hook" the system. As an example, lets say you have software that blocks urls to adult web sites. There's a jump table the system uses to store the location of the DNS resolving program. When something wants to resolve a url, they call the routine at that location.

Your software would copy the address at that location, and then replace it with YOUR address. So when someone looks up a domain, they ask you instead of the DNS software. Your software can look at the request and decide whether to return an error code, or to forward it to the DNS software. This process goes by a few names, but "hooking" is common. It's also possible your software may return a bogus or different URL instead of returning an error or passing the call to the DNS routine. That would be an "override" of sorts, and your participation would be invisible to the caller.

It's possible for more than one piece of software to hook a call. Then it starts coming down to a matter of who hooked first. If my program hooks before yours, and someone makes a DNS request, you'll get called, then you will pass it to me, and I will pass it to the DNS program. (assuming neither of us rejects it)

That would be post-hooking. Hooking can also be done interim. For example, your software might have a url whitelisted, and when someone looks up that domain, your software disables the firewall, calls the DNS, and then re-enables the firewall before returning the DNS's results to the original caller. That'd be an interim hook. Because sometimes you want to take action after the actual call is made. (maybe for logging, for example)

In the case of a service, everyone involved in hooking the service would have to pass it through to allow it to be serviced normally. There'd be no way for one service to override the others. But lets say its more of an approval. Lets say there's a service to simply tell you if something is allowed (like a URL) or not. If you are the last one to hook it, you get first crack at it and can approve it instead of passing it on to the previously assigned routine. (or routines, if it had already been hooked) You hooked it last, you have first crack at it, and its possible that no one else gets a chance to deny it.

And sometimes a service is outright completely replaced. In that case, the hooker may store the previous value before replacing it, but it won't ever call it. It's now in charge of providing the service. Maybe you've customized the GUI sound effects, and there's NO reason for you to be calling the defaults since you replace them. You might keep the original on hand though in case you offer the ability to disable yourself without a reboot, so you can put back the original value.

So generally speaking, either everyone has to allow it, or it's last-hook-wins. (or at least has first crack at it) It really depends on the service.

This makes it difficult to predict how different programs will behave when ran together, and this is why pretty much none of them will support their software if you're also running something else that may be interfering/interacting.

Let me give an example of undefined behavior: lets say you have two pieces of software, one that turns off the firewall for certain URLs, and one that does additional lookups (checks to see if a server is running HTTPS if you make an HTTP request, to let you know you have the option) If the firewall opener hooks last, the order of operations will be (firewall off)(https check)(http check)(firewall on) But if the https checker hooks last, the order is changed to (firewall off)(https check)(firewall on)(firewall off)(http check)(firewall on). If the firewall takes awhile to recover from being turned on, the http check that follows right after getting the firewall turned on and back off may fail for some reason of timing. Note this sort of thing may also lead to performance problems. (if it takes 1 second to toggle the firewall, this request takes either 2 OR 4 seconds depending on hook order) Unpredictable behaviors like this is why vendors don't like dealing with systems running other unknown software.

TL;DR: there's no way of knowing without testing or finding documentation on it
Posted By: slolerner Re: Understanding Little Snitch - 12/04/15 05:53 PM
Originally Posted By: slolerner
I too have pondered that but it made my head hurt so I tried not to think about it.
Thanks, V1
Posted By: artie505 Re: Understanding Little Snitch - 12/05/15 07:42 AM
Thanks for another great explanation of the inner workings of OS X.
Posted By: artie505 Re: Understanding Little Snitch - 12/05/15 07:42 AM
I've e-mailed the question to Little Snitch's developer, and with luck I'll get a definitive answer.
Posted By: artie505 Re: Understanding Little Snitch - 12/07/15 07:41 AM
As a test, I allowed LS to run silent and allow connections, and then, still in the same mode, I tried to visit domains on the resultant connections list and found that Safari was unable to connect with those that I knew should have been blocked...an excellent indicator; other domains showed an endless spinning work wheel and never connected, and others did connect.

In the same mode, I also tried to access domains on my hosts list and was universally unable to connect.

Pending a response from Ob Dev, then, I'm assuming that LS and Ghostery are NOT self-canceling.
Posted By: artie505 Re: Understanding Little Snitch - 12/26/15 10:58 PM
I emailed this question to the developers of Little Snitch and Ghostery:

Quote:
Does Little Snitch respect Ghostery’s settings and block calls out to entities it has blocked, or does it negate Ghostery’s protection?

Further, can I assume that when I run Little Snitch in “Silent Mode/Allow connection attempts” EVERY connection attempt is to an entity NOT blocked by Ghostery, i.e. that connection attempts to entities blocked by Ghostery NEVER get to LS?

I can’t imagine why, but LS’s devs couldn’t be bothered to even acknowledge me, and I gave up after two tries. (Even if there’s an answer somewhere on their website, and I did look, it’s rude!)

Ghostery’s developers, on the other hand, were helpful:

Originally Posted By: Andre Vorobyov (Ghostery)
We are not exactly sure how other programs operate. However, when you choose to block a tracker using the Ghostery extension, the call that's being blocked will not be seen when you look at outbound network calls. Hopefully that helps! (Emphasis added)

Following that lead I realized that disabling LS’s two Safari catch-all rules
  • Allow outgoing TCP connections to port 80 (http) and
  • Allow outgoing TCP connections to port 443 (https)
would result in a pop-up for every connection attempt and might be informative as respects my hosts file, and I was correct.

With those rules disabled, any attempt to connect to a URL listed in my hosts file resulted in a screen similar to this one and a “Local documents on your computer” (which sounds like a reference to the hosts file) cache entry in Safari > Prefs > Privacy > Privacy > Details…but never a Little Snitch pop-up.

So it looks like Ghostery functions side by side with my hosts file, with both suppressing calls out to URLs in their databases before they ever get to LS.
Posted By: artie505 Re: Understanding Little Snitch - 12/31/15 03:08 PM
Final response from Ghostery tech support...

Quote:
Yep, the Ghostery extension blocks the calls before they are able to make an outbound network call.
Posted By: slolerner Re: Understanding Little Snitch - 01/02/16 11:26 PM
Is Disconnect compatible with Ghostery? How is Ad Block Plus different than Ghostery?

I had originally posted this question here:

http://www.finetunedmac.com/forums/ubbth...38069#Post38069

when deniro was discussing his security message from ATT. Deniro is using these. Rather than start a new string, we are discussing 'hooking,' LS, and Ghostery here so I think this is an appropriate place to post this.
© FineTunedMac