Lambing dates remain one of life’s great mysteries. Here in the UK, farmers in the north usually lamb earliest, often only just after Christmas when it’s usually bitter cold and snowy up there. Down here in the balmy south, lambs are born three months or more later, typically in April, when they’re often struggling to keep cool in the sunshine. Last week we saw the first of this year’s lambs, and Apple’s Spring OS fest, including Sequoia 15.4.

Size

That update was large, but that isn’t exactly unusual:

• 7 March 2024, Sonoma 14.4 was 3.6 GB (Apple silicon) with 64 vulnerabilities fixed, “the most substantial update of this cycle so far”;
• 27 March 2023, Ventura 13.3 was 4.5 GB with 49 vulnerabilities fixed, being “substantial, and brings many improvements and fixes”;
• 14 March 2022, Monterey 12.3 was 5.3 GB with 45 vulnerabilities fixed, being “very substantial, introducing major new features like Universal Control and Spatial Audio, changing several bundled apps, and fixing many bugs”;
• 26 April 2021, Big Sur 11.3 was 6.62 GB with over 50 vulnerabilities fixed, “the largest update to macOS since Mojave, and quite possibly the largest ever”.

(Figures and quotations from links here.)

Although the 15.4 update wasn’t quite as large as 11.3, at 6.2 GB for Apple silicon, it has comfortably surpassed it in the number of vulnerabilities fixed, 131 in all, and came close to the size of the 15.0 upgrade at 6.6 GB. What’s most disappointing is that, while the first release of Sequoia merited long and detailed accounts of much of what had changed, for 15.4 there’s precious little information beyond its lengthy security release notes.

A stroll through the version numbers of its bundled apps and /System/Library confirms the extent of changes. There was no point in my trying to compile an article listing them, as it might have been briefer to report what hasn’t changed. What’s more to the point is what’s new in 15.4, what are its Spring lambs?

Novelties

Among the new kernel extensions is the first version of AppleProcessorTrace, and there’s a brace to support hardware in Apple silicon chips including a T6020 and T8103 for PCIe, and a T6032. Those appear to be for M2 Pro, M1 and M3 Ultra chips, respectively. There are two new public frameworks, one named CLLogEntry that is presumably for Core Location log entries, the other tantalisingly named SecurityUI. Neither seems to align to anything in Apple’s developer documentation, so might be preparing the ground for what we’ll hear about in early June at WWDC, when the lambs have grown a bit.

I keep a track of the total number of bundles in several of the folders in /System/Library. Since the release of Sequoia 15.0, that containing Private Frameworks has grown from 4,255 to 4,398. Because of their layout, this total overestimates the real change in numbers, and that probably represents a true growth of around 70 Private Frameworks in Sequoia so far.

These Private Frameworks contain code features used privately by Apple’s apps, but not exposed to third-party developers. Although much is of little or no use or advantage, they also contain much that supports changing features in macOS. Using Private Frameworks is a sure way to madness, and something explicitly forbidden in the App Store, but, like the unaffordable car or boat we like to gloat at, there’s no harm in wondering what they will bring in the future.

The list of new Private Frameworks in Sequoia 15.4 is long, and includes: AUSettings, Bosporus, ComputationalGraph, CoreAudioOrchestration, CryptexKit, CryptexServer, DailyBriefing, DeepVideoProcessingCore, Dyld, ExclaveFDRDecode, FPFS, FindMyPairing, various GameServices, GenerativePlaygroundUI, MCCFoundation, MLIR_ML, MobileAssetExclaveServices, Morpheus, MorpheusExtensions, an OnDeviceStorage group, OpenAPIRuntimeInternal, OpenAPIURLSessionInternal, PIRGeoProtos, RapidResourceDelivery, SecureVoiceTriggerAssets, SecurityUICore, and VideoEffect.

While many of those names can inform speculation about what we’re about to see in macOS 16, three merit a little more decoding.

Cryptexes are secure disk images loaded during boot that currently deliver Safari and its supporting components, and the dynamic libraries for all those frameworks, public and private. Accessing them from user-level code isn’t something you’d expect to happen, so those two Private Frameworks, CryptexKit and CryptexServer, hint at further expansion in their use and support.

Bosporus

The Bosporus Strait in Turkey connects the Black Sea to the Sea of Marmara, thence through the Dardanelles to the eastern Mediterranean. It’s a busy thoroughfare formerly used heavily by ships carrying grain and other bulk cargoes from Ukraine and Russia.

View of Constantinople and the Bosphorus (1856) is one of many views that Ivan Aivazovsky made of this great city, which he visited on many occasions. The artist kept his studio in Crimea, on the opposite (northern) shore of the Black Sea.

Morpheus

Morpheus is the god of dreams, whose name is the source of the word morphine. Although usually distinct from Hypnos, god of sleep, he’s sometimes associated with Nyx, goddess of the night, most famously in reference to a passage from Virgil’s Aeneid, painted below by Evelyn De Morgan.

She pairs Nyx with Morpheus in her Night and Sleep, from 1878. The further figure is a young woman wearing long red robes, her eyes closed, clutching a large brown cloak with her right hand, and most likely Nyx. Her left arm is intertwined with a young man’s right arm. He also has his eyes closed, and is most probably Morpheus. He clutches a large bunch of poppies to his chest with his left arm, while his right scatters them, so they fall to the ground below.

Virgil’s lines in Book 4, line 486 read:
hinc mihi Massylae gentis monstrata sacerdos,
Hesperidum templi custos, epulasque draconi
quae dabat et sacros servabat in arbore ramos,
spargens umida mella soporiferumque papaver.
haec se carminibus promittit solvere mentes
quas velit, ast aliis duras immittere curas…

Translated (at Perseus at Tufts University), this reads:
From thence is come
a witch, a priestess, a Numidian crone,
who guards the shrine of the Hesperides
and feeds the dragon; she protects the fruit
of that enchanting tree, and scatters there
her slumb’rous poppies mixed with honey-dew.
Her spells and magic promise to set free
what hearts she will, or visit cruel woes
on men afar.

Spargens umida mella soporiferumque papaver, one of Virgil’s greatest lines, is conventionally translated as “scattering moist honey and sleep-inducing poppy”, and describes well the effects of the opiate drugs derived from opium poppies, including morphine.

I look forward to watching the lambs grow up through the coming summer, and learning about those lambs that came with Sequoia 15.4 at WWDC.

The firing of the head of the National Security Agency was only the latest move that has eroded the country’s fortifications against cyberattacks, especially those targeting elections.

© Joshua Roberts/Reuters

Two dozen trade experts gathered recently to simulate how a global trade war would play out. The results were surprisingly optimistic.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5292. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version removes the macos_toydrop_b rule for MACOS.ADLOAD, and amends the rules for MACOS.ADLOAD.I, MACOS.BUNDLORE.MDPLST and MACOS.ADLOAD.IN.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5292.

Sequoia systems only

This update has now been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5292 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Apple has just released the update to macOS Sequoia to bring it to version 15.4, and security updates for 14.7.5 and 13.7.5.

The Sequoia update for Apple silicon Macs is about 6.2 GB in size, and 3.9 GB for Intel models, making it one of the largest intermediate updates for some years. For Apple silicon Macs, the update to 14.7.5 is about 3.7 GB, and to 13.7.5 about 3.3 GB.

Among the changes listed by Apple for 15.4 are:

• Adds Memory movies in Photos using AI.
• Adds a Sketch Style option in Image Playground, in AI.
• Adds Mail Categorisation.
• Apple silicon Macs with an internal SD card reader now support SDUC cards larger than 2TB.
• This should resolve problems with some M4 Macs being unable to launch Virtual Machines.
• Content filter extensions correctly receive non-TCP/UDP network protocol traffic.
• Finder no longer fails to copy some dataless files from SMB file shares.

Enterprise release notes are here.

Software Update settings will be automatically changed to enable future macOS updates to be downloaded and installed automatically: if you don’t want that, you’ll need to change that setting once your Mac boots in 15.4.

Security release notes are available for Sequoia, Sonoma and Ventura updates. There are a total of 131 vulnerabilities fixed in 15.4, which must be a record. None is reported as being suspected of exploitation in the wild, and the security updates for Sonoma and Ventura are almost as numerous.

Firmware updates include iBoot (Apple silicon) to version 11881.101.1, and T2 Macs to 2075.101.2.0.0 (iBridge 22.16.14248.0.0,0). The macOS build number is 24E248.

The new version of Safari in 15.4 is 18.4 (20621.1.15.11.10). APFS is updated to version 2332.101.1.

As so much has changed, I won’t be posting a separate article listing significant changes: it looks like pretty well everything has!

Just for reference, the Sequoia 15.0 major version upgrade from Sonoma was 6.6 GB for Apple silicon, and 4.9 GB for Intel – those aren’t that much larger than this ‘minor version update’.

Those intending to update Apple silicon Virtual Machines currently running 15.3.2 should be prepared for the 15.4 update to fail. I’ve tried with two VMs now, one with a fresh copy of 15.3.2, and both have failed early during installation with a kernel panic. However, 15.4 does install correctly from the latest IPSW image file. Older VMs with 14.7.4 and 13.7.4 do update correctly to 14.7.5 and 13.7.5 respectively.

