If you’re already running Catalina, you’re sure to have noticed that it makes a big thing of privacy, even more so than Mojave. Over the next few articles, I’m going to try to explain how 10.15 has changed, how you can manage its privacy protection, and how to cope with its glitches and problems. This first article explains the principles, and what the user should experience when all is working properly.

Privacy and security are different, although interrelated. You can’t protect a user’s privacy without having good security in place, but privacy protection isn’t just concerned with keeping malware out of your sensitive data. Over the last few years, the greatest concerns over privacy have arisen with apps and services which aren’t intending to be malicious as such, just profligate with your private data, usually to sell it on to enable advertising, for example.

Macs already use permissions to protect some data, but they’re a blunt tool. If I enable Location Services, for example, the information it stores about my location is private. But that’s going to be kept in locations like the Library folder in my Home folder (~/Library), and all the apps that I run have access to that. So what’s to stop any other app that I run from accessing my location data, even though I may not be aware of that happening?

The aim of Catalina’s privacy system is to segregate facilities, such as any built-in camera, microphone, and screen recording, so that only the apps that I trust can access them, and to do the same for data collections, files and other documents. As you might guess, that turns out to be more complex than it sounds.

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 your 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, it lets you make that decision. 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 the apps which do want camera access. If you simply click through every consent dialog, then you won’t catch the rogue PUP, for instance.

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 implied: 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.

Protected services and locations break down into the following categories:

• Recording systems, such as camera and microphone
• Data requiring user consent to access, such as Contacts and Calendars
• Locations requiring user intent or consent, such as your Desktop and removable volumes
• Data managed by the system, such as Mail and Messages
• Automation services, including Accessibility and AppleEvent Automation
• System security policy exemption, for developer tools.

I’ll take these one at a time.

Recording systems include:

• Camera
• Microphone
• Screen Recording (new in 10.15)
• Input Monitoring (keyboard, keylogging)(new in 10.15)

These are controlled by user consent: the app has to ask macOS to be able to use the specific system, and you then have to consent to it gaining access. The requesting app is then added to the respective list. Screen recording and keylogging may appear less valuable, but can of course be used to capture other protected information, even passwords. They’re also common features of malware.

Data requiring user consent to access includes:

• Contacts (address book)
• Calendars
• Reminders
• Photos (Photos libraries)
• Location Services
• Speech Recognition (using Apple’s voice to text service)

Each of these has its own list, and user consent is required for each before it can be added to its list.

Locations which require user intent or consent to access, which are all new for 10.15, include:

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

The aim with these is that, when an app tries to access them using standard File Open and File Save dialogs, by double-clicking in the Finder, dragging and dropping, or similar actions which work via LaunchServices, then user intent is clear, and you shouldn’t see a consent dialog. However, there are some circumstances in which code can trigger one, unfortunately. These are also controlled by the Full Disk Access list, and reflected more specifically in the Files and Folders list.

Data managed by the system, requiring user consent to access, includes:

• Mail
• Messages
• Safari’s browsing history
• Cookies
• Call history
• iTunes backups of devices
• Time Machine backups
• Trash (new in 10.15)

Access here is controlled by the Full Disk Access list. Access to the Trash folder is complex, as the user can still of course move items into and out of the Trash, as can an app, but other apps need consent through Full Disk Access.

There are just two automation services:

• Accessibility – ‘Synthetic input events’ as used to control apps by ‘pretend’ mouse clicks and keypresses
• Automation – AppleEvents, which are used to control other apps

These get complex: the first category covers some techniques used in accessible software, but can also be abused by malware, while the latter covers the situation where one app controls another in an explicit pairing. This makes obtaining user consent tedious, as each pairing must have specific consent.

There is just one system security policy exemption, Developer Tools, such as Xcode, which need to run code locally which may not meet normal security policy. If you don’t have Xcode installed, then you’re unlikely to see this item in the Privacy lists.

This account has so far considered only apps with a GUI. The same rules also apply to command tools and scripts, and in those circumstances the privacy system uses an Attribution Chain to look for a way of obtaining user consent where possible. If you type a command into Terminal, for instance, the command tool itself may be in the appropriate privacy list, or Terminal may be, and consent may then be attributed from that.