The Mac continues its path towards buttoning down the application sandbox on Mojave. High Sierra — Mojave’s predecessor — already presented user authorization prompts the first time an app accessed Contacts, Photos, Calendars, etc. Mojave builds upon that by adding other categories such as Camera and Mail, and making the prompt unavoidable even if going directly to the file system.

The goal is simple and noble: ensure the user has knowledge and control over which apps are accessing his data.

Also included in this prompt-on-first-use tactic are Apple Events. Apple Events allow apps to communicate with each other and perform various tasks. Similarly, whenever and app tries to send an AppleEvent to another app for the first time, macOS will prompt the user for authorization.

Seems fair right? Well… there are a couple of crucial differences that I believe make this the wrong approach for app-to-app automation.

Felix Schwartz has already written about how the current implementation is lacking even after new APIs were introduced in beta 7. Not to mention the missing documentation and bugs…

But what I’m about to argue here is that macOS is taking a wrong turn regarding automation.

The Round Peg in the Square Hole

These authorization prompts serve to inform and empower the user to control access to his data. It’s easy to see that these prompts are valuable when we’re talking about an API dealing with Contacts or Photos. An API whose main purpose is to read/write user’s data.

But what about opening a Terminal window on a given folder, pausing a video, adjusting audio volume, composing a new e-mail, changing the type of an image, etc? Apple Events provide a platform for apps to automate each other — the spectrum of functionality you can achieve with it is much broader than the concise APIs of Contacts, Photos, Calendars, etc.

There are also many more scriptable apps out there than the dozen APIs Apple is protecting. And for apps that are built to interact with other apps having to authorise each interaction is far from an enjoyable user experience.

Prefixing all and any of these interactions with a cryptic alert does more harm than good. For example, when Secrets opens a new Transmit window to connect to a service how is this alert helpful?

Just to be clear, there’s no data flowing from Transmit to Secrets, only the other way around. Secrets is the one providing the service URL and credentials.

So in many of these cases the prompt has a negative effect on user experience, can be misunderstood, and contributes even further to numbing down the importance given to security alerts (which ultimately defeats the purpose of having any). Coincidentally, this is one of my favorite Apple vs PC commercials.

How did we get here

Automation has always been a staple of macOS. And there was a time where it was booming. Apple gaves us Automator, the Scripting Bridge and bindings to other programming languages. The excitement you see today regarding Siri Shortcuts, us Mac users, we’ve experienced it before.

But a few years back (I can’t precise when), development stopped. And the only thing we would hear at WWDC was how signing, gatekeeper and sandboxing were affecting our applets, automator flows and APIs. But even then, I believe we were on the right track. For example, on WWDC’s “Secure Automation Techniques” from 2012, Apple introduced new entitlements for sandboxed apps wanting to send Apple Events.

With it, an app can annotate the scripting API it vends with an access group which the caller can include in its entitlements as a scripting target. For example, Mail.app added a com.apple.mail.compose access group around the API that allows other apps to open a new e-mail compose window. Caller apps only including this entitlement are only allowed to access that part of the API, as opposed to being able to read all of your mail.

For apps that don’t specify access groups in their scripting API, there’s the com.apple.security.temporary-exception.apple-events entitlement that allows callers to interact with the entire scripting API of the target app. Note the temporary in the entitlement name.

But the gist is that there was this notion that not all parts of a scripting API were created equal. Some parts were more sensitive than others, and access groups were there to distinguish between them.

My 2 cents

In 2012, macOS was on the right path. Annotating an app’s scripting interface was the first step to solve the authorization problem but somewhere along the way I guess Apple forgot all about it…

So here’s what I think Apple should do to swerve back in the right direction:

1. Postpone the feature¹
2. Augment the access group annotations with an attribute that specifies whether they’re sensitive or not. Only sensitive APIs should require a prompt.
3. Thoroughly annotate 1st party scripting APIs.
4. Establish a timeline for 3rd party developers to annotate their scripting APIs. Note that there was never an incentive for developers to do so.

I know this is just wishful thinking, but it doesn’t feel like it’s too much to ask.

Back to posts