[Last updated 1715 GMT 1 April 2025.]

Trust your staff, admit mistakes, don’t embarrass the president.

Help yourself. The door is open.

Each new version of macOS has increased the complexity of launching apps, from the basics of launchd, the addition of LaunchServices, to security checks on notarization and XProtect. This article steps through the major landmarks seen when launching a notarized app that has already passed its first-run checks and is known to macOS Sequoia 15.3, on an Apple silicon Mac.

Rather than trying to provide a blow-by-blow account of what’s written in the log over the course of thousands of entries, I’ve extracted landmarks that demonstrate when each subsystem gets involved and its salient actions. These have been gleaned from several similar app launches, and are ultimately timed and taken from one complete record of one of my simpler notarized apps that has no entitlements and uses only basic AppKit features. The app hadn’t been through quarantine as it had been built and notarized on the same Mac, and had been run previously but not in that session since the previous boot. It had thus been previously registered with LaunchServices and other subsystems. The host was a Mac mini M4 Pro, so timings should be briefer than on many other Macs, it was run from the main Applications folder on the internal SSD, and AI was enabled.

LaunchServices and RunningBoard

LaunchServices has been around for many years, and handles many of the tasks exposed in the Finder, including mapping of document types to app capabilities, Recent Items and Open Recent lists, making it the backbone of app launching. RunningBoard was introduced in Catalina and has steadily assumed responsibility for managing resources used by apps, including memory and access to the GPU. Although the test app doesn’t have any of its resources managed by RunningBoard, LaunchServices launched it through RunningBoard.

RunningBoard’s first task is to create a job description, which it helpfully writes to the log as a dictionary. This is a mine of useful information, and has replaced the copious information compiled by LaunchServices in the past. This includes:

• a dictionary of Mach services
• whether Pressured Exit is enabled
• a full listing of environment variables, such as TMPDIR, SHELL, PATH
• RunningBoard properties including another TMPDIR
• whether to materialise dataless files.

Once that job description has been constructed for the app, RunningBoard tracks the app and its assertions, providing a detailed running commentary through the rest of the app’s life. LaunchServices still performs its traditional tasks, including creating an LSApplication object and sending an oapp AppleEvent to mark the opening of the app, and launchd still reports that it’s uncorking exec source upfront.

When the app is running, its preferences are loaded from the user CFPrefsD, and its pasteboard is created. Almost 0.1 second later (0.3 seconds after the start of launch) there’s a sustained flurry of log entries concerning Biome, and signs of AI involvement (Apple silicon only). The latter include a check for the availability of generative models and WritingTools. There are also entries referring to the loading of synapse observers.

LaunchServices log entries are readily accessed through its subsystem com.apple.launchservices, and RunningBoard through com.apple.runningboard.

Security and privacy

The first serious engagement in security is the verification of the app’s signature and its evaluation by Apple Mobile File Integrity (AMFI, using amfid). Shortly after that comes the standard Gatekeeper (GK) assessment, with its XProtect scan, starting less than 0.1 second after the start of launch. Immediately after the start of that scan, XProtect should report which set of data files it’s using. In Sequoia those should be at /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara. That scan took just over 0.1 second.

While XProtect is busy, syspolicyd checks the app’s notarization ticket online, through a CloudKit connection with the CKTicketStore. That’s obvious from log entries recording the network connections involved, and the complete check takes around 0.05 second. Once that and the XProtect scan are complete, syspolicyd reports the GK scan is complete, and evaluates its result.

At about the same time that the Gatekeeper checks are completing, privacy management by TCC (Transparency Consent and Control, in tccd) is starting up. Its initialisation includes establishing the Attribution Chain for any Mach-O binaries run by the app, so that TCC knows where to look for any required entitlements. Following that, TCC writes bursts of entries as different components such as the Open and Save Panel service are set up for the app.

The final phases of security initialisation come in provenance tracking, which first appeared in macOS Ventura. This may be associated with presence of the extended attribute com.apple.provenance, but details are currently sketchy.

Following syspolicy in the log is best through its subsystem com.apple.syspolicy, you can watch XProtect using com.apple.xprotect, and TCC is com.apple.TCC.

Overall

Downloadable PDF: applaunch153

Main landmarks with elapsed time in seconds:

• 0.000 Finder sendAction
• 0.023 LaunchServices, launch through RunningBoard
• 0.029 RunningBoard launch request
• 0.043 AMFI evaluate
• 0.066 Gatekeeper assessment
• 0.080 XProtect scan
• 0.085 check notarization ticket
• 0.187 TCC checks
• 0.204 launched

Previous article

Launching apps in Sonoma 14.6.1: Conclusions

The additions included companies that are customers of Intel and Nvidia, and one firm that was the focus of a New York Times investigation last year.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5291. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version amends the Yara rule for MACOS.PIRRIT.OBF.DROPPER, but doesn’t add any new rules.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5291.

Sequoia systems only

This update has also been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5291 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Entitlements are settings baked into an app’s signature that enable it to do things that otherwise wouldn’t be allowed. Many let App Store apps do things their sandbox wouldn’t normally permit. Others give access to features that are controlled by privacy protection, so may be used by apps that aren’t sandboxed. A few enable apps specially approved by Apple to use features in macOS that aren’t generally available, such as working with APFS snapshots.

One way to run third-party apps in relative security is to confine them to a tightly restricted environment, a sandbox. That denies them the ability to access storage or other resources outside those dedicated to it in its sandbox. That’s too restrictive for the great majority of apps, which need to be able to open and save documents to folders such as ~/Documents, so entitlements specify which sandbox restrictions they’re allowed to break. In the case of opening and saving documents outside the sandbox, the entitlement is named com.apple.security.files.user-selected.read-write, and gives that app read and write access to files the user has selected in a standard macOS Open or Save dialog. Apple requires that all apps distributed through its App Store run in their own sandbox, so they all claim entitlements to be able to work beyond that.

Sandboxed apps all have their own entitlement to their sandbox, com.apple.security.app-sandbox, which isn’t used by apps that are notarized but not sandboxed. Whether sandboxed or not, an app might need access to the Mac’s camera, and for that it will need an entitlement named com.apple.security.device.camera.

Thus, entitlements fall into groups:

• Those that can be used by any app that wants access to controlled features, depending on whether it’s sandboxed or not.
• Those that give access to macOS features that have to be approved by Apple.
• Those that are private to Apple’s own apps and can’t be used by third-parties.

Viewing entitlements

The Finder and other macOS utilities don’t reveal whether an app runs in a sandbox, nor list its entitlements. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency.

Apparency’s Entitlements pane lists all those baked into that app’s signature. My own free Taccy also lists entitlements, but for this purpose Apparency is the better tool by far.

Apps that aren’t sandboxed, only hardened and notarized, will only have entitlements if they need to access privacy-protected features, or use restricted features in macOS. In many cases, that means they will have neither entitlements nor a provisioning profile.

com.apple.security

These give an app access to files and features that are restricted, either by the sandbox, or by privacy protection.

Sandbox controls

These are options that extend an app’s abilities beyond the sandbox, starting with the entitlement that sets the sandbox in the first place. They aren’t used by apps provided outside the App Store that are only notarized and not sandboxed. Apple provides fuller details of the sandbox here.

Examples include:

• com.apple.security.app-sandbox runs the app in a sandbox, and is standard for all sandboxed apps
• com.apple.security.files.user-selected.read-write gives read and write access to files the user has selected in a standard macOS Open or Save dialog
• com.apple.security.files.bookmarks.app-scope gives access to security-scoped bookmarks with app scope
• com.apple.security.files.bookmarks.document-scope gives access to security-scoped bookmarks with document scope
• com.apple.security.network.client allows it to open outgoing network connections
• com.apple.security.print allows it to print.

Privacy controls

These give access to information, devices and features that are controlled by the privacy features in macOS, enforced either by Location Services or by TCC. These are used by any third-party app, whether supplied through the App Store or not, and include:

• com.apple.security.personal-information.addressbook gives access to the content of the address book
• com.apple.security.personal-information.location gives access to location data from Location Services
• com.apple.security.device.camera gives access to the camera
• com.apple.security.device.microphone gives access to the microphone
• com.apple.security.automation.apple-events enables automation using AppleEvents.

These normally have a corresponding list in Privacy & Security settings.

com.apple.developer

These entitlements can only be granted by Apple, and control access to macOS features that aren’t generally available. Among the most common are:

• com.apple.developer.endpoint-security.client enables it to monitor system events for potentially malicious activity using Endpoint Security
• com.apple.developer.persistent-content-capture is required for a Virtual Network Computing (VNC) app to have persistent access to screen capture
• com.apple.developer.driverkit gives an extension permission to run as a user-space driver
• com.apple.developer.vfs.snapshot gives access to snapshot features
• com.apple.vm.networking allows virtual network interfaces without their having to escalate privileges to the root user, typically in bridged networking.

com.apple.private

These are private to Apple’s own apps, and encompass many other com.apple entitlements that aren’t documented for third-party developers. Examples include:

• com.apple.private.applemediaservices
• com.apple.private.dmd.policy
• com.apple.private.octagon
• com.apple.authkit.client.private
• com.apple.duet.activityscheduler.allow.

Some appear self-explanatory, others are opaque.

Command tools and standalone executables

