For the great majority of Mojave users, its new stringent privacy protection may pass almost unnoticed. If the apps that you run don’t try to access newly-protected private data, you will hardly notice the change. That doesn’t mean to say that the protection is wasted, just that it will get on with doing its job quietly.

If you use third-party apps and other tools which do look in protected folders, or which use restricted features such as controlling other apps using AppleEvents, then you can save yourself a lot of potential trouble with a little planning and preparation, which this article explains.

What is protected in Mojave?

Apple has set out lists of different categories, including two classes of app data, services and devices, and the field of automation.

App data is the simplest to understand. The following have class-specific protection:

• Contacts (Address Book) – the contents of ~/Library/Application Support/AddressBook
• Calendars – the contents of ~/Library/Calendars
• Reminders – often bundled with Calendars, sometimes considered separately
• Photos – .photoslibrary files in ~/Pictures.

These have individual listings in the Privacy tab of the Security & Privacy pane, but limited controls there which only allow you to disable items which macOS adds to that list.

The following have more generic protection:

• Mail – the contents of ~/Library/Mail
• Messages – the contents of ~/Library/Messages
• Safari browsing history – the contents of ~/Library/Safari
• Cookies – the contents of ~/Library/Cookies
• iTunes backups (when present)
• Time Machine backups – all your backup folder
• Miscellaneous – the contents of ~/Library/HomeKit, ~/Library/IdentityServices, ~/Library/Metadata/CoreSpotlight, ~/Library/PersonalizationPortrait, and ~/Library/Suggestions, most of which are new to Mojave.

These don’t have individual listings in the Privacy tab, but are normally included when Full Disk Access is granted.

Protected devices and services are:

• Location services
• Camera, built-in
• Microphone, built-in.

These have individual listings in the Privacy tab, but limited controls there which only allow you to disable items which macOS adds to that list.

App automation such as scripting other apps and controlling them using AppleEvents is more complex. Clearly there would be no point in introducing the extensive protection above if all an app had to do was to ask Mail to reveal the contents of various messages. But getting the level of protection and access controls right is difficult, and still evolving. If you use apps which rely on controlling other apps, keep a watch on their support site or blog, where their developers should be giving specific advice to help you use them in Mojave.

How does its protection work?

Mojave’s protection system, TCC (for Transparency Consent and Control), has to work with old apps, built before these controls were implemented, and new ones, which may have the protection of being App Store apps, or can be ‘hardened’ and notarized. To cope with this wide range, its rules may appear complex, so I have sketched them out in a diagram which explains what happens when an app tries to access protected data.

The various classes of protected data are shown at the left, those in red being covered explicitly in the Privacy controls. The first step is to determine whether the app trying to access protected data is signed by Apple: if it is, access will be determined by private controls, and sometimes regular controls as well. That makes sense, as it would be daft to have to give consent before Photos could open its own library.

Apps developed by a third party are checked to see whether they already have access to that particular class of protected data according to the Privacy settings. If they have, access is then granted without any further dialogs or delay. Note that the effect of adding an app to the Full Disk Access list is to give it access to all protected data (not services or hardware, though) without any further consent being sought.

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

If you give consent, then that app will be added to the appropriate class in the Privacy settings; if you decline, then it will be denied access, but isn’t put on any sort of blacklist, so you can still give consent on another occasion.

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

If the app does contain a usage statement appropriate for that class of protected data, then Mojave will display the consent dialog, this time containing the text from that usage statement as well. If you give consent, the app will then be added to the list in Privacy in the normal way.

App entitlements are quite different from usage statements or consent, and are built into apps which are either delivered through the App Store (as they always have been for all sorts of system resources), or those which are specially ‘hardened’ and normally notarized. Notarization is an optional process intended to enhance trust in apps which aren’t supplied through the App Store. Those apps cannot be given access to protected data, services, or hardware for which they don’t have an entitlement, even if they contain an appropriate usage statement, but you should still be able to add them to the Full Disk Access list if you wish.

