https://lapcatsoftware.com/articles/2025/1/6.html Previous: New secure note on macOS Sequoia Articles index Jeff Johnson (My apps, PayPal.Me, Mastodon) Little Snitch feature nobody knows about January 24 2025 Little Snitch by Objective Development is the first app that I install on a new Mac. In fact I just bought a new Mac, an M4 MacBook Pro with nano-texture display, and I installed Little Snitch via thumb drive even before connecting the Mac to the internet. While setting up my new Mac, which came with macOS 15.2 preinstalled, I noticed that Safari attempted to connect to ssl.gstatic.com on launch. That domain is owned by Google! Safari wants to connect to ssl.gstatic.com on TCP port 443 (https) I denied the connection, but it kept happening on every launch, despite the fact that I set Safari to open with a new private window and empty page. Moreover, it happened on every launch of Safari Technology Preview too. In the Little Snitch alert window, I pressed the info button, which revealed that the connection was initiated by Safari Search Helper, a separate process from the main Safari app. Established by /System/Volumes/Preboot/Cryptexes/Incoming/OS/System/ Library/PrivateFrameworks/SafariShared.framework/Versions/A/ XPCServices/com.apple.Safari.SearchHelper.xpc/Contents/MacOS/ com.apple.Safari.SearchHelper Like most web browsers nowadays, Safari launches other processes to perform dedicated tasks. To see this in action, just search for "Safari" in Activity Monitor. The advantage of using separate processes is that each process can have separate privileges, and if one process happens to crash, it doesn't cause the entire app to crash. When an internet connection is initiated by a process launched by an app, Little Snitch attempts to attribute the connection to the main app rather than to the helper process. This attribution usually makes more sense to the Little Snitch user. I haven't figured out exactly why Safari Search Helper connects to ssl.gstatic.com, but it's definitely related to using Google as the search engine in Safari Search Settings. If I change the search engine to DuckDuckGo, for example, the connection attempts no longer occur on launch. Indeed, if I switch the search engine back from DuckDuckGo to Google in Safari Settings popup button, a connection to ssl.gstatic.com occurs immediately. None of the other search engine choices provoke a connection. I decided to permanently deny all connections to ssl.gstatic.com from Safari, because there's no good reason for Safari to silently contact Google when I'm not even searching. Unfortunately, my new Little Snitch rule had an undesirable side effect. Although I'm trying to wean myself off, I still use Gmail, and when you set up Gmail in Mail app, it authenticates your Google account in Safari. However, the authentication kept failing for me. Looking in the Safari web inspector console, it became clear that the problem was some denied ssl.gstatic.com connections. Thus, I was forced to disable my Little Snitch rule and allow Safari to connect to ssl.gstatic.com in order to authenticate Gmail for Mail app. Oddly, the ssl.gstatic.com connections from Safari stopped entirely after I allowed it to connect once. I discovered, comparing Safari preferences before and after, that WBSOfflineSearchSuggestionsModelLastUpdateDateKey had been set. defaults read com.apple.Safari WBSOfflineSearchSuggestionsModelLastUpdateDateKey I also discovered through experimentation, giving WBSOfflineSearchSuggestionsModelLastUpdateDateKey different date values (technically, they're string values of dates), that Safari checks for updates once a week. Thus, it was clear that Safari would make future ssl.gstatic.com connections, if allowed by Little Snitch. By the way, I should note that I've disabled "Include search engine suggestions" in Safari Search Settings, yet Safari is still apparently trying to download suggestions from Google? What I wanted to do was create a Little Snitch rule that applied to Safari Search Helper but not to websites loaded in Safari tabs. I tried creating a new rule using the explicit path on disk of Safari Search Helper, but that didn't work. Little Snitch seemed to ignore that rule and continued to attribute Safari Search Helper connections to the Safari app. I emailed Objective Development to ask whether there's any way to separate the rules in Little Snitch for the two processes, Safari and Safari Search Helper. At first, they said no, but then on reflection, they said yes! Safari via com.apple.Safari.SearchHelper The trick is to use "via" in the Little Snitch rule. When you're creating the rules, enter the full file paths of the two processes, separated by "via". Little Snitch will automatically replace the paths with the process names. Make sure you match both of the processes by code signing identity too. The above rule denies ssl.gstatic.com connections initiated by Safari Search Helper while otherwise allowing such connections by Safari. It's nice to know that this trick exists, though it's unlikely that you'll need to use it much. I thought the trick might help with Google Chrome, but it turns out that most Chrome connections are initiated by the Google Chrome Helper process: not only the web page connections but also the silent connections that run in the background, for example to googleapis.com, accounts.google.com, tools.google.com, clients1.google.com, clients2.google.com, clients3.google.com, etc. Needless to say, Google Chrome phones home a lot! It was disappointing to learn that Safari makes a silent connection to Google too. I guess that the massive yearly default search engine payment from Google to Apple buys a lot of access. Jeff Johnson (My apps, PayPal.Me, Mastodon) Articles index Previous: New secure note on macOS Sequoia