Although Mach-O binaries such as command tools and daemons can be hardened and signed, thus can be notarized, they can’t have a provisioning profile embedded, so can’t have entitlements. Apple recommends working around this by wrapping them in an app-like structure, as explained here.

Entitlements for access to features controlled by privacy protection rely instead on the attribution chain to determine whether they’re entitled. Thus a command tool called by an app isn’t expected to have the entitlement, but the app calling that binary is.

Stripping signatures

Because entitlements are baked into the signature, if you were to strip the signature from an app, that would remove all its entitlements. For a sandboxed app, that might not be fatal, but for most other types of entitlement, that could render the app non-functional. Resigning the app with an ad hoc signature wouldn’t help either.

References

Apple’s Entitlements documentation
Tech Note 3125 on provisioning profiles for code signatures
If you can’t find an entitlement in any of those lists, try looking in Jonathan Levin’s database of all known entitlements for iOS and macOS, which is as comprehensive as we’re likely to get.

Gene banks are like a survivalist cache: our nation’s safeguard against all future challenges to growing the food we need.

Last week’s security updates to macOS have left some confusion over version numbers, and firmware for T2 Macs. This article attempts to clarify what happened, and where supported versions of macOS are going next.

Security updates 11 March 2025

Apple released:

• macOS 15.3.2 Sequoia
• Safari for macOS 14.7.4 Sonoma
• Safari for macOS 13.7.4 Ventura.

There were no security updates for Sonoma or Ventura other than their Safari updates.

There was also a firmware update included in the 15.3.2 update, changing the version of iBridge firmware in the T2 chip of Intel Macs from 22.16.13051.0.0,0 to 22.16.13060.0.0,0. There were no firmware updates for Apple silicon Macs, nor for Intel models without T2 chips, I understand.

Sequoia

If your Mac is running macOS Sequoia and has been updated, it should now be running 15.3.2 (build 24D81). If it has a T2 chip, it should have updated its firmware to read
EFI 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0)

Safari should be version 18.3.1 (20620.2.4.11.6).

Sonoma

