Yesterday, I looked at how Mojave’s new privacy protection works for data, services (Location) and hardware (camera and microphone), and largely ducked the most thorny issue of apps and scripts controlling other apps – Automation.

Regulating direct access by apps to protected data is relatively simple, and should be highly effective. But macOS has always had powerful means by which apps can control other apps – AppleEvents – which are exposed to the user in scripting systems, notably AppleScript, and Automator. Many excellent apps are built largely on bringing together features of different apps using AppleEvents. And some of the most surprising apps call the occasional snippet of AppleScript to enable important features.

So all a developer would have to do would be to locate features in an app which does have access to protected data (or services or hardware), and control that app using AppleEvents, to circumvent Mojave’s privacy. This makes controls on Automation one of the most important features in Mojave’s new privacy system.

The snag is that putting simple limits on the use of AppleEvents to control other apps can easily leave vulnerabilities. An app running a line of AppleScript could be using it to display a file’s location in a Finder window, running a command with elevated privileges, or stealing the contents of emails. There is no system of whitelists or blacklists to distinguish between the effects of commands on your privacy.

What Mojave currently does for Automation is very likely to evolve over the coming days, weeks, and months. What I describe here may well have changed completely by Christmas, or maybe even sooner.

When an app calls an AppleEvent (or runs AppleScript) which performs an entirely innocent task, such as
set thePath to POSIX file "/Users/me/Documents/myDoc.text"
tell application "Finder" to reveal thePath
the privacy control system, TCC, lets this pass without any concerns over privacy, and it doesn’t trigger any dialogs.

Actions which are potentially more risky are handled with much greater care. For example, using System Events in code such as
tell application "System Events" to get the name of every login item
tell application "System Events" to delete login item "MyApp"
tell application "System Events" to make login item at end with properties {path:"/Applications/My.app", hidden:false}
will trigger a consent dialog. However, it does not require the calling app to provide usage information, even when that app is built against the 10.14 SDK.

So if no usage information is provided, the user sees a dialog which currently has a lot of text, isn’t likely to make much sense to a naïve user, and doesn’t explain the purpose. Apple is considering how best to change this, but without both app-specific and contextual information, it’s hard to see how this can be improved much.

Apps which do more ambitious things, such as controlling real apps rather than System Events, are required to have usage information if they have been built with the 10.14 SDK, much as they do to access other private data. This is then added to the consent dialog as shown above, and can make a big difference to the user when they are forced to make a decision.

One significant limitation at present is that only a single usage string can be supplied. In the case of my apps, which use AppleScript to install themselves as Login Items, that is unimportant. But apps which use a lot of AppleEvents can do so for a wide range of different purposes. It isn’t yet possible for them to change the app-specific content in the consent dialog so that it is specific for that individual consent.

When consent is obtained for Automation, it must be specific for that pair of apps, as shown in the Privacy settings. Here, the user has consented to Bailiff scripting System Events, but that doesn’t permit Bailiff to script any other apps: separate consent must be obtained for each, still using the single usage statement for all.

In an app which scripts several different apps, that means the user should see a separate consent dialog for each of those relationships, which is neither efficient nor kind to the user.

Developers who are struggling with these problems hope that Apple will come up with a better solution. You can read full details in Felix Schwarz’s excellent article here.

What about your own AppleScripts, though: surely you don’t have to comply with all this privacy protection when they’re your own scripts and your own data?

Sadly, there’s no robust way of telling whether any given script or app is owned by the same person as the data, so TCC’s rules have to extend to user scripts in exactly the same way as they do to commercial apps. If you run an old AppleScript app on Mojave, you will see the same consent dialog as for any app.

Mojave’s AppleScript editor does try to help you get it right, though. If you have developer signing certificates, it is happy to sign your AppleScript apps, but they cannot be hardened or notarized, and don’t have entitlements.

The Script Editor also adds default usage information to a script app’s Info.plist, which you can edit to clarify your purpose. There is a slight snag here with signed apps, though, as their code signatures should include the Info.plist, which would prevent you from modifying that after signing. Hopefully that apparent conflict will be resolved to allow scripters to create properly signed apps with custom usage information.

The strange thing with apps created by the Script Editor is that it does what everyone agrees you shouldn’t do: it adds usage information for every class except Location services, as shown in this shot from Taccy.

Building scripting into Mojave’s privacy control is not easy, nor is it yet complete. I think that Apple is going to have to provide more extensive support to app developers, and the human interface will inevitably improve. It would make a great deal of sense for apps to be able to obtain pre-approval when first opened, so that users can give their consent to the features that they have just paid for, to access their own data. But this is going to require great care, for fear of opening vulnerabilities which will allow rogue apps to exploit the system.

If you rely on apps which make use of AppleEvents – something which is almost impossible to determine, although you can usually make a good guess – then you may find them struggling during your early days with Mojave. Once the barrage of consent dialogs is out of the way, they should behave more like their old selves again. Keep a careful watch on their support sites, where developers should provide detailed information about any issues with Mojave.