Why all this privacy protection? An overview
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
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.
