Demonstrating causal connections using the log

Times are hard for many of us. Those who rely on clickbait for their income, directly or indirectly, need your clicks more than ever, to keep pace with rising prices. Conspiracy theory of the month, a good little earner, is that Apple is somehow inspecting all the images on your Mac (or iPhone, or iPad). While I’ve already published a detailed rebuttal of one claim, there will be others who jump on this bandwagon in a bid to pay their bills.

This article explains how such claims fail to demonstrate the alleged chain of causation, with an example from my recent look at what happens when ‘browsing images in the Finder’.

What you see

You’re browsing images in the Finder, without opening any of them in QuickLook Preview (by pressing the Spacebar). All of a sudden, your software firewall informs you that is trying to make a TLS connection with an Apple server at https://

It would be so easy to conclude that macOS was trying to phone home, and tell Apple about one or more of the images you’ve been looking at. But that association could be coincidental. The next step is to get more detail by looking in the log.

What’s in the log

I won’t reproduce the hundreds of log messages detailing what happened, but here are some highlights that provide an account.

The trigger for this came from a query raised by part of QuickLook, which apparently needed some help handling a RAW camera image among those being viewed.
1.251126 -[ControlManager handleClientConnection:on:]_block_invoke_2: QuickLookSatellite issued query command for

macOS decided that it needed to open an XML file containing a catalogue to support this.
1.251254 -[ControlManager newCatalogLoad:withPurpose:]: Catalog fileLocation: /System/Library/AssetsV2/com_apple_MobileAsset_RawCamera_Camera/com_apple_MobileAsset_RawCamera_Camera.xml

However, when it looks, there is no such file.
1.251259 -[ControlManager loadCatalog:catalogAssets:assetIds:postedDate:lastFetchDate:catalogInfo:withPurpose:]: Could not load catalog for

The solution is to download the catalogue. This is recorded by Launch Services.
1.252366 GetMobileAssetCatalog_block_invoke MobileAsset catalog not present. Initiating download
1.256211 failure to find bundle record for our audit token: Error Domain=NSOSStatusErrorDomain Code=-10814 "Unable to find this application extension record in the Launch Services database." UserInfo={NSDebugDescription=Unable to find this application extension record in the Launch Services database., _LSLine=699, _LSFunction=<private>}

Download options are then set.
1.259213 -[MADownloadOptions logOptions]: The download options are MADownloadOptions allowsCellular: 0 resourceTimeout: 900 canUseCacheServer: 0 discretionary: 1 sessionId: (null) additionalServerParams:(null) allowsExpensiveAccess:1 requiresPowerPluggedIn: 0 prefersInfraWiFi: 1 liveServerOnly: -1 DownloadAuthorizationHeader: not present analyticsData: not present + MAMsuDownloadOptions reqProdVersion: (null) delayPeriod: 0 managedDevice: 0 allowSameVersion: 0 prereqBuild: (null) prereqVersion: (null) prereqReleaseType: (default) liveAssetAudienceUUID: (null) purpose: (null)

Because there’s no catalogue at present, no check will be made to see whether the available catalogue is more recent than that already available.
1.259342 -[ControlManager getCatalogLastModifiedDate:ifFromXmlUrl:withPurpose:]: Prior catalog could not be loaded (may not have been downloaded yet) for so we will not use a Last-Modified when downloading

Unusually, the local Content Caching Server can’t be used for this, and the full URL is given.
1.261268 -[DownloadInfo determineDownloadUrl:callback:]: not allowed to use caching server, download from:

Everything is now ready to download the catalogue, so that is started.
1.266724 NDSession <12347C45-8739-4DA7-B122-617670672DDD> Task <977CCD45-7868-4750-A30B-691964886ED5>.<19> will begin

The TLS connection is negotiated and established, and boringssl gets on with the download. In case you’re wondering, BoringSSL is a fork of OpenSSL used by Google and others, and one of the mainstays of networking in macOS.
1.396577 boringssl [C19.1.1:2][0x1200278d0] TLS connected [version(0x0304) ciphersuite(TLS_AES_128_GCM_SHA256) group(0x001d) signature_alg(0x0403) alpn(http/1.1) resumed(0) offered_ticket(0) false_started(0) ocsp_received(1) sct_received(0) connect_time(29ms) flight_time(14ms) rtt(14ms) write_stalls(0) read_stalls(8)]
1.396782 nsurlsessiond CFNetwork Connection 19: connected successfully

The download takes 0.156 seconds, at the end of which completion is announced.
1.552752 mobileassetd CFNetwork Task <977CCD45-7868-4750-A30B-691964886ED5>.<19> finished successfully

There are many other details in the log, including an explicit statement giving the URL the XML file was obtained from, and where the download was installed.
1.553525 -[DownloadManager massageXmlAndPersist:from:to:with:postedDate:considerCaching:]: The staging path is: file:///System/Library/AssetsV2/staging/com_apple_MobileAsset_RawCamera_Camera.xml from target file:///System/Library/AssetsV2/com_apple_MobileAsset_RawCamera_Camera/com_apple_MobileAsset_RawCamera_Camera.xml

Sure enough, if you go to /System/Library/AssetsV2/com_apple_MobileAsset_RawCamera_Camera and look at com_apple_MobileAsset_RawCamera_Camera.xml, which is actually on the Data volume, you’ll find it’s a 1.2 MB file containing information about cameras whose RAW format is supported by macOS.


If anyone claims that macOS does or doesn’t do something, particularly if it’s undocumented or controversial, ask them to show you the log entries recording it. If they’re unable or refuse to, tell them to come back when they can. If they become evasive, don’t waste your time listening to a word they say, as they’re a charlatan, a trickster, a con artist.