In my previous post, I pointed out that it is the app developer who is most likely to be confronted with problems arising from Mojave’s new privacy protection, as the most severe effect is going to be that their app crashes when trying to access protected data. Users will see this as a failing in the app, rather than the consequence of their action, or of macOS defending their privacy.

Unless a user takes to browsing the Info.plist of the applications they run, and understands in some depth how Mojave’s privacy protection works, there is no easy way for them to discover what limits an app might have. There’s no convenient display in Finder’s Get Info dialog, for instance, which tells them that the image editor they’re about to use doesn’t have access to images in their address book, or Photos library.

Indeed, when they use the Finder, they will see that they have normal read and write access to all of these folders and files. Unlike Unix permissions, Mojave’s Finder doesn’t give any indication of what is protected, either in its own windows or in its Get Info dialog.

Apps which are not currently permitted to access protected folders do display conventional No Entry signs on those folders when you try to open a protected area in their Open File dialog. But that conflicts with the Finder’s display of those same folders being fully accessible. I can see some users considering that to be a bug in the app, and complaining about it.

Apple would no doubt argue that users have to do something different in order to see protected data, such as opening their hidden Home Library folder, or looking inside a Photos library. Whilst that is true, I know of plenty of users who have done such things, but don’t even understand normal file permissions, let alone what Mojave is about to unleash.

At the very least, the app developer needs to tell users what their apps are able to do, and where they can’t go. If privacy protection is going to be meaningful and work to our benefit, we shouldn’t be enabling every app to access protected data, nor should the user be giving them all Full Disk Access.

My suggested example is a simple, predominantly graphical panel based on Mojave’s Privacy settings, listing for an app what it can and cannot do, and how. For instance, here is one for my extended attribute editor, xattred:

I am putting that information in its documentation, and in a new command in its Help menu. Many users may ignore both, but we can only take the horse to water.

The Help window is quick and simple to do. Here is an archive containing blank light and dark mode files, and completed examples: privacyhelp

Mark up one of each for your app, and add them to a new image set in Xcode’s Asset Catalog. Use the Any, Light, Dark appearance to ensure that your app will automatically use the right image for the current mode.

Make a new Window Controller in Interface Builder, around 279 x 377 in size, and with a suitable Storyboard ID such as Privacy Window Controller. Add an Image View, and set it to display your image.

Then, in your AppDelegate source, add the code to show that window, in a function which you then connect to a menu command of Privacy settings in the Help menu.

When it’s all built and running, using that command will display the image.

And switching to Dark Mode will automatically show that version instead.

If you’ve got your scaling right, the user should be able to put your window next to the Security & Privacy pane, and match the items listed in each.

For an app which seeks no special access to protected areas, the only item which should be ticked is, of course, Full Disk Access. That sends the clear message that, should the user not grant that access, trying to open any protected data may be unwise.

You are very welcome to use this and the examples provided, to adapt, remix, or do whatever you want with them, if you think they might help.

In future versions of Mojave, I think that it would be helpful to everyone if:

• The Finder’s Get Info parsed app information and gave some idea of its privacy constraints, and
• Privacy-protected folders and files were visibly identified as such when viewed in Finder windows (not just Open File dialogs). Come to think of it, we don’t seem to have a general icon to signify what is private; this might be its first good purpose.