If your Mac is running macOS Sonoma and has been updated, it should still be running 14.7.4 (build 23H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (19621.1.14.11.3, 19621).

Ventura

If your Mac is running macOS Ventura and has been updated, it should still be running 13.7.4 (build 22H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (18621.1.14.11.3, 18621).

SilentKnight

To keep a complex situation as simple as possible, SilentKnight only considers one firmware version to be current for each model of Mac. If it tried anything more complex, I’d not be able to cope. As there are presently two different ‘current’ and supported versions of T2 firmware in use, SilentKnight goes with the older one. That way it doesn’t complain, but politely remarks for Sequoia 15.3.2:
EFI version found 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0) ;
expected 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Please bear with me until Apple resyncs T2 firmware across the three supported versions of macOS. I’m sure that will return with the release of 15.4, 14.7.5 and 13.7.5. If not, we can all scream together.

Sonoma 14.7.5 and Ventura 13.7.5

Many have been reporting that their Macs have been updated to 14.7.5 or 13.7.5, and some have claimed that those versions have been released by Apple. They are in fact beta-releases of the next scheduled updates to Sonoma and Ventura, and haven’t yet been generally released. If your Mac is running one of those, you might like to check it against recent beta-releases:

• 21 February 2025 betas: Sonoma 14.7.5 (23H510), Ventura 13.7.5 (22H510)
• 10 March 2025 betas: Sonoma 14.7.5 (23H520), Ventura 13.7.5 (22H520)
• 17 March 2025 betas: Sonoma 14.7.5 (23H525), Ventura 13.7.5 (22H525)

App Store full installers

If you download a full installer from the App Store or elsewhere, the current releases are:

• Sequoia 15.3.2 (build 24D81)
• Sonoma 14.7.4 (build 23H420), which will then need Safari updated
• Ventura 13.7.4 (build 22H420), which will then need Safari updated.

How has this happened?

Normally, when the current version of macOS has a security update, the two older versions that are still supported have matching security updates. That would have brought 14.7.5 and 13.7.5 along with 15.3.2. However, in this case the patch to be applied could be supplied in a Safari update for the older two. As that’s much smaller and simpler than a full macOS update, Apple opted to supply those as Safari updates alone, which can’t of course be a new version of macOS.

This is possible because Safari and some of its supporting frameworks and components aren’t part of the Signed System Volume, so updating them doesn’t require the System volume to be rebuilt, turned into a snapshot, and installed as a new Signed System Volume.

However, firmware updates can only be supplied and installed as part of a full macOS update, so it was only possible to update T2 firmware in Sequoia systems being updated the long way to 15.3.2.

I hope this dispels any remaining confusion.

I’m grateful to ExcleX for pointing out that Safari versions can vary according to when you updated.

If you have a laptop Apple silicon Mac, you’ll no doubt have discovered one of its novel features: connect a USB or Thunderbolt peripheral to one of its USB-C ports, and you could be asked whether to allow it to connect, as a result of its Accessory Security. This isn’t available in desktop models, though. This article explores how it works and how it’s associated with liquid detection.

Accessory Security setting

At the foot of the Privacy & Security section of System Settings in capable Macs is an extra control Allow accessories to connect. In macOS Sequoia this has four options:

• Ask Every Time, which prompts you to approve every time you connect a peripheral to a USB-C port.
• Ask for New Accessories, which only prompts you to approve devices that it hasn’t connected previously. However, if your Mac is locked for three days or more, it may ‘forget’ devices that it approved previously, and require you to approve each again.
• Automatically When Unlocked, which connects all devices without prompting, so long as that’s done when that Mac is unlocked.
• Always, which will never prompt you to approve a device.

This novel security mechanism is intended to prevent laptop Macs from being attacked using plug-in USB or Thunderbolt devices intended to breach their security. Apple considers laptop models to be most at risk, but surprisingly still hasn’t offered this as an option in any of its desktop models.

Approval

When you connect a USB or Thunderbolt device to one of your Mac’s USB-C ports, there will be a momentary delay and, if your approval is required, an alert will be displayed.

To approve or refuse that invitation, you’ll first need to unlock your Mac if it’s locked. Peripherals such as hubs and docks that can charge your Mac will still be able to do that even if you don’t allow them to connect, but all other features will be blocked until you click on Allow.

How it works

To examine how Accessory Security works, I connected a Thunderbolt 4 hub to a USB-C port on a MacBook Pro M3 Pro, which supports this feature, and a Mac mini M4 Pro, which doesn’t. The setting for the laptop was to Ask Every Time. I then captured their logs using LogUI and compared the contents of each.

Port activation

This consisted of a long sequence of entries from IOAccessoryManager detailing port activation and initial configuration. Here are some waymarks among those, with elapsed time given in seconds:
0.883 IOAccessoryManager IOPortTransportState::setActive(): [Port-USB-C@2: CC] active: YES (transportType: 1 [CC])
0.883 IOAccessoryManager IOServiceNotificationManager::handleServiceReregistration(): [Port-USB-C@2/CC] Re-registering service...
0.883 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB3... (transportType: 3)
0.884 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB2... (transportType: 2)
0.884 IOAccessoryManager IOPort::_updateConnectionActive_block_invoke(): [Port-USB-C@2] m_connectionActive: YES, m_connectionCount: 1, m_connectionUUID: F53E1B0B-8347-4528-B77C-FC79E8A657C5
The last entry there records the connection’s UUID.

Is it authorised?

Next, authorisation was assessed:
0.885 IOAccessoryManager IOPort::_updateAuthorizationState(): [Port-USB-C@2] Updating authorization state...
0.885 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: NO -> YES, authorizationPending: NO -> NO, userAuthorizationPending: NO -> NO, supervisedTransportActive: NO -> NO
Those will still appear in the log of a desktop Mac, but will say NO throughout.

There are repeated updates of the port’s pin configuration:
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPinConfiguration(): Updating pin configuration...
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setCableActive(): activeCable: NO
0.885 IOAccessoryManager 1605 IOAccessoryManagerUSBC::setCableOptical(): opticalCable: NO
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setDisplayPortPinAssignment(): dpPinAssignment: 0
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPlugOrientation(): plugOrientation: 2
0.885 IOAccessoryManager IOPortTransportStateUSB::setDataRole(): [@: IOPortTransportStateUSB3] Setting data role... (dataRole: 2 [Host])

Liquid detection

A little while later, in the laptop only, a hardware liquid detection sensor was checked, to see if there was any liquid present in the receptacle (port):
0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
On a desktop Mac running Sequoia, you’ll only see LDCM is not supported on this device.

Approval

Preparations are then made to display the approval dialog, and authorisation status is updated:
1.116 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: YES -> YES, authorizationPending: NO -> YES, userAuthorizationPending: NO -> YES, supervisedTransportActive: NO -> YES

As promised in Apple’s documentation, charging from the peripheral is enabled before approval:
2.639 IOAccessoryManager IOPortFeaturePower::_addPowerSource(): [Port-USB-C@2/Power In] Adding power source (powerSourceName: Brick ID)...
and the power chime may be sounded
2.718 gui/501/com.apple.powerchime xpcproxy spawned with pid 1677

Once approval is given in the dialog, this is recorded and the connection is then established fully:
4.709 IOUIAgent Received notification response! (userNotification: 0x620364480, .responseReceived: 1, .notificationCancelled: 0, .notificationDismissed: 0, userAuthorizationStatus: 2, port: <private>)
4.709 IOAccessoryManager IOPortUserClient::setUserAuthorizationStatus(): Setting user authorization status... (target: Port-USB-C@2, newUserAuthorizationStatus: 2 [Authorized])

Authorisation

Although Accessory Security settings are in Privacy & Security, much of which is concerned with controls implemented by TCC, protection and authorisation is here controlled by IOAccessoryManager. Its list of previously approved devices isn’t exposed to the user, and the only control is its single setting.

Liquid detection

The surprise feature is liquid detection, in the liquiddetectiond service and LDCM. This is a new feature in macOS Sequoia, and the following models:

• MacBook Air M3 and later
• MacBook Pro with M3 Pro or Max
• MacBook Pro with M4 base, Pro or Max.

If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, a sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry. Full details are given in this support note, dated 23 November 2024.

Previously, reports of this feature claimed that it was intended for use by Apple to determine whether a laptop Mac had been damaged by liquid ingress. Like all laptops, internal components of MacBook Air and Pro models contain several liquid sensors already intended to reveal whether ingress has occurred. Sensors in the USB-C receptacles are clearly different, and are being used to prevent damage by corrosion inside the receptacle, rather than limit warranty or AppleCare+ repairs.

Summary

• Accessory Security is available in all laptop Apple silicon Macs, and intended to prevent attack by malicious devices.
• A single control in Privacy & Security settings determines when approval will be required for devices to be connected to a USB-C port.
• This is controlled by IOAccessoryManager, which manages the initialisation and preparation of USB-C ports. TCC is not involved.
• Some laptop M3 and M4 models have liquid detectors in each USB-C port. These will alert you if liquid is found when connecting to a USB-C port. This is intended to prevent corrosion occurring inside the receptacle, not to detect damage caused by liquid ingress.

Before the introduction of specific protection for privacy, like all Posix-compliant operating systems, macOS had just a standard system of privileges and permissions, augmented by ACLs. Although proven in terms of security, they are too coarse to be used to protect different classes of information within the same level of privilege.

When you run an app, it naturally runs with your full user’s privileges, and has access to everything according to the permissions set on folders and files. Just as you want your privileges to give the Finder and your mail client access to all your emails and their enclosures, all other apps that you run enjoy those same privileges. But would you also want a third-party note-taking or photo-editing app to have that same level of access, even without your knowledge? Similarly, while you want FaceTime to have access to your Mac’s camera and microphone, would you be happy for any other app to access them without your being asked?

Although robust security provides a foundation for the protection of privacy, they are quite different. Your FileVault and user passwords must be protected by good security, but entries in your address book and calendar aren’t the same, and primarily a concern for privacy protection.

Consent and intent

Privacy centres on controlling access to information and devices that provide it, and there are two approaches used to give you that control, your consent and your intent. These are used throughout privacy protection in macOS.

For an app to gain access to images from your Mac’s built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that may seem tedious and even pointless at times, the decision remains yours and not the app’s or that of macOS. If the whole purpose of an app is to provide web conferencing, then its consent dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps do want camera access.

Protected folders are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one, so for that macOS may ask for your consent instead.

Command tools and helpers

Expressing intent and obtaining consent are proven methods that work for apps with a human interface. Code is run in many other ways that don’t present any interface to the user. This applies to command tools, helper apps, and similar. To apply the same principles there relies on another fundamental concept in privacy protection, the attribution chain. Although you won’t normally encounter this in the GUI, if you ever need to understand how protection works, and if you have to resort to looking at logs, you’ll find it essential.

Let’s say I have an app that builds an index of files containing references to keywords, and does so using a command tool keyindexer. For that command tool to access files in my Documents folder, it can’t rely on intent for each one, so must seek consent. As it has no interface, the only way that can be obtained is through its parent app, through the attribution chain. If I were to run that same command from Terminal, then the Terminal app would be its parent, found by macOS using its attribution chain, and that’s why many prefer to give Terminal Full Disk Access.

Universal, not extensible, permanent

One of the more common complaints about privacy protection is that it’s universal. You as a user may not keep anything private in your Documents folder, but there’s no opt-out that lets you remove that from protection. That ensures that all apps are written on the assumption that ~/Documents is a protected folder, and ensures that hostile software can’t remove protection from any folder.

Unlike permissions, you can’t extend privacy protections to other locations or features. Although that could be attractive, privacy protection is complicated enough to negotiate without it being applied to almost anything you might fancy.

Until recently, when you gave consent for an app to have access to protected locations or features, that was set until you changed it. macOS 15 Sequoia has changed that, in that you’re now reminded periodically if you have given screen recording consent for an app. This has proved problematic, with many criticisms and persistent bugs.

Informative texts and entitlements

Depending on the privacy protection, Apple can apply restrictions as to which apps can request the user for consent to access a protected resource. This is implemented in two ways: a requirement for the app to provide in its Info.plist the text to be shown to the user in the consent dialog, and an entitlement to access the protected resource that is baked into the app’s signature.

Those are far from universal across all protections, but can be inspected in the app using Apparency for verification purposes.

Apple’s reference lists

Info.plist keys
Entitlements

Articles in this series

Protected folders and places
Protected devices
Protection of location information
Protection of network devices, automation, and others

Appendix: Protection and lists

For macOS 15.3.1 Sequoia, protected resources are as follows.

Protected locations:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• Third-party cloud storage
• Removable volumes
• Network volumes via local network devices
• Time Machine backups.

Protected data:

• Calendars
• Contacts
• HomeKit
• Media & Apple Music
• Photos
• Reminders
• Focus
• Motion & Fitness.

Protected devices:

• Bluetooth
• Camera
• Input Monitoring, of mouse, trackpad, keyboard
• Local Network devices
• Microphone
• Screen & System Audio Recording
• Speech Recognition.

Protected features:

• Passkeys Access for web browsers
• Accessibility, control over the Mac
• App Management, to update or delete other apps
• Automation, control other apps, giving access to their data and documents
• Developer Tools, to run software that doesn’t meet macOS security rules
• Remote Desktop.

Possible list arguments for tccutil:

• Accessibility
• AddressBook
• All
• AppleEvents
• AudioCapture
• BluetoothAlways
• BluetoothPeripheral
• BluetoothWhileInUse
• Calendar
• Camera
• ContactsFull
• ContactsLimited
• DeveloperTool
• FileProviderDomain
• FileProviderPresence
• FinancialData
• FocusStatus
• KeyboardNetwork
• MediaLibrary
• Microphone
• Motion
• Photos
• PostEvent
• Reminders
• RemoteDesktop
• ScreenCapture
• SpeechRecognition
• SystemPolicyAllFiles
• SystemPolicyAppData
• SystemPolicyDesktopFolder
• SystemPolicyDeveloperFiles
• SystemPolicyDocumentsFolder
• SystemPolicyDownloadsFolder
• SystemPolicyNetworkVolumes
• SystemPolicyRemovableVolumes
• WebBrowserPublicKeyCredential

for use in
tccutil reset [list] [appID]
where [list] is one of the lists above, and the optional [appID] is the identifier of the app whose privacy settings are to be removed.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5290. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new Yara rule for MACOS.SLEEPYSTEGOSAURUS.SYM.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5290.

Sequoia systems only

This update has just been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5290 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

Hurrah!

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Updated 1840 GMT 11 March 2025, announcing iCloud release!

Apple has just released an update for macOS Sequoia bringing it to version 15.3.2. There are also Safari updates available for Sonoma and Ventura.

The update for Apple silicon is about 1.45 GB in size, while that for Intel Macs is around 600 MB.

Security release notes are already available, and list a single WebKit vulnerability, that Apple states is a supplementary fix for an attack that was blocked in iOS 17.2, and in iOS had been exploited before it was fixed in iOS 17.2.

Updated with Safari info, 1930 GMT 11 March 2025.

Since XProtect Remediator (XPR) went live during the summer of 2022, it has run daily sets of checks for known malware in macOS Catalina and later using its scanning modules. Those have been sufficiently regular and reliable that some of my apps, including Skint and SilentKnight, check that they’re occurring and report normal and healthy results. Just over a month ago, I provided a detailed account of XPR’s different types of scan, and how they are scheduled and dispatched in XPR version 149. Last week in XPR version 151, Apple changed all that, and Skint, SilentKnight and XProCheck may now show few scans and frequent warnings.

As Apple has never provided anything other than the vaguest of information about XPR, I have no idea whether this is the new normal, or the result of bugs. As XPR scans now vary greatly between different Macs, and run least on those with large numbers of Time Machine backups accessible, I’m inclined to suspect at least some of this is unintended behaviour.

XPR scans

There are still three types of timed scan:

• a fast scan, com.apple.XProtect.PluginService.agent.fast.scan, performed at intervals of 6 hours (21600 seconds), and run when on battery;
• a standard scan, com.apple.XProtect.PluginService.agent.scan, performed at intervals of 24 hours (86400 seconds), but not run when on battery;
• a slow scan, com.apple.XProtect.PluginService.agent.slow.scan, performed at intervals of 7 days (604800 seconds), but not run when on battery.

In the standard scan, each of the scanning modules is run in turn, once using the agent version running as the current user, normally 501, and once using the daemon version as root, user 0.

Fast scans do run every six hours, but don’t currently include any of the scanning modules, so leave little trace in the log. They are also run soon after starting up and logging in as a user, where they’re referred to as a startup scan when run as root, and a login scan when run as the current user, usually 501.

As a slow scan is only run once a week, I still haven’t been able to observe one.

With XPR version 151 installed, you’re likely to see the following sets of scans after user login:

• Paired startup and login scans, no scanning modules used, taking about 46 seconds for root and 9 seconds for user 501.
• Timed low priority scans as root and user, using just the Eicar scanning module, and taking about 2 and 1 seconds respectively.
• Timed standard scans as root and user using all the scanning modules, and taking around 175 seconds for root, and up to 600 seconds as user. These may be cancelled by the XP Timer firing, which kills the current scanning module and terminates that set of scans, leaving them incomplete.

Thereafter, every six hours a fresh fast scan is performed, and every 24 hours a standard scan is attempted, although the latter may be terminated without completing any scanning modules at all.

XP Timer termination

At varying times after the start of a standard scan running its sequence of scanning modules, they may be interrupted by the firing of the XP Timer, and you’ll see a sequence of entries in the log describing how that not only kills the current scanning module, but terminates the whole of that set of scans:
16.438 com.apple.XProtectFramework 34294 XP Timer fired, killing activity
16.438 com.apple.XProtectFramework 34784 Received SIGTERM, canceling running plugins then exiting
16.439 XProtectRemediatorAdload Cancellation handler called for reason: Dispatch recieved SIGTERM
16.442 XProtectRemediatorAdload {"caused_by"[], "execution_duration":0.0002809762954711914, "status_message":"PluginCanceled", "status_code":30}

It’s that status_message and status_code that is detected by XProCheck, SilentKnight and Skint, and reported there as a warning.

16.450 com.apple.XProtectFramework Finished system scan, ran as 501
16.451 com.apple.duetactivityscheduler COMPLETED <_DASActivity: "501:com.apple.XProtect.PluginService.agent.scan:BD32B7", Utility, 60s, [09/03/2025, 07:39:13 - 10/03/2025, 07:39:13], Started at 09/03/2025, 19:52:35, Group: com.apple.dasd.default, Intensive: CPU Disk, PID: 2254>
16.453 com.apple.xpc.activity Rescheduling: com.apple.XProtect.PluginService.agent.scan (0x653344140)
16.457 com.apple.duetactivityscheduler Completed <private>, ran for 9.7 mins, total runtime 9.7 mins

The next daily standard set of scans are then submitted to DAS for rescheduling, to be run in about 24 hours:
16.465 com.apple.duetactivityscheduler Submitted: 501:com.apple.XProtect.PluginService.agent.scan:15B497 at priority 30 with interval 86400 (Mon Mar 10 07:52:34 2025 - Tue Mar 11 07:39:13 2025)

Although referred to as the XP Timer, times when it will fire range widely, from a few seconds to nearly ten minutes, and there’s no indication of how that is determined.

Effects

XPR checks now differ greatly between Macs. Most basic systems running from their internal SSD with a minimum of external storage, with just a modest set of Time Machine backups, still appear to complete standard scans normally, as they did in previous versions of XPR.

Macs with multiple external disks and long series of Time Machine backups may now complete few if any standard scans. Instead, most or all of them are terminated prematurely by the XP Timer, so triggering warnings in XProCheck, SilentKnight and Skint.

If you wish to run a set of XPR scans manually, then you still can, either in XProCheck or by running the XProtect app yourself. Those are run as the current user, not as root, but may be sufficient to restore your confidence in XPR’s protection.

This leaves me with a dilemma: should those apps suppress those warnings and tell you that everything is fine with XPR’s checks, or should they continue to report them? Given all the problems with XProtect updates in Sequoia, would it be simplest just to abandon my attempts to check anything in macOS security? Are these bugs, and should they be reported to Apple, or is this the new normal we have to look forward to for the future?

Over the last nine years, few of my articles here have been about XProtect, other than those announcing its updates. Until September 2024 and the release of macOS 15 Sequoia. This is now the tenth article I have written about the problems brought by XProtect updates in Sequoia over those six months, when there have been just 13 updates. The result of the last, on 4 March, was that for two days afterwards, many Macs running Sequoia were still using its data from 26 February rather than that in the new version 5289.

This not only affects XProtect, but the other front-line tool in macOS to detect and remove malicious software, XProtect Remediator (XPR). Earlier this year, I reported that at least 17 of the 24 scanning modules in XPR now use Yara definitions provided by XProtect’s data. All those Macs still running the superseded version of XProtect would also have had XPR scans run using that old version of the Yara rules.

XPR is a recent addition to these tools, introduced just three years ago, but XProtect goes way back before Yosemite in 2014. Although there have been occasional brief glitches in delivery of its updates, they have almost invariably completed quickly and reliably, leaving very few Macs stuck with an outdated version 24 hours after an update.

I have now come to dread XProtect updates because of the problems we encounter, and the latest update to 5289 was a good example. There’s a flurry of comments and emails from those whose Macs had failed to complete the update, previously a rare exception. For XProtect 5287 on 5 February, for example, there were 33, including my responses. For version 2184 exactly a year earlier there’s not one comment about that XProtect update.

Sole documentation provided about XProtect’s updates in Sequoia is the man file for its command tool, xprotect, which refers only to updates provided via iCloud, and doesn’t explain how those delivered via the traditional mechanism in softwareupdate might be involved. Yet we know there is a relation: the latest update has still not been supplied via iCloud, not even four days later, but relied instead on XProtectUpdateService working with an update obtained via softwareupdate. Previously that could be invoked using the xprotect update command, but that no longer works, leaving users with two versions of XProtect data, of which the copy used by XProtect and XPR is the older.

Late last year, when xprotect update appeared to be working as expected, I decided that my app SilentKnight would need to use that command in order to download and install updates. As that requires elevated privileges, I have been looking at how to implement a privileged helper app to perform that. With the latest update, that approach would have failed until the version in iCloud had been brought up to date. Instead we’re now reduced to restarting our Macs and hoping that, some time in the next day or two, they might update.

There’s a further problem emerging with the updates of 4 March. Many users have noticed subsequent XPR scans being terminated before completion. Although in most cases that fault appears to go away in later scans, in some Macs it prematurely terminates every set of XPR scans, leaving several of its scanning modules unused.

For example, this iMac Pro has failed to scan using ten of its 24 modules. This occurs because XPR apparently runs a timer, and when a round of scans is deemed to be taking too long, that timer fires and brings XPR to an abrupt halt. Indications are this is most likely when there are many Time Machine backups accessible; as those are all immutable snapshots and haven’t changed since they were made months ago, this is strange behaviour, and hadn’t occurred prior to the updates of 4 March.

Six months ago, if anyone had told me that macOS security protection in Sequoia was going to become less reliable, I wouldn’t have believed them. The truth is that, for many, it now has. As things stand in 15.3.1, a Mac is now more likely to be using an out of date version of XProtect’s detection rules, and for XPR scans to detect and remove malware. And there’s nothing you can do about that until Apple returns to using an update mechanism that’s both timely and reliable. Is that really too much to expect of this front-line security protection?

Selected previous articles:

What is happening with XProtect updates?
XProtect tormentor
How XProtect has changed in macOS Sequoia
A simple guide to how XProtect installs and updates in Sequoia
XProtect has changed again in macOS Sequoia 15.2
What happened with XProtect?
What has happened to XProtect in Sequoia?

Macs and almost all devices assemble information about their location from local Wi-Fi networks, GPS systems (not Macs), and other sources. Access to location information in macOS is controlled in Privacy & Security settings, but unlike most of the items listed there it isn’t managed the same using TCC, but by its own service locationd in Location Services.

Tracking

In addition to those, Safari and other browsers include their own controls over tracking and location. In Safari, these are gathered in the Privacy section of its Settings, and the Location item in Websites. If you subscribe to iCloud+, you can access Private Relay in the iCloud+ section in your Apple Account.

Sharing and Find My…

Location Services are unique in that, when enabled, location data are invariably shared in iCloud, a feature you can’t control in iCloud settings. The only way to stop the sharing of locations across your iCloud-connected devices is to turn the whole service off, which is also true for iOS and iPadOS devices. Although it might seem tempting to disable Location Services altogether, that improved privacy comes at the cost of some valuable services: in particular, Find My… and Activation Lock, and many system services and apps also need Location Services to be enabled.

Settings

Location Services is the most complex of all the sections in Privacy & Security settings, and nests many of its controls deeply. This was inherited from the days of System Preferences, and hasn’t yet been redesigned to take advantage of System Settings. Above its last item, System Services, is a list of those apps over which you have direct control of their access to location data, although they can only be enabled or disabled and not removed from the list, neither can you add other apps.

Unusually, the About Location Services & Privacy button opens a window containing a mixture of help and privacy information, which is worth reading to give you better insight into what’s managed and how data is shared. It points out one important message: by giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not those of Apple. If your location data is sensitive, then you shouldn’t give third-party apps access to it unless you’re confident they will protect it appropriately.

Further important controls are revealed in another window when you click on the Details… button for System Services. This lists some of the purposes for which macOS uses location data, giving you fine control over them.

The final layer in this onion is revealed when you click on the Details… button next to Significant Locations: a listing of all those locations that macOS considers to be ‘significant’. On a static Mac with mobile iOS devices, those are largely based on location data gathered from those, and are mirrored in similar lists on each device.

If you’ve never inspected these Significant Locations, you may be surprised at how much detail they contain: exact location, shown on a local street map, with time periods, over the last few months. It might be possible to reconstruct a lot of your life and activities from them. This window allows you to clear its history, in case you don’t want anyone to know where you’ve been.

Internals

Behind these is the system service locationd and its database locked away in /var/db/locationd. The official description of locationd is that it obtains geographic location data and manages access to it. When you’re prompted to give access to location data, that’s the CoreLocationAgent in action on its behalf. Apps that can ask for location data from Location Services should have the com.apple.security.personal-information.location entitlement and provide NSLocationUsageDescription information, something you can check using Apparency.

The /var/db/locationd directory contains one file that’s simple to read and holds important information, clients.plist, and various opaque data files. A sub-directory /Library has a surprising collection of scripts and cached data.

clients.plist is a standard Property List containing a dictionary of all the apps and other software that could access Location Services data. Those that are currently granted access contain the key Authorized set to <true>. In general, these should match apps and other items in the Location Services list in Privacy & Security settings, although that doesn’t apply to public or private frameworks that are included. There’s also a flag available for the key Hide suggesting that some apps or services can be given access to locations but won’t be displayed in Location Services settings.

While other privacy protections can be managed by the tccutil command tool, there’s no equivalent for Location Services. Besides, clearing its database would affect a lot of system services, including Find My… and Activation Lock, with their wider security implications.

Because of the reliance of Location Services on hardware and network features, they don’t function in Virtual Machines running on Apple silicon Macs, even though you can opt to ‘enable’ them.

Summary

• Geographic location data is derived from Wi-Fi networks and other sources, and delivered in Location Services.
• Although controls are included in Privacy & Security settings, they work differently from others, using the locationd service rather than TCC.
• Location Services are required for Find My…, Activation Lock and other macOS apps and services.
• By giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not Apple’s.
• Significant Locations can give a detailed history of your movements.
• There’s no command tool to manage Location Services.

As those running macOS 15 Sequoia are only too painfully aware, the way that XProtect’s data is updated has changed from that still used in older versions of macOS. Instead of accessing that data in XProtect.bundle in the path /Library/Apple/System/Library/CoreServices, in Sequoia the data used is in /private/var/protected/xprotect. While the old location can still be updated using Software Update, SilentKnight and softwareupdate, the only way to update the copy in the new location is using the xprotect command tool, which normally obtains its updates through a connection to iCloud.

Updating in Sequoia

Since Sequoia 15.0, there has been a way to update data in the new location from XProtect.bundle in the old location, using the command
sudo xprotect update
If that finds a newer version of the bundle in the old location, it installs its contents in the new location, so updating XProtect in Sequoia. At least, it did until the release of Sequoia 15.3 or 15.3.1.

When Apple released XProtect version 5288 on 26 February, it did so through both connections, and all versions of macOS were able to update promptly and successfully. That didn’t work with its successor 5289 on 4 March, though. Although the Software Update version was successfully updated in the old location to 5289, no iCloud update was made available, and sudo xprotect update proved unable to update from that to the new location.

This has left those running Sequoia 15.3.1 with version 5289 in the old location, but 5288 stuck in the new location. As Apple doesn’t tell us of these updates, nor of how XProtect is supposed to work in Sequoia or earlier, it’s impossible to tell whether this is intended, or an unintended failure.

Which rules does XProtect now use?

One potential explanation is that XProtect has returned to using its old location for the Yara rules, in /Library/Apple/System/Library/CoreServices/ XProtect.bundle/Contents/Resources/XProtect.yara. That’s fairly easy to check in the log, where it states the location of the rules it’s using to check an app for malware. The answer is
com.apple.xprotect Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
that’s the new location for Sequoia, and hasn’t changed since 15.0.

How does macOS now update the correct rules?

By chance, a few minutes after I had started my Mac mini M4 Pro yesterday, I opened SilentKnight and discovered that XProtect had successfully been updated to version 5289, something it wouldn’t do the previous evening following its release. At that time:

• XProtect in its old location had been updated to 5289 the previous evening.
• SilentKnight now reported XProtect in its new location was 5289.
• sudo xprotect check reported the version in iCloud was still 5288.
• sudo xprotect update reported that it was already up to date.
• xprotect version reported that 5289 had just been installed, about 2.5 minutes after starting up.

This was an ideal opportunity to discover how XProtect had updated this time, by looking in the log with LogUI. That showed the update had been dispatched as a background activity by DAS, with ID com.apple.security.syspolicy.xprotect-update. That’s a scheduled background activity run every 24 hours, and in this case appears to have been dispatched because of the recent boot.

That activity connects to XProtectUpdateService, which then runs the check and updates as necessary, connecting to iCloud using CloudKit. On this occasion it ‘found’ the 5289 update, although maybe in its old location rather than in iCloud, and updated XProtect’s data in its new location.

How to keep XProtect up to date

From this experience, bearing in mind that everything might change again in the future, my advice is to:

• Check for updates as usual using SilentKnight, Software Update, or softwareupdate.
• When offered an update by any of those, install it gratefully.
• Run SilentKnight a few minutes later. If that update isn’t reflected in the version shown, restart your Mac and leave it for 10 minutes or so before checking again.
• If it still doesn’t update correctly, check again in about 24 hours, by which time DAS should have dispatched com.apple.security.syspolicy.xprotect-update with any luck.

I suppose that’s progress?

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5289, and to XProtect Remediator for all macOS from Catalina onwards, to version 151. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect add two new rules for MACOS.TAILGATOR.RST.CT and MACOS.TEPIDTEA.

XProtect Remediator doesn’t change the list of scanner modules.

There is a new Bastion rule 13 for the behavioural version of XProtect (Ventura and later). This watches for execution of PasswordManagerBrowserExtensionHelper in CoreServices, in the App Cryptex, and makes an immediate report with the Signature Name of macOS.PasswordExtension.Exec if that occurs.

You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-151 and XProtectPlistConfigData_10_15-5289.

Sequoia systems only

This update hasn’t yet been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5289 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

This version is currently only available via Software Update, softwareupdate, or in SilentKnight, and not via iCloud. If your Mac is running Sequoia and you download it that way, the xprotect update command might take a while to use that downloaded version to update your Mac properly. As a result, the version of XProtect shown may remain at 5288, but should later change to 5299.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Updated 1720 GMT 5 March 2025 following a ‘spontaneous’ update at 1631, although sudo xprotect check is still reporting the old version.

‘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.

Passwords and other secrets were little-used until the arrival of email and the Internet. Secure storage for them in keychains was developed for the PowerTalk mail engine in Apple Open Collaboration Environment (AOCE), and was first released in about September 1993, probably in System 7.1.1. When AOCE was dropped from Mac OS 8, keychains languished until their revival later that decade, and were probably first supported by the System in around 1999 in Mac OS 8.6.

Those early keychains were the ancestors of what’s now referred to as file-based keychains, in contrast to the data protection keychain that can be shared in iCloud. Although macOS Sequoia still supports classic keychains, their use was discontinued with the introduction of Mac OS X in 2001, when they were replaced with newer keychains supported by the SecKeychain API.

SecKeychains gained full support in Mac OS X 10.2 Jaguar in 2002, and ever since have provided the central login keychain still used in Sequoia over 20 years later. These are encrypted databases containing login credentials and other secrets. Each keychain can be unlocked using a single password, with that of the login keychain being the same as the user’s login password, enabling it to be unlocked following login.

With the introduction of iPhones and their iOS operating system, they didn’t use SecKeychains, but a new and more secure relative known as the Data Protection keychain, with a separate SecItem API. Although support for that was added in Mac OS X 10.6 Snow Leopard in 2009, it wasn’t until OS X 10.9 Mavericks in 2013 that Macs started using Data Protection keychains for their iCloud Keychain. Two years later, with OS X 10.11 El Capitan, SecKeychains and their ancestors were formally deprecated, although much of their APIs still remain.

Throughout Mac OS X and into macOS, the bundled tool for maintaining keychains has been Keychain Access provided in /Applications/Utilities. With the arrival of the iCloud Keychain, Safari provided access to passwords stored in the iCloud Keychain, and that was later augmented in a Passwords item in System Preferences and Settings.

Earlier versions of Keychain Access, such as that seen here in Mac OS X 10.4 Tiger in 2005, provided a valuable First Aid tool to verify and repair keychains. That was dropped some years ago.

After the introduction of iCloud Keychain, the login keychain has steadily lost importance. Here it’s seen at its zenith in Mac OS X 10.6 Snow Leopard.

This shows the login keychain again, in Keychain Access from OS X 10.10 Yosemite in 2014.

macOS Sequoia brought a dedicated app Passwords that only works with the Data Protection keychain, and relegated Keychain Access to /System/Library/CoreServices/Applications, where it can still be used to work with traditional file-based keychains as well.

login keychain

For each user, their default personal file-based SecKeychain is the login keychain, located in ~/Library/Keychains/login.keychain-db. This is unlocked automatically when the user logs in as it has the same password as that user account. It’s here that each user can still store certificates, secure notes, etc. for general use on that Mac.

Although kept unlocked, readable and writeable while the user is logged in, that doesn’t guarantee access to its contents. If an app makes a call to the macOS security system to retrieve a stored password for its use, that system determines whether the app is trusted to access that information, and whether that keychain is locked. Assuming the password is stored there, the app is trusted, and the keychain is unlocked, then the password is retrieved and passed back to the app. If the app isn’t trusted or the keychain is locked, then the security system, not the app, displays a distinctive standard dialog asking for the password to that keychain to authenticate before it will provide the password to the app.

Access to secrets is determined by the security system, the specific access it grants to an app, and to individual items in that user’s keychain. At its most restrictive, the system can limit all other apps from accessing a particular secret in the keychain, but specific secrets can also be shared across several different apps.

System keychains

For the system, there two two vital groups of keychains:

• in /System/Library/Keychains, in the SSV, are SystemRootCertificates and others providing the set of root security certificates for that version of macOS;
• in /Library/Keychains is the System keychain and others providing certificates and passwords required for all users, including those to gain access to that Mac’s Wi-Fi connections.

Data Protection keychain

Since OS X 10.9, Macs have also had one and only one Data Protection keychain that’s accessed using the SecItem API. If you share your keychain in iCloud, this is the local copy of that shared keychain and is known as iCloud Keychain; if you don’t share it in iCloud, then it’s known as Local Items instead. The local copy of this is normally stored in ~/Library/Keychains/[UUID]/keychain-2.db, where the UUID is that assigned to that Mac.

This Data Protection keychain stores all the standard types of secret, including internet and other passwords, certificates, keys and passkeys. Prior to macOS 11, it only synchronised internet passwords using iCloud, but from Big Sur onwards it synchronises all its content, including passkeys, which have now become first class citizens. Unlike file-based keychains, secrets in the Data Protection keychain can be protected by the Secure Enclave in T2 and Apple silicon Macs, and can therefore be protected by biometrics including Touch ID, and Face ID on iOS and iPadOS. Hence they’re required for passkeys, which can’t be supported by traditional file-based keychains.

Future

Much as Apple wants to support only the Data Protection keychain in macOS, there are still many that rely on the login and other file-based keychains. SecKeychain will thus remain supported reluctantly until macOS can finally call it a day on keychains that originated well over 25 years ago.

References

Apple TN3137: On Mac keychain APIs and implementations
Apple Keychain Services

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5288. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds two new rules for MACOS.TAILGATOR.UPD and MACOS.TAILGATOR.INLASCLDR.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5288.

Sequoia systems only

This update is also available for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then entering your admin password. If that returns version 5288 but your Mac still has an older version installed, you can force the update using
sudo xprotect update

This version is now available via Software Update, softwareupdate, or in SilentKnight as well. If your Mac is running Sequoia and you download it that way, rather than using iCloud, then once it’s installed you’ll need to run the update command for that to take correctly.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Making a CPU do more work requires more than increasing its frequency, it needs removal of obstacles that can prevent it from making best use of those cycles. Among the most important of those is memory access. High-speed local caches, L1 and L2, can be a great help, but in the worst case fetching data from memory can still take hundreds of CPU core cycles, and that memory latency may then delay a running process. This article explains some techniques that are used in the CPU cores of Apple silicon chips, to improve processing speed by making execution more efficient and less likely to be delayed.

Out-of-order execution

No matter how well a compiler and build system might try to optimise the instructions they assemble into executable code, when it comes to running that code there are ways to improve its efficiency. Modern CPU cores use a pipeline architecture for processing instructions, and can reorder them to maintain optimum instruction throughput. This uses a re-order buffer (ROB), which can be large to allow for greatest optimisation. All Apple silicon CPU cores, from the M1 onwards, use out-of-order execution with ROBs, and more recent families appear to have undergone further improvement.

In addition to executing instructions out of order, many modern processors perform speculative execution. For example, when code is running a loop to perform repeated series of operations, the core will speculate that it will keep running that loop, so rather than wait to work out whether it should loop again, it presses on. If it then turns out that it had reached the end of the loop phase, the core rolls back to where it entered the loop and follows the correct branch.

Although this wastes a little time on the last run of each loop, if it’s had to loop a million times before that, accumulated time savings can be considerable. However, on its own speculative execution can be limited by data that has to be loaded from memory in each loop, so more recently CPU cores have tried to speculate on the data they require.

Load address prediction

One common pattern of data access within code loops is in their addresses in memory. This occurs when the loop is working through a stored array of data, where the address of each item is at a constant address increment. For this, the core watches the series of addresses being accessed, and once it detects that they follow a regular pattern, it performs Load Address Prediction (LAP) to guess the next address to be used.

The core then performs two functions simultaneously: it proceeds to execute the loop using the guessed address, while continuing to load the actual address. Once it can, it then compares the predicted and actual addresses. If it guessed correctly, it continues execution; if it guessed wrong, then it rolls back in the code, uses the actual address, and resumes execution with that instead.

As with speculative execution, this pays off when there are a million addresses in a strict pattern, but loses out when a pattern breaks.

Load value prediction

LAP only handles addresses in memory, whose contents may differ. In other cases, values fetched from memory can be identical. To take advantage of that, the core can watch the value being loaded each time the code passes through the loop. This might represent a constant being used in a calculation, for example.

When the core sees that the same value is being used each time, it performs Load Value Prediction (LVP) to guess the next value to be loaded. This works essentially the same as LAP, with comparison between the predicted and actual values used to determine whether to proceed or to roll back and use the correct value.

This diagram summarises the three types of speculative execution now used in Apple silicon CPU cores, and identifies which families in the M-series use each.

Vulnerabilities

Speculative execution was first discovered to be vulnerable in 2017, and this was made public seven years ago, in early 2018, in a class of attack techniques known as Spectre. LAP and LVP were demonstrated and exploited in SLAP and FLOP in 2024-25.

Mechanisms for exploiting speculative designs are complex, and rely on a combination of training and misprediction to give an attacker access to the memory of other processes. The only robust protection is to disable speculation altogether, although various types of mitigation have also been developed for Spectre. The impact of disabling speculative execution, LAP or LVP greatly impairs performance in many situations, and isn’t generally considered commercially feasible.

Risks

The existence of vulnerabilities that can be exploited might appear worrying, particularly as their demonstrations use JavaScript running in crafted websites. But translating those into a significant risk is more challenging, and a task for Apple and those who develop browsers to run in macOS. It’s also a challenge to third-parties who develop security software, as detecting attempts to exploit vulnerabilities in speculative behaviour is relatively novel.

One reason we haven’t seen many (if any) attacks using the Spectre family of vulnerabilities is that they’re hardware specific. For an attacker to use them successfully on a worthwhile proportion of computers, they would need to detect the CPU and run code developed specifically for that. SLAP and FLOP are similar, in that neither would succeed on Intel or M1 Macs, and FLOP requires the LVP support of an M3 or M4. They’re also reliant on locating valuable secrets in memory. If you never open potentially malicious web pages when your browser already has exploitable pages loaded, then they’re unlikely to be able to take advantage of the opportunity.

Where these vulnerabilities are more likely to be exploited is in more sophisticated, targeted attacks that succeed most when undetected for long periods, those more typical of surveillance by affiliates of nation-states.

In the longer term, as more advanced CPU cores become commonplace, risks inherent in speculative execution can only grow, unless Apple and other core designers address these vulnerabilities effectively. What today is impressive leading-edge security research will help change tomorrow’s processor designs.

Further reading

Wikipedia on out-of-order execution
Wikipedia on speculative execution
SLAP and FLOP, with their original papers

Last week I attempted to draw distinction between the different systems that control access to files and folders, from permissions to privacy settings. This article continues with a more detailed account of how Privacy & Security works, through the macOS Transparency, Consent and Control (TCC) system. Its settings are probably the most extensive and complicated of all System Settings, and grow worse with each new version of macOS.

Many of the controls in Privacy & Security settings refer not to folders on your Mac, but concern access to private data or sensitive hardware. The list of folders and volumes that have restricted access in macOS Sequoia is extensive:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage, if used
• removable volumes
• network volumes
• Time Machine backups.

Consent and intent

Apple’s approach to privacy is founded on two basic user controls: user consent, and user intent. These are fundamentally different, and are used in different types of protection.

For an app to gain access to its built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that dialog may seem tedious and even pointless, the decision is yours and not the app’s or that of macOS. If the app is for web conferencing, then the dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps want camera access. If you simply click through every consent dialog, then you won’t catch rogue or malicious apps.

Protected locations are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder, or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one. So access to protected locations may require user intent or consent.

The result for protected locations generally appears in two settings:

• individual folders are set in Files & Folders,
• system-wide access is set in Full Disk Access.

You can’t add apps directly to Files & Folders, but you can give them Full Disk Access. The difference is in how they work.

Files & Folders

Take an example, my virtualiser Viable, which doesn’t do anything privacy-related, but does provide access to some protected folders. When first installed, it has no entry in Privacy & Security. When I try to run a VM, that accesses some protected folders. As I don’t select them in a file open or save dialog, or by drag-and-drop, I don’t express my intent to access those folders. When Viable tries to do so, I’m prompted to give consent for it to access the Downloads and Desktop folders.

If I agree to those, Files & Folders is changed, adding Viable to its list, with access to those two folders enabled. If I don’t like that, or trash that app, then it’s up to me to delete its settings there. Otherwise, the next time it won’t prompt me, as I’ve already given my consent.

In the case of Files & Folders settings, you don’t have to quit the app and open it again for these changes to take effect.

Full Disk Access

Instead of doing that, you could decide to give the app Full Disk Access, which goes far beyond those two folders. In most cases, you should avoid giving everything Full Disk Access, as you could then be caught out by a rogue app. This works differently in that you have to open Privacy & Security settings, and in the Full Disk Access list, click on the + tool at the bottom left to select the app and add it.

Unlike Files & Folders, if you change its setting while the app is running, you’ll need to quit the app for the change to register and take effect.

Once that’s done, my app is listed in the Full Disk Access section. You could then disable Full Disk Access, even delete the app from here, although in both cases that needs the app to be closed and re-opened for the change to take effect.

Single files

There’s a third possibility we haven’t seen here: what if I want to use an app to edit files in a protected folder like ~/Documents? So long as I show my intent using features like file open and save dialogs, then that should go unchallenged, and you won’t be asked to give consent for the app privacy settings to be changed.

Command tools

This is fine for regular apps, but what about command tools, as they don’t have a GUI interface? Here the rules are applied through an attribution chain, based on which app called the tool to be run. In most cases, that means Terminal’s privacy settings. So if you want tools there to have access to protected folders, you’ll normally need to give consent by adding Terminal to Full Disk Access settings.

Exceptions

Unfortunately, macOS also applies some additional restrictions on locations that can be used for specific actions. For example, you can use the log collect command to save a copy of the Unified log to a logarchive for later analysis, but if you specify a path to an external disk, then the command fails, as it can’t be saved on external storage. You can, however, save the logarchive to internal storage, then move or copy it to external storage.

Summary

Rules for access to protected folders:

• If the user shows explicit intent, access is normally granted.
• If the app performs access without the user showing explicit intent to use a file in a protected folder, and the app doesn’t have Full Disk Access, then the user is prompted and that app added to the Files & Folders list to allow access to that specific folder.
• If the app needs consent for more general access, give it Full Disk Access.
• For command tools, treat Terminal as setting their access.
• Privacy controls work on top of permissions; if you or your app don’t have permissions, then privacy can’t overrule that.

Last week, in a quiet village nestling between golf courses in the Green Belt of Surrey, to the south of London, a huge void opened up in its High Street. Some of the older locals recalled there were old mine workings in the area, making it plausible that sinkhole may be due to the collapse of those abandoned mines or tunnels. What has shocked the residents of Godstone is unfortunately not uncommon, the result of failure to restore the land and what’s under it before developing on top.

Last week, after a long period of deliberate abstinence, I returned to the subject of permissions, privacy and security protections, and how they conspire to prevent us from accessing our own documents and files. In this case, there’s a warren of underground tunnels that can collapse when you’re least expecting it, although most aren’t disused but still active and poised to turn into voids of misunderstanding.

Privacy controls over locations started in macOS Mojave back in 2018, and ~/Desktop, ~/Documents, ~/Downloads, removable volumes and others were added in Catalina the following year. These have become so “transparent”, to use Apple’s well-worn euphemism, that developers have criticised them relentlessly since, and most users are still completely at sea with them, over five years later.

Apple’s Mac User Guide for Sequoia now lists 32 protection categories from Location Services to Lockdown Mode, but explains remarkably little. It passes over in silence the distinction between settings for Files & Folders and those for Full Disk Access. Presumably it leaves each individual app with the task of explaining those to the user, in the context of that app’s potential access.

This is the extent of its current explanations for users:

• Files & Folders “allow apps to access files and folders in different locations on this Mac. The listed apps have requested access.”
• Full Disk Access “allows apps to access all files on your computer, including data from other apps (for example, Mail, Messages, Safari and Home), data from Time Machine backups and certain administrative settings for all users on this Mac. To add an app, click the Add button, select the app in the list, then click Open.”

For once, information given in Apple’s Platform Security Guide is briefer, and it does come a bit closer to making that distinction, even if it avoids using the term Full Disk Access, and muddies the waters by referring instead to “full internal storage access”, which isn’t accurate.

Nowhere does Apple explain how those privacy settings interact with permissions, or any of the unexpected behaviours that we’ve become used to since Mojave. For example, some still report that an app that has been able to open a document without problems is unable to save that document, even though that file and its folder have appropriate permissions set. This has been associated with documents whose default app has been changed from that set for that document type, and undocumented extended attributes such as com.apple.macl, which is even protected by SIP to prevent the user from trying to rectify the behaviour.

For developers, there’s a long series of WWDC presentations reporting the many changes that have been made to extend privacy protection without addressing its user interface, and Apple’s Developer Forums. But if your app wants to discover whether it has been given Full Disk Access by the user, “Except in very limited circumstances, there’s no good way to:

• tell if you have the Full Disk Access privilege
• explicitly ask for the privilege.”

What if alongside its concerted effort to deliver us Apple Intelligence, it were to devote a little time to design and implement a consistent and integrated interface to permissions, privacy constraints and other limitations to what we can open and save on our Macs, and deliver it in the Finder rather than by trial and error? If Apple doesn’t address this soon, these cracks could open up like that sinkhole in Godstone.

Exactly two weeks after we had dutifully updated to Sequoia 15.3, and its parallel security updates for Sonoma and Ventura, we were going through the process again for 15.3.1, 14.7.4 and 13.7.4. Those were unscheduled security updates, with the only information from Apple being that they include “important security fixes”. Even Apple’s security release notes reports for each that “this update has no published CVE entries”.

Having scoured Apple’s site and many others, I have drawn a complete blank as to what those updates fixed. I even watched nearly ten minutes of HalfManHalfTech, who claimed to show “some key highlights, New Features and New Changes in macOS 15.3.1 Sequoia”, but I remained none the wiser, and could count those promised new features and new changes on the thumbs of one foot.

My own analysis, based on comparing version and build numbers for bundled apps and the whole contents of /System/Library, was almost as barren. Apple silicon Macs had a firmware update, taking iBoot from version 11881.81.2 to 11881.81.4. Safari remains at version 18.3 (20620.2.4.11.5), and the only change apparent is that Messages had single minor build increment, from 14.0 (1402.400.131.1.2) to 14.0 (1402.400.131.1.3), which eluded even HalfManHalfTech.

The absence of CVE entries doesn’t mean that these updates didn’t fix any vulnerabilities, though. The Common Vulnerabilities and Exposures (CVE) scheme sets out to identify and monitor publicly known vulnerabilities and exposures, particularly those discovered and reported by third-party researchers. There’s no obligation or expectation that Apple should assign CVEs to vulnerabilities that it discovers in-house, and apparently don’t come to the attention of anyone outside.

In the past, Apple used to assign CVEs to many vulnerabilities discovered by its engineers. Looking back at previous security release notes, I noticed those for OS X Yosemite 10.10.3 of 8 April 2015, listing a total of 79 CVEs that were addressed. Of those, 36 were in open source components, leaving 43 in OS X itself. Apple credited its own engineers for reporting 6 of those, and in a further 4 no credit was given in the release notes at the time.

Over the last few years, precious few entries in macOS security release notes have cited CVE entries credited to Apple. This implies that either Apple’s engineers are now detecting very few vulnerabilities, or that those they detect are seldom being entered as CVEs. I’m inclined to believe the latter, and the release of 15.3.1, 14.7.4 and 13.7.4 updates confirms that suspicion. It may be that in the coming weeks, Apple does release more details as to what has been fixed in these security updates. It’s not unusual for it to issue revised release notes some time afterwards, providing information that it decided not to make public at the time of the update.

There’s currently a lot of attention focussed on Apple’s responses to two families of attacks that abuse speculative features of the CPU cores in M-series chips. Almost a year ago a team of seven researchers made public GoFetch, shown to be capable of revealing encryption keys, but not those kept inside the Secure Enclave. Late last month a team from Georgia Tech and Ruhr University Bochum published details and demonstrations of SLAP and FLOP enabling memory leakage in M2 and M3 chips.

There’s no evidence at present that any of those has been exploited in malicious software, and it’s also far from clear whether they’ll ever be used against us. Although a triumph of security research, in the pragmatic world of the attacker, they’re several orders of magnitude more difficult than deceiving the human, the weakest link. While I’m looking forward to Apple addressing GoFetch, SLAP and FLOP, we should remain more concerned with those mundane vulnerabilities that are already both popular and effective. If you’re unsure what those are, Patrick Wardle’s analysis of new macOS malware of 2024 is a worthwhile reference.

Does it matter whether Apple lists them as CVEs in release notes? In practice, relatively little, as the message remains the same: keep macOS up to date and never drop your guard. Some of the most important fixes are released in these ‘minor’ updates, and we may well have another month to go before the next macOS updates are released. If you haven’t updated yet to 15.3.1, 14.7.4 or 13.7.4, please do so today.