Although it is macOS which determines whether to invite your consent to an app accessing protected data, it cannot bypass the consent step for third-party apps. Third-party apps can’t sneak past and gain access without your being asked for approval. The exception to this is when you add an app to the Full Disk Access list: when on that list, and ticked as having active approval, you will not be prompted for user consent when that app accesses protected data.

You thus control what is added to most of the class-specific Privacy lists by giving consent, but you cannot yourself decide to add an app to any of those. The list which you do control completely is that for Full Disk Access, which (for the moment at least) is not one that an app can directly request.

Every app listed in those Privacy lists can have its access restricted, and this is an important control which you should use for your own benefit. Let’s say that you need to let an app access your address book, but only the once. You can consent to its doing so, and it will be added to the Contacts lists in the Privacy tab. Once it has completed that task, you can and should then open the Security & Privacy pane and remove its tick in the Contacts list, which will force it to seek your consent again should it ever try to access your address book later.

You can also uncheck or remove apps from the Full Disk Access listing, if you want to deny them all access for the time being.

I have a free tool which will reveal the usage information, entitlements, and the version of the SDK against which an app is built: Taccy is available from Downloads above. It not only runs in Mojave, but in Sierra and High Sierra too, so you can use it to check apps before you have even upgraded to Mojave.

Planning for privacy protection

Although you can just leave this all to work out, privacy protection can cause some strange effects, and could get in your way. Apps which haven’t been given access to protected data will show it as if the protected folders have incorrect permissions, for instance when you try to open a file. In some cases, for example when scanning a folder, protected areas will simply be omitted; in other cases, you could find an accessing app suddenly crashes.

When you have upgraded to Mojave and you’re setting your preferences up, spend a little while adding apps to the Full Disk Access list in the Privacy tab. Don’t add everything that could possibly want to access any protected data, though: only include those which normally need to have such access.

Also consider those apps which run command tools: Terminal is an obvious case, but if you use other apps to run commands or shell scripts, they may well need to be added to Full Disk Access too. This is because TCC uses an Attribution Chain when assessing whether to give command tools and similar non-apps access. That chain normally rises until it hits a proper app, which is then expected to control access to protected data. Mojave will try to walk you through this process when a command is run, but this can be usefully anticipated and Full Disk Access granted.

TCC and its privacy protection are likely to evolve substantially as they become widely used in Mojave. I’ll be surprised if they remain unchanged over the next six months, as Apple and developers tune it to maintain protection for users without prejudicing functionality.

Because the user can’t add apps to most of the lists in the Privacy settings, if a developer doesn’t provide the right usage information in an app built against the 10.14 SDK, it can lock that app out of being able to access some classes of protected data unless it is given Full Disk Access.

The fallback here is to give that app Full Disk Access, which overrides the narrower class lists. But you may not wish to give it access to some other classes of protected data. In that case, it might be worth keeping access to a copy of the last version of that app to be built against the 10.13 SDK: as TCC is more relaxed in its requirements for such older versions, this could allow you to get an app approved and consented into a Privacy listing even though a later build against 10.14 doesn’t support it. So long as that older version has the same app ID as the current one, inclusion should work for the newer version too.

The general workaround for any app which appears unable to access protected data is to manually add it to the Full Disk Access list, which works for apps built against any version of the SDK, irrespective of the usage information provided.

The greatest uncertainty remains over apps which control other apps using AppleEvents. Some superficial interactions, such as showing a file in a Finder window, shouldn’t have any privacy controls, but quite a few apps engage in much more intimate collaboration. This is likely to see greatest change in the first versions of Mojave, and you should keep a careful watch on the developers’ support sites for further information. You may wish to keep to an earlier version of the app until any problems have been resolved.

Finally, remember that giving your consent (or refusal) is not irrevocable, done and dusted. You the user remain in control of which apps can access which protected data – the whole purpose of these changes. During your early use of Mojave, check the Privacy settings at least once a day until you are happy that little is changing. If you don’t like what you see there, don’t hesitate to change it. It is good practice to withdraw your consent from many apps once they have got the information that you are prepared to give them. And please read the consent dialogs carefully, or you will be caught out when you simply click through them.