Last Week on My Mac: Death, taxes and macOS updates
‘Tis impossible to be sure of any thing but Death, Taxes and macOS updates.
(Modified with apology from the original, said by Toby Guzzle in Christopher Bullock’s play The Cobbler of Preston (1716), quoted in turn by Daniel Defoe and most famously by Benjamin Franklin in 1789.)
Last week my iMac Pro was updated against my wishes from macOS Sequoia 15.1.1 to 15.3.1. Although it wasn’t my intention, it proved a relief in two ways, first that my ageing iMac Pro survived the process without losing any data or dying completely, and second that I had at last caught a forced update red-handed. For some years I have been aware of many who suffered a similar fate, where they had been careful to avoid upgrading or updating macOS, but had eventually succumbed to it unwittingly. At last I was able to experience this at first hand, and capture log excerpts to discover just what happened.
Deceit
My conclusions were:
Software update notifications tricked me into unwittingly agreeing to perform a macOS update.
That update was expressly against my Software Update settings.
I was given no second chance to confirm I intended the update to take place.
The update was scheduled to be performed when my Mac was unattended.
DAS scheduling and dispatch were unaware of the scheduled backups to be performed later that night, and dispatched the update at a time before those backups were scheduled. Had anything gone wrong in the update, I could have had to fall back on backups made nearly 24 hours earlier, and would have lost a whole day’s changes.
What I’d like to see is a change to the process initiated by opting to perform a delayed update, either later or that night. If the user opts for that, then Software Update should display a clear confirmation dialog, offering options to cancel the update or postpone it further. If the user does accept, then they should be offered a timeframe for the update to be performed, to allow it to be scheduled after any nightly backups.
Above all, the user should never be given a forced choice between updating now or later tonight, and there should always be a third option to defer further.
This has been a long-running flaw in the behaviour of macOS that has shocked and antagonised many users over several years. Although we’re all in favour of Apple encouraging and facilitating us to keep macOS up to date, there’s neither need nor excuse to do so by deceiving us by trickery. Deceit undermines confidence in both Apple and its products and is notoriously bad marketing and support.
This chart shows how I believe the process works, from the initial notification options to starting the update.
Opacity and persistence
During my investigation of how this unwanted update had occurred, I hadn’t expected to meet my old friend Duet Activity Scheduler (DAS). As I traced through the log extracts it became clear that, once the update had been scheduled by DAS, the only way to postpone or abort it would have been to shut the Mac down. Activities scheduled by DAS-CTS are hidden from the user, who has neither awareness nor control over them.
DAS and its linked XPC Activity subsystem, alias Centralised Task Scheduling or CTS, now manage over 500 background activities in macOS, including Time Machine backups and XProtect Remediator scans. They’re one of the few parts of the system that remains almost inaccessible. DAS manages lists of activities that can’t be inspected, and dispatches them according to opaque criteria. Once an activity is scheduled by DAS, there’s no way a user can remove it from its lists, so it will inexorably attain a score sufficient to pass that set by DAS as its threshold. For a few brief moments that activity will be visible among running processes, then vanish again into obscurity.
If I wanted to design persistent code that periodically harvests and send sensitive data to a remote server, DAS-CTS would be highly attractive. As there’s no way to inspect its scheduled activities, no security software could discover the existence of that activity, unless they were fortunate enough to catch it while it’s running briefly. Such activities don’t need a tell-tale LaunchDaemon or LaunchAgent, but can be arbitrary code in a completion handler within an apparently innocent app. They’re run using XPC, but without its formalities or restrictions.
DAS-CTS seems to rely largely on security through obscurity, and opening up inspection of its activity lists could be a valuable first step in preventing its abuse. It has enjoyed a decade since its release in 2014 apparently without being exploited, although its opacity makes it difficult to know that with any confidence. Perhaps it’s time for a reassessment.
