Privacy Consent in Mojave (part 2: AppleScript)

This two-part series discusses lessons learned in controlling the user consent for access to private information by a third part program in macOS Mojave. In Part 1 of this discussion, we saw how to query the user for consent to privacy-restricted areas, how to do it synchronously, and how to recover when your program has been denied consent.

Consent for automation (using AppleScript) is more complicated. You won’t know whether you can automate another application until you ask, and you won’t find out for sure unless the other application is running. The API for automation consent is not as well-crafted as the API for other privacy consent.

The source code for this article is the same project I used in Part 1. It is available at https://github.com/Panopto/test-mac-privacy-consent under an Apache license. The product that drove this demonstration needs automation control only for Keynote and PowerPoint, but the techniques apply to any other scriptable application. Note that this sample application is not sandboxed. You’ll need to add your own entitlements for AppleScript control if you need to be sandboxed; see https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW25.

 

You will want to think more carefully about whether to ask your user for automation permission, and when to ask. You don’t want to bombard your customer with a large number of requests for control of applications that won’t be relevant to the task at hand. For the Panopto video recorder, we don’t ask for permission to control Keynote or PowerPoint until we see that someone is recording a presentation and is running Keynote or PowerPoint. If you’re running just Keynote, we won’t ask for PowerPoint access. One other wrinkle for automation consent that’s different from media consent: you only have one string in your Info.plist to explain what you’re doing. You can have separate (localizable) strings to explain each of camera, microphone, calendar, and so on. But Automation gets only one explanation, presented for each application you want to automate. You’ll have to be creative, perhaps adding a link to your own website with further explanation.

 

Screen Shot 2018 09 03 at 5 21 53 PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The newer beta versions of macOS Mojave provide an API to query the automation consent status for a particular application: the C API AEDeterminePermissionToAutomateTarget(). , defined in AppleEvents.h.You’ll call that with an AppleEvent descriptor, created either with Core Foundation or with NSAppleEventDescriptor. The descriptor targets one specific external application using the external application’s bundle identifier; you’ll need a different descriptor for each external application you want to control. Here’s how to set it up, using the C style API just for fun (you were expecting Swift???):

 

– (PrivacyConsentState)automationConsentForBundleIdentifier:(NSString *)bundleIdentifier promptIfNeeded:(BOOL)promptIfNeeded

{

    PrivacyConsentState result;

    if (@available(macOS 10.14, *)) {

        AEAddressDesc addressDesc;

        // We need a C string here, not an NSString

        const char *bundleIdentifierCString = [bundleIdentifier cStringUsingEncoding:NSUTF8StringEncoding];

        OSErr createDescResult = AECreateDesc(typeApplicationBundleID, bundleIdentifierCString, strlen(bundleIdentifierCString), &addressDesc);

        OSStatus appleScriptPermission = AEDeterminePermissionToAutomateTarget(&addressDesc, typeWildCard, typeWildCard, promptIfNeeded);

        AEDisposeDesc(&addressDesc);

        switch (appleScriptPermission) {

            case errAEEventWouldRequireUserConsent:

                NSLog(@”Automation consent not yet granted for %@, would require user consent.”, bundleIdentifier);

                result = PrivacyConsentStateUnknown;

                break;

            case noErr:

                NSLog(@”Automation permitted for %@.”, bundleIdentifier);

                result = PrivacyConsentStateGranted;

                break;

            case errAEEventNotPermitted:

                NSLog(@”Automation of %@ not permitted.”, bundleIdentifier);

                result = PrivacyConsentStateDenied;

                break;

            case procNotFound:

                NSLog(@”%@ not running, automation consent unknown.”, bundleIdentifier);

                result = PrivacyConsentStateUnknown;

                break;

            default:

                NSLog(@”%s switch statement fell through: %@ %d”, __PRETTY_FUNCTION__, bundleIdentifier, appleScriptPermission);

                result = PrivacyConsentStateUnknown;

        }

        return result;

    }

    else {

        return PrivacyConsentStateGranted;

    }

 

}

There’s an unfortunate choice made in AppleEvents.h to wrap the definition of result code errAEEventWouldRequireUserConsent in a #ifdef that defines it only for macOS 10.14 and higher. I want my code to work on earlier releases too, so I’ve added my own conditional definition to work on earlier versions. If you do the same thing, you’ll probably have to fix your code when Apple fixes their header:

// !!!: Workaround for Apple bug. Their AppleEvents.h header conditionally defines errAEEventWouldRequireUserConsent and one other constant, valid only for 10.14 and higher, which means our code inside the @available() check would fail to compile. Remove this definition when they fix it.

#if __MAC_OS_X_VERSION_MIN_REQUIRED <= __MAC_10_14

enum {

    errAEEventWouldRequireUserConsent = –1744, /* Determining whether this can be sent would require prompting the user, and the AppleEvent was sent with kAEDoNotPromptForPermission */

};

#endif

Finally, let’s wrap this up in a shorter convenience call:

 

NSString *keynoteBundleIdentifier = @”com.apple.iWork.Keynote”;

– (PrivacyConsentState)automationConsentForKeynotePromptIfNeeded:(BOOL)promptIfNeeded

{

    return [self automationConsentForBundleIdentifier:keynoteBundleIdentifier promptIfNeeded:promptIfNeeded];

}

 

Caution: this code will not always give you a useful answer. If the automated program is not running, you won’t know the state of consent, even if you’ve been granted consent previously. You’ll want to test whether the automated program is running, or react to changes in NSWorkspace’s list of running applications, or perhaps even launch the automated application yourself. It’s worth taking some time to experiment with the buttons on the sample application when your scripted app is running, not running, never queried for consent, or previously granted/denied consent. In particular, methods like showKeynoteVersion will not work correctly when the scripted application is not running.

 

Screen Shot 2018 09 04 at 8 17 25 PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

We can nag for automation consent, just as we do for camera and microphone consent. But the Security & Privacy Automation pane behaves differently. It does not prompt the user to restart your application. So let’s add a warning in the nag screen, in hopes of warding off at least a few support requests.

 

Screen Shot 2018 09 04 at 10 57 33 AM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Automation consent is more complicated than media and device consent. Felix Schwarz, Pauloa Andrade, Daniel Jalkut, and several others have written about the incomplete feel of the API. This pair of posts is meant to show you how to ship software today with the API that we have today.