First there were permissions, which determine which users and groups can access files. Then in Mojave, Apple added privacy protection, which applied additional access limits to certain stores of sensitive data on your Mac. Now in Catalina it might appear that almost every document is protected, although most apps seem to work as they did before. This article looks at some of the new classes of files which are protected in macOS 10.15, in particular those in your Documents folder.

When Apple first announced this in Kelly Yancey’s presentation in session 701 of WWDC 2019, there was considerable confusion as to exactly what this meant. Some had visions of being constantly prompted by everyday apps to grant them access to regular documents: that isn’t what this is about.

The principle is quite straightforward. The majority of user actions which open documents – using the Open command in an app, double-clicking the document, and so on – are handled by LaunchServices, and should continue to work as they always have done. This part of privacy protection is mainly concerned with apps and other software which don’t result in the user choosing to open a document, but which open files nonetheless. This is about controlling opening and reading files, not creating or saving them, so in one sense it’s actually the inverse of normal permissions.

An example might be an app which scans through documents in a folder, analysing or changing them in some way, perhaps batch-converting Rich Text files to PDF. Under Mojave’s privacy system, there’s nothing to stop software from extracting information from documents which could (particularly when compiled) be undesirable to say the least.

The way this might work, then, is that apps and other software which want to crawl through parts of your Documents folder opening documents of their choice should be added to a list in the Privacy tab in the Security & Privacy pane. However, these protections apply not just to your Documents folder, but to Downloads, Desktop, Trash, Removable Volumes, and more. To have a separate list for each would be unmanageable, so they’re combined into the single item Files and Folders.

If you open that section in the Privacy tab, you’ll notice that you can’t add or remove items from that list, only control the access which they’ve already sought or been given using checkboxes. So how do you add an app or command tool? Using the Full Disk Access list instead. Alternatively, if you want to limit its access, run the app or tool. When it then tries to access protected items, macOS will add it to the Files and Folders list with appropriate locations. If you give consent to that access, that location will then be enabled; if you refuse, it will still be added but the location will remain unticked.

Apple here distinguishes user consent from user intent. Obtaining user consent is tedious, so rather than driving us nuts through interminable dialogs, Catalina relies as much as possible on inferring your intent. When you use any of the LaunchServices methods of opening a document, there is no doubt that you want to open it: so macOS infers that as your intent. When a background process tries to open a document without any user interaction, you haven’t expressed that as your intent.

This works fine for one-off access, but once an app has been given access to a document inside your Documents folder, it needs to retain that right, and that needs to travel with that document wherever it goes. Jeff Johnson – developer of StopTheMadness – has just discovered how this feat is achieved: using a new extended attribute (xattr) which is attached to files, recording the apps which have right of access.

The xattr in question is named com.apple.macl, and if you search Mojave and earlier systems, you’ll discover that the only files which have this xattr attached to them are those which have come from Catalina. Create a new file, or save an existing one, in Catalina using an app built using the latest SDK, and it will have a com.apple.macl xattr attached to it automatically, which gives the creator the ability to open that document wherever you move it.

The com.apple.macl xattr contains a list of UUIDs for the apps which can open it, each with a prefix 0100 containing a single flag which presumably grants that file-specific entitlement. There can be one or several UUIDs, which are stored there in binary, not text, for example as
0100ece205ce6bfd4175940aa2dba173d5c0
which represents the UUID
ece205ce-6bfd-4175-940a-a2dba173d5c0
in standard notation.

There are two complications to this scheme. First, most but not all of these com.apple.macl xattrs are protected by SIP, so those can’t be deleted. It’s unclear why some are, and some are not, as there doesn’t seem to be any simple pattern. The other is that the UUIDs don’t appear to match those used by other well-known subsystems in macOS, so at present there’s no way to look up which app each represents. They may also change over time, with one app being represented by more than one UUID.

In case you’re worrying that, with a single xattr protected by SIP, these marked files might prove impossible to remove, so long as you don’t try removing that xattr alone, you can do everything else normally with them, such as putting them in the Trash and emptying it. The xattr and any SIP protection persist into copies of that file too, so the only way to remove the xattr is to extract the file’s data content to a separate file which lacks that xattr.

There are some worrying features in Catalina, though. I have written before about the promiscuous use of the quarantine flag on documents in Mojave and earlier. I regret to report that this behaviour doesn’t appear to have changed at all, and in many current Catalina installations the new com.apple.macl xattr will be outnumbered by all those devalued quarantine flags. This also gives rise to some strange consequences: open a PDF in Preview without saving it, and it will be given a quarantine flag but no com.apple.macl xattr. If you try to Save that to overwrite the original document, Preview promptly refuses, and may not even be able to write that file out under another name. Repeat that with a PNG file, and Preview has no such problems.

Finally, in the event that an app is tripped up by this new privacy protection or the com.apple.macl xattr, Kelly Yancey suggested opening Console and checking back through the log to see what happened. If only we could do that so simply in Console! You should find my free utility Taccy much more helpful, as it will deliver a log extract containing just the entries concerned with privacy protection, without you having to work out how to do that yourself.

None of this appears to be documented by Apple beyond the glimpse given at WWDC 2019. The macOS User Guide doesn’t mention any of these issues, and developer documentation seems scant at best. Thanks to Jeff Johnson for lifting this lid and writing up what he found inside.