Apple pre-releases some of the components for the next major version of macOS in the previous version. For example, when macOS Monterey 12.3 was released on 14 March 2022, a new XProtect.app bundle appeared in /Library/Apple/System/Library/CoreServices, and passed almost unnoticed until it was updated to version 2 in macOS 12.4 on 16 May 2022. By June that was being updated frequently, and is now a significant part of macOS protection against malware.

This article looks back at versions of Sequoia that have brought new components to identify those we might see more of next month, when the first betas of macOS 16 reach developers.

Officially announced

One new feature that Apple has already made available in macOS 15.4 and later is privacy control of access to the pasteboard, described here. It’s likely that a new Pasteboard item will be added to Privacy & Security settings in macOS 16, allowing you a choice between:

• automatically allowing all pasteboard access without notifying the user (as previously);
• always denying all pasteboard access, unless the user explicitly chooses to access the pasteboard for pasting;
• asking the user for permission to grant pasteboard access, although that will automatically be granted when the user explicitly chooses to access the pasteboard for pasting;
• the default, to ask the user for permission when an app rather than the user seeks access to the General pasteboard; all other pasteboards would always allow access.

This appears complicated, and I expect may need simplification during beta-testing, or users could be baffled. Apple’s note details a default setting you can use to preview this behaviour in macOS 15.5 for individual apps in testing.

To celebrate the 40th birthday of its accessibility support, Apple has announced some new features we can expect in macOS 16. Among them is a Magnifier app that will use an iPhone running iOS 19 through Continuity Camera as a live video magnifier. Others include:

• Vehicle Motion Cues, already available in iOS and iPadOS;
• Braille Access, a full-featured braille note-taker;
• Accessibility Reader, to make text easier to read across a wide range of disabilities.

New apps

macOS 15.5 introduces a new app in CoreServices named Apple Diagnostics. This is currently non-functional, but appears to give access to some form of online diagnostic service in the future.

New kernel extensions

Three kernel extensions to watch for in macOS 16 are:

• AppleDisplayManager, introduced in 15.2, and still at version 1.0
• AppleAOP2, introduced in 15.4, and still at version 1.0; AOP is the Always On Processor in Apple silicon Macs;
• AppleProcessorTrace, introduced in 15.4, and still at version 1.0.0.

New public frameworks

Two were added to 15.4, and remain at version 1.0, for CLLogEntry which appears to be part of Core Location, and SecurityUI which hasn’t yet been mentioned anywhere.

New private frameworks

Many new private frameworks have been added by updates to Sequoia. Although most of these remain at their initial build of 1.0, some have seen surprising increases, including:

• AppSystemSettings, introduced in 15.2, now at build 3.3.5
• CryptexKit and CryptexServer, introduced in 15.4, now at build 493.120.7
• DeepVideoProcessingCore, introduced in 15.4, now at build 1.17
• various GameServices, introduced in 15.4, and already at build 819.4.46
• OSEligibility, introduced in 15.2, now at build 181.120.32.

Among the new private frameworks with intriguing names that remain at their initial version are: Bosporus, Morpheus and MorpheusExtensions, an OnDeviceStorage group, and most recently CodableSwiftUI.

Your guess is no doubt better than mine as to what these all do, but I expect some of them will appear in macOS 16, in one guise or another.

Irish investigators said TikTok did not protect the data of users in the European Union, improperly transferring some of it to China. TikTok said it would appeal.

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.

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.

So far in this series explaining how you can control access to potentially sensitive features and data in macOS, I have covered the following topics:

• Gaining access to privacy-protected folders,
• Managing privacy-protected devices,
• Managing access to location information.

This article rounds those off with a brief survey of other privacy controls, including an account of the newest of them all, over local network devices.

Additional privacy controls

There are several controls over specific classes of data, including

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

These are normally the preserve of specialist apps that are required to seek your explicit consent, and are controlled in their own entries in Privacy & Security settings. General access to their files can be given through Full Disk Access as well, where appropriate.

There’s a final group of controls whose purposes overlap more, and as a result may appear confusing:

• Passkeys Access for Web Browsers, required if you want a third-party browser to use passkeys for authentication.
• Accessibility, allowing control over your Mac, as in Automator and AppleScript. These can be added manually.
• App Management, allowing an app to update or delete other apps, which can be added manually.
• Automation, allowing control over other apps, so giving access to the data and documents within controlled apps, and to perform actions with them, but that doesn’t include Automator itself.
• Developer Tools, required to run software locally that doesn’t meet macOS security rules such as the requirement for notarization. This is primarily for developers, and can be added manually.
• Local Network, allowing access to network devices, as described below.
• Remote Desktop, allowing access to the contents of the screen.

As with other controls, these are all managed by TCC, and their individual lists can be cleared and reset using the command
tccutil reset [list]
where [list] is one of the following:

• Accessibility
• AddressBook (for the Contacts list)
• AppleEvents (for the Automation list)
• Calendar (note the singular, for the Calendars list)
• ContactsFull
• DeveloperTool
• FocusStatus
• MediaLibrary
• Motion
• Photos
• Reminders
• RemoteDesktop
• ScreenCapture

Local network privacy

This is one of the latest, introduced in macOS Sequoia. Although common to macOS, iOS, iPadOS and visionOS, it doesn’t work the same in each. It’s explained in TN3179 of 31 October 2024, and seems likely to evolve in the future.

Many apps access remote locations outside your local network; currently there are no privacy restrictions imposed on those, but code that accesses devices inside your local network, including your router, comes within the scope of this control. Some apps that work with devices on your local network do so using code that’s automatically given local network access because it’s a Launch Daemon or running with root privileges. Together with command line tools run in Terminal or over SSH, those aren’t controlled by TCC.

Regular apps and other code that attempt to access the local network will result in the user being asked to give their consent. While apps are invited to provide the text to be used in this dialog, in an NSLocalNetworkUsageDescription in their Info.plist, at the moment that isn’t enforced as a requirement, nor is there a required entitlement. You’re thus unable to verify whether an app should be expected to request access to local network devices.

This can apply to any app that tries to list other devices on the local network, whether over wired Ethernet or Wi-Fi. Those that also access Bluetooth will additionally request that, in a separate consent dialog.

Those who know Bryan Christianson’s excellent network utility WhatRoute may already have discovered that opening it for the first time in macOS Sequoia results in a privacy consent dialog. This might appear puzzling for an app that’s all about Internet connections, but as it does look at your router and can be used within your local network, macOS includes it within this new privacy category.

For the moment, Apple doesn’t appear to provide a service name that can be used with tccutil to reset its privacy settings, and disabling them in System Settings doesn’t remove them from the list. If you really need to reset that list, you’ll have to use
tccutil reset All [appID]
with the appID of each app that has already been given access.

Finally, because of the problems with network controls in early versions of macOS Sequoia, don’t rely on local network privacy in releases prior to 15.3.

Summary: local network privacy

• Sequoia introduces consent dialogs for access to devices on the local network, including routers, via Ethernet or Wi-Fi.
• This doesn’t apply to connections made to remote locations on the Internet.
• Launch Daemons, code running with root privileges and command tools in Terminal or via SSH aren’t affected.
• Access by other apps may result in a consent dialog, and an entry in Privacy & Security settings.
• Currently tccutil can’t reset all local network privacy settings in a single command.