Appleidauthagent Little Snitch
- Little Snitch 10.14
- Appleidauthagent Little Snitch Game
- Appleidauthagent Little Snitch 2
- Appleidauthagent Little Snitch Movie
0:17.29 /Library/Little Snitch/Little Snitch Daemon.bundle/Contents/MacOS/Little Snitch Daemon. /traktor-pro-for-imac.html. What is little snitch app.
Little Snitch’s default behavior is to show you Connection Alerts—messages letting you know apps are attempting to connect to the Internet—and to ask if you want that app to send out data from your. Jun 13, 2016 Ultimately I used Little Snitch to block all incoming Apple pings and every 'phone home' to Apple. That helped, but what I consider Apple bloatware was frustrated by inability to connect. OS X, for example, found another path (radar.submissions) to try to report I had disabled Spotlight. The AppleIDAuthAgent process on my 2007 Mac Pro running OS X 10.7.5 is taking up 95-100% CPU continuously. I use it whenever I go to work. I also use it as a server. I occasionally pull/push using git and to access it via SSH and remote desktop from home or elsewhere. It's behind a major university firewall and has fairly high security settings.
Ever wonder what all those system processes are doing? So did I..- Jan 18, 2015 I have 'Little Snitch' installed on my MBA which alerts me every time any process connects to the outside world. Since upgrading to Yosemite the number of alerts have increased 3 to 4 fold. Since learning from your website problems with.
- Jun 13, 2016 Decrease the number of Little Snitch alerts like 'gamed wants to connect to static.gc.apple' by disabling services you don't need in Mac OS X. If you run Little Snitch on a Mac you are likely to get frequent alerts about connections from the 'gamed' process. The full alert.
I recently picked up Little Snitch and I've had a fun time watching all the traffic that one little MacBook can send! I wasn't satisfied to just filter my user-level programs -- why should I trust a system process when it could be hijacked just like any user process? (For example, see this mDNSResponder vulnerability from June of this year that allows for arbitrary code execution. Yikes!)
So, I decided I would actually bother to investigate what all those different system-owned processes and daemons did. I've had some adventures selectively enabling and disabling services with launchctl, running processes through dtruss, Wireshark, and other tracing tools, and occasionally breaking my computer along the way. Here's what I've found on some of the processes you might have noticed if you ever disabled the protected rules:
AirPlayXPCHelper - Background on XPCs: An XPC is user-level service (like a daemon) that runs in the background and helps apps accomplish some goal. Apple recommends using XPCs for fault-tolerance: if you have some component in your application that is likely to crash, throw it in an XPC so that even if it crashes, the main user-facing program won't, and can simply restart the XPC service. (Aside: this seems like Apple is saying 'got buggy code? Don't fix it, just throw it in an XPC!' which sounds pretty awful but whatever, that's not what we're here for). Furthermore, every individual XPC service is sandboxed so it can't affect other processes.
AirPlayXPCHelper obviously helps with AirPlay. However, my AirPlayXPCHelper tried to connect to something on port 7000. Since port 7000 isn't listed as an AirPlay port on Apple's list of ports used by Apple products, I blocked it. Haven't had any issues so far.
AppleIDAuthAgent - As the note on the protected rule states, 'AppleIDAuthAgent is used to check whether Apple-ID certificates are valid.' I recommend letting this one connect to Apple (and Apple only) at least periodically to keep the system happy. I've blocked it at times, and the OS seems to accept not being able to verify the user's identity sometimes.
apsd - From the protected rule notes: 'Part of Apple’s PushService framework.' Turn it on when you want push notifications from Apple, block it otherwise. Note that apsd is responsible for sending and receiving iMessages and texts in Messages, so if you use that then you'll want to allow it access to the push.apple.com domain.
assistantd - This is Siri, and other voice control stuff. I blocked it unconditionally since I don't use the feature, and I'd rather my MacBook not be always listening to everything. You can use launchctl to disable the service permanently if you want; you can find it at /System/Library/LaunchAgents/com.apple.assistantd.plist.
automount - This tool mounts drives of all kinds, including network drives. If you don't need to mount network drives, you're good to block this one. (But don't disable it in your OS! Otherwise all kinds of stuff may not mount properly)
cloudd - A daemon related to iCloud. I allowed it to connect specifically to iCloud servers while on my home network, and blocked it elsewhere. Depends how accessible you need your iCloud to be. (Never use iCloud? block away!)
com.apple.geod.xpc - Another XPC, this one's name can be read 'Geo-D', short for 'geolocation daemon'. If you're paranoid about being tracked by The Man, block this one unconditionally. I let it connect to Apple, because I suspect it's used by Find My Mac, and I'm more worried about my laptop being stolen than my location being tracked by the fed.
configd - This one controls a host of mostly network-related tasks, but also some other stuff. Use 'man configd' in the terminal to take a look at its manual. If you block it, you won't be able to connect to WiFi hotspots, or at least not always or very well. So we have to allow some traffic, but we can restrict it pretty hard: on most networks, it's sufficient to only allow incoming UDP on ports 67 and 68, and outgoing UDP on the local network.
findmydeviced - As with com.apple.geod.xpc, this one comes down to whether you'd prefer to find your stolen property, or not let Apple and other APTs know your location.
gamed - This is the daemon for the Games Center. If you never use the Games Center (I don't), then you can not only block this one, but also disable it using launchctl. When blocked, it retries every second, which can be annoying, so disabling it is a nice fix.
helpd - This daemon fetches content provided through the 'Help' drop-down menu of most applications. It will try to connect mostly to Apple, but also occasionally to help resources on other domains (e.g. SourceForge) for non-Apple applications. If you never use 'Help', you can probably block this one entirely. I let it connect to Apple and no-one else.
ksfetch - This is an updater daemon for Google products, notably Chrome. There's also a Google Software Update app installed within Google Chrome.app, so I'm not sure why Google needs an updater app AND an updater daemon. I have it blocked currently, but maybe I shouldn't.
launchd - This is a service dispatcher (like inetd on Linux) that launches other services. It is sufficient to only allow incoming connections; launchd just listens and launches other daemons to hand off the incoming data to. I don't recommend turning it entirely off, since it will break some stuff, but (in my experience) you can limit it to the local network without issue, unless you're running a webserver or something.
mDNSResponder - This one's been a big headache for me. It originally only did Bonjour (Apple's 'zeroconf networking' solution, allowing devices to find each other automatically on the local network), but as of MacOS 10.6 it took on a bunch of regular DNS tasks as well. I discovered this when I disabled it entirely and found that it broke a bunch of stuff. I'm still working on a good profile for it, but for now I have it very selectively filtered: it can access a few DNS servers I trust on port 53 (DNS), and port 5353 (the Bonjour/mDNS port) only on my local network. It's otherwise blocked off, and this seems to work alright for now. Your mileage may vary. If you have a decent filter for mDNSResponder, I'd love to hear about it.
mount_nfs and mount_url - Just like automount, if you don't have any network drives to access, you can safely block these entirely. Note that these two can mount internet filesystems in addition to local ones.
netbiosd - NetBIOS is a super-old local network drive-sharing protocol. If you don't have any network drives on your local network to access, you can block this one too.
nsurlsessiond - I'm guessing that the 'ns' at the beginning of this one's name refers to 'NeXtStep' and not 'namespace', which indicates to me that this is probably pretty old tech. I don't know all the things it's used for, but it is used at least to sync data from iCloud. Others are finding it's also responsible for leaking your data to Apple and Microsoft in the built-in Spotlight and Bing searches (if you haven't already, turn off Spotlight Suggestions and Bing Search from the Spotlight settings so that your keystrokes aren't all sent over the wire whenever you search for a local file). I've got it locked down to only call out to iCloud servers, and that seems to work well.
ntpd and sntp - These little daemons keep your system clock in sync with Apple's clocks. I'm not sure why the OS needs two of them (looking into this is on my to-do list). Blocking them does little harm, but I suggest instead just locking them down to only be able to connect to Apple's servers.
ocspd - This daemon is used by the system to check X.509 certs. I've got it blocked when I'm outside of my own home for now, and that doesn't seem to be a problem. I assume it might be a problem if I try to install any new software while it's blocked.
storeaccountd and storeassetd - So far I've only ever seen these two call out to iTunes-related domains. I assume they do 'what it says on the tin,' grabbing resources for the Store. I've got them blocked everywhere, and I disable the rule when I need to use the Apple Store or iTunes Store. Streaming music in iTunes through Apple Music doesn't seem to be affected by them being blocked, so I'm guessing it's only for actual Store stuff.
syncdefaultsd
Little Snitch 10.14
- Yet another iCloud-related thing, this guy keeps various preferences sync'd between Apple devices and such. You can probably block it, at least outside of your home network.trustd - Like ocspd, this one verifies certificates. I haven't seen much traffic from it, and I have it blocked everywhere that isn't my own home, which seems to work fine.