For the first 15 years of Classic Mac OS, right up to Mac OS 9 in 1999, Macs remained fundamentally single-user, and privacy wasn’t an issue of much concern. In those halcyon years of desktop publishing and HyperCard, users were more excited by opening information up than keeping it private, and the internet was in its infancy. It was Mac OS 9 that first integrated multiple user accounts and started to secure information using keychains.

Mac OS X brought the first full multi-user operating system to the Mac, but as internet connections became increasingly common and lasting, little attention was paid to privacy. By 2011, the Privacy tab in Security & Privacy, then in System Preferences, contained just three items: Location Services, Contacts, and Diagnostics & Usage. While privacy features developed elsewhere, for the sake of simplicity I’ll here focus on that pane in System Preferences, and its successor in System Settings.

Four years later, in OS X 10.10 Yosemite (2015) and still in 10.12 Sierra (2017), those three items had grown to eight, with the addition of Calendars, Reminders, Accessibility, and two social media platforms, Twitter and Facebook.

Then at WWDC in 2018, Apple revealed its new privacy architecture, putting it at the forefront in macOS 10.14 Mojave, and eventually reversing the order to Privacy & Security.

Mojave protected information in the following 15 categories:

• Location Services,
• Contacts (address books),
• Calendars,
• Reminders,
• Photos (Photos libraries),
• Mail,
• Messages,
• Safari browsing history,
• HTTP cookies,
• Call history (iOS),
• Time Machine backups,
• iTunes backups,
• camera input,
• audio input through the built-in microphone,
• automation (AppleScript and others).

Its new protection system was dubbed TCC, for Transparency Consent and Control, and has since become prominent in the nightmares of developers, those who support Macs and many who use them. At its worst, it crashes apps that don’t comply with its rules, as shown in the diagram below for macOS 10.14.

Various classes of protected data are shown at the left, those in red being covered explicitly in Privacy controls. The first step was to determine whether the app trying to access protected data was signed by Apple: if it was, access was determined by private controls, and sometimes regular controls as well.

Apps developed by third parties were checked to see whether they already had access to that particular class of protected data according to Privacy settings. If they had, access was then granted without further dialogs. Note that the effect of adding an app to the Full Disk Access list was to give it access to all protected data, but not services or hardware, without any further consent being sought.

If they hadn’t already been given access, the next check was to see which version of the SDK they were built against. If they were built against 10.13 or earlier, then Mojave didn’t expect them to have support such as usage information, so it should have displayed a dialog inviting consent to the requested access. That would normally only contain the standard text information.

If consent was given, then that app was added to the appropriate class in Privacy settings; if it was declined, then it was denied access, but wasn’t put on any blacklist, so consent could still be given on another occasion.

If the app was built against the 10.14 SDK, then stricter rules were applied. It was then required to have a usage statement for the class of data it was trying to access, where that was in the class-specific list at the top, or a protected device or service. If the app didn’t provide the appropriate usage statement, TCC considered the request to access protected data was unintended, and crashed the app as an ‘unexpected quit’.

If the app did contain a usage statement appropriate for that class of protected data, then Mojave displayed the consent dialog, this time containing the text from that usage statement as well. If consent was then given, the app would be added to the list in Privacy.

Since Mojave, TCC has been a fertile source of vulnerabilities for third-party researchers to discover, and the malicious to exploit. Three were reported shortly after the initial release of 10.14. Two, discovered by Patrick Wardle and Jeff Johnson, weren’t disclosed, to allow Apple to address them, and the third, in ssh, wasn’t so much a vulnerability as a feature that could be exploited.

Each successive major version of macOS has added further to that list from Mojave. Catalina (10.15, 2019) added new locations that required user intent or consent to access, including:

• ~/Desktop, widely used for active documents
• ~/Documents, main document storage
• ~/Downloads, the default location for downloaded files
• iCloud Drive, now widely used for shared working documents
• third-party cloud storage, if used
• removable volumes
• network volumes.

This is one of the late Security & Privacy panes from macOS Catalina in 2019.

By the time that macOS 13 Ventura was released in 2022, its shiny new Privacy & Security section in System Settings listed 20 categories. Some, like Full Disk Access and Files and Folders, overlapped, while others like Accessibility appeared to have been misnamed. Controls provided varied between different categories, and many users dreaded having to tinker with them.

At this rate of growth, Privacy will soon have its own app alongside System Settings.

Writing a coherent and comprehensive description of a painting is an excellent exercise not only for writing skills, but to remind yourself of the adage that a picture is worth a thousand words. Nowhere is this more appropriate than when describing graphical user interfaces such as macOS, as I reminded myself this week when trying to sort out a problem with Desktop behaviour.

That took me to Sequoia’s revised System Settings, where those for Desktop & Dock have become a farrago covering anything from the default web browser to the addition of margins to tiled windows. Although I’ve been one of System Settings’ few advocates, that section has become an example of what they shouldn’t be.

