One of the most confusing changes in Catalina’s privacy protection are the new locations which are now protected, including ~/Documents and removable storage. This is because macOS uses complex mechanisms to minimise the impact on users, particularly to avoid consent dialogs. To explain these, Apple uses the concept of user intent.

When an app decides it wants to access your camera, or to look through the cookies stored by Safari, you may have initiated that yourself and be fully aware of the request, but more often than not you aren’t. In those circumstances, macOS has to presume that you’re not fully aware of what the app has requested, and you’re prompted to give your consent in a dialog which should contain custom text explaining why this is needed by the app.

When apps come to read and write files, the situation is different. In the great majority of cases, you are in control of what is happening, expressing your intent explicitly through a standard Open or Save File dialog. Adding any form of consent dialog to that would be absurd.

But there are occasions when apps and other software work in and through folders which contain many personal documents, like ~/Documents, and could for instance be harvesting content from them without our knowledge. These new location protections are aimed to prevent just that sort of behaviour, and ensure that our consent is sought for software to access what it wants in the following locations:

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

When this protection works as advertised, you can open and save documents to any folder for which you have appropriate permissions, using any app, and won’t be prompted for consent, or any form of confirmation. Neither should you need to add those apps to any list in Privacy. This should apply when using access methods which work through LaunchServices, including

• standard Open File, Save File and related dialogs
• double-clicking a document
• the Open Recent command
• dragging and dropping the document onto the app in the Finder or Dock.

In other circumstances, for instance an app which itself gets a directory listing of a folder and then works systematically through its contents accessing those files, as soon as TCC detects that this is happening without user intent, you should be invited to consent to this activity, and add that app to the Files and Folders list, for specific access to that folder. That dialog may contain some custom explanatory text, if provided by the app, and has distinctive icons.

When you have given your consent, the app is added to the Files and Folders list, giving you individual control over which folders that app can access without your expressing user intent.

Where you know that an app is going to want to access files in these new protected locations, you can pre-empt the process of obtaining consent by adding the app to the Full Disk Access list instead. However, unlike obtaining consent for individual protected folders, Full Disk Access is broad spectrum, and covers all the new locations and those which have been protected since Mojave.

If you give an app Full Disk Access, that should also override any existing more limited access to individual folders, and replace those in the Files and Folders list. When TCC’s database is extensive, macOS can take its time to show that, and for a while you may see both forms in the list. Furthermore, when an app has had individual locations listed and then has Full Disk Access enabled, disabling Full Disk Access may revert to the individual locations, although they should all be turned off by default. This can become confusing.

As of Catalina 10.15.2, there also appear to be bugs in this system. In some circumstances, apps which aren’t included in the Full Disk Access or Files and Folders lists can be given free access to protected folders as if they were listed, or perhaps they’re listed in TCC’s database but omitted from the lists displayed to the user. In other situations, access to some locations, notably removable volumes, is immutably barred to some software, no matter what you try giving Full Disk Access to.

Some of these quirks and bugs may relate to a supporting technology which appears intended to ensure that, no matter where a given document is moved, and what changes are made to the privacy lists, the app used to edit it retains access – per-document privacy control. Apple hasn’t explained this, but it appears to depend on attaching a new extended attribute of type com.apple.macl to the document. Within that, those apps which retain editing rights to that specific document are identified by a UUID, and the extended attribute is protected from removal using SIP.

Currently, this system is so complex that it appears unpredictable. Sometimes everyday apps like Preview decide that they’re unable to overwrite an existing document. Saving documents from many apps, including those running in the sandbox, results in the new extended attribute being written to them, but other apps can write documents which don’t have that extended attribute at all.

The end result should be that, almost all the time, these new protected locations shouldn’t result in any additional consent dialogs or other intrusions. However, if you use apps which can crawl through folders accessing their contents, you will either have to give them Full Disk Access (if you haven’t already done so), or wait until prompted to give them more specific access in a consent dialog. If the Files and Folders list doesn’t appear to be working correctly, give it a little time to catch up, try restarting, or in the extreme take to tccutil to try to rectify it.