After the Finder, tools for configuring the appearance and behaviour of the interface are the most important. For many years, we had to do this through the keyhole of the fixed window size provided by System Preferences.

Many of its more complex panes had to resort to multiple tabs, here in the Network pane of 2002.

This was no easier for relatively simple panes, such as Sound, seen here in macOS 12 nearly 20 years later.

Ventura’s completely reworked System Settings were controversial, but at last provided the ability to expand panes vertically, although at that time many used floating windows to arrange discrete groups of settings in a hierarchy, such as those for Stage Manager.

Some of those used pictures, although most were illustrative rather than replacements for a thousand words, unlike the screenshot below.

Sequoia’s Desktop & Dock settings have been flattened out into a single view that’s so deep it even has to be scrolled on a Studio Display. Its sections include the Dock, Desktop, Stage Manager, Widgets, default web browser, Windows, tiling, Mission Control, keyboard shortcuts and Hot Corners, while further settings for the Desktop are controlled in Appearance and Wallpaper. Many of these are obscure unless you already use a feature, and many need further help, even for those who have been using macOS for years.

Like Desktop & Dock settings, its help page uses words exclusively rather than pictures, often doing little more than paraphrasing the text labels already shown in System Settings. Apple Support is one of many to provide a video tutorial for these settings, but those are of limited benefit when you just want to check how the options available for tabs in windows affect the appearance and behaviour of document windows, for example. Yet that would be so simple to demonstrate in three cutouts from screenshots, and so much more meaningful than the paraphrasing in Help: “Choose when you want documents to open in a tab (instead of in a new window): Never, Always or In Full Screen.”

In the last few years, Apple has devoted considerable engineering effort into enriching the macOS human interface, with Stage Manager and most recently Sequoia’s tiling feature. Even though you may not wish to use either, they do have their uses and some find them powerful.

Tiling is a case in point, as Apple seems to have decided that it should be enabled by default when you upgrade to Sequoia. That results in frustratingly changed behaviour when you drag a small window up to the top or another edge of the display, and it suddenly tiles out to cover the whole screen, without offering any Undo. Only by rummaging through System Settings will you discover that you can return that to normal by turning off Tile by dragging windows to screen edges in Desktop & Dock settings, although this has nothing to do with the Desktop or Dock.

In principle, I still believe System Settings is the right way forward, with its vertical flexibility and use of SwiftUI. But leading designs using those now come from third-party developers. It’s time for Apple to reassert its former mastery of the human interface, and realise the potential of SwiftUI by making System Settings a paragon rather than a pickle.

Each of the main security services in macOS, such as XProtect, relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.

Currently, those most frequently updated are XProtect and XProtect Remediator, normally released in two-week cycles. However, Sequoia has changed the way that XProtect’s data is updated, and it’s now intended occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.

This article details each of the main security data files found in macOS 15 Sequoia, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, or left frozen in time, and three have been removed completely; those are listed below for the record. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.

Main Security Data

XProtectPayloads, alias XProtect.app and XProtect Remediator
Latest version: 145, 3 September 2024.
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app on the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every two weeks using Software Update or a substitute.

XProtectPlistConfigData
Latest version: 1.0 5275, 24 September 2024.
These are the whitelists and blacklists used by XProtect, as detailed here. In Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle, on the Data volume; the secondary is also on the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and is used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Sequoia is intended to update the primary bundle via a CloudKit connection to iCloud, although it can still update the secondary bundle using those released via Software Update when they’re available. This is expected to be updated every two weeks, but may not be the same as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, and that will also copy an update obtained through Software Update to the primary location.

Bastion
Latest version: not given, but bundled in the current XProtectPayloads.
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. As of XProtectPayloads 137 it has 12 Bastion rules, but doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated infrequently.

AppleKextExcludeList
Latest version: 20.0.0, 5 September 2024 (15.0 release).
This is a huge list of kernel extensions which are to be treated as exceptions to Sequoia’s security rules, and is stored on the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist.

Others

IncompatibleAppsList
Latest version: 140.191 (15.0 release).
This is a bundle on the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.

Vestigial Data

MRTConfigData
Latest version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored on the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but may be later as a security data update.

Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database on the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database is no longer used.

Gatekeeper E Configuration Data (GKE)
Latest version: 8.0.
This is an SQLite database on the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since.

Recently Removed

TCC_Compatibility Bundle
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/TCC_Compatibility.bundle which has been removed from Sequoia.

Core Services Application Configuration Data
This used to be a bundle on the System volume at /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle, containing a list of app exceptions in /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist. This has been removed from Sequoia.

CompatibilityNotificationData
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/CompatibilityNotificationData.bundle, containing CompatibilityNotificationData.plist, and listing version ranges of third-party products to be notified as being (in)compatible. This has been removed from Sequoia.

Last updated: 24 September 2024.