Friday, August 31, 2018

AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms

Felix Schwarz (tweet):

macOS Mojave beta 7 introduced AEDeterminePermissionToAutomateTarget, a new API that allows apps to determine whether they’re authorized to send an AppleEvent to another app:

OSStatus AEDeterminePermissionToAutomateTarget( const AEAddressDesc* target,
						AEEventClass theAEEventClass,
						AEEventID theAEEventID,
						Boolean askUserIfNeeded );


Also new in macOS Mojave beta 7 is kAEDoNotPromptForUserConsent, a flag that can be added to the AESendMode that’s passed to AESend().

If the AppleEvent sent that way would require user consent, the user is not prompted for consent. Instead AESend() will return errAEEventWouldRequireUserConsent.

What’s up with the documentation this year? We’re now on beta 9, but Apple hasn’t mentioned this important stuff anywhere but the headers. And there are still no release notes for Foundation, Core Data, and other frameworks besides AppKit.

AppleEvent sandboxing, as of Mojave beta 9, is not in a good shape. The addition of new APIs in beta 7 telegraphed that Apple is still working on it. But it’s unclear what changes are still in the pipeline - and whether Apple can make enough progress before Mojave’s public release.

Apple has been talking a good game lately about the Mac and professional users, but actions like this either make it seem like mere talk or point to division within the company. The general idea of AppleEvent sandboxing is not a bad one, but the rollout was botched. Apple did not seem to be aware of how disruptive this would be for developers or how much it will degrade the user experience for customers. That is impossible to square with the idea that it understands and cares about pro users. Or, alternatively, Apple understood this but development was way behind schedule and, for no discernible reason, it decided to rush ahead rather than take the time to get it right for macOS 10.15.

Mark Munz:

Given Mojave b9 created a whole NEW set of display problems in app (none which existed in any prev beta) does not give me encouragement that Apple will fix #AEpocalypse in time or in a user-friendly manner. #bigmess


And it will be individual developers that will be left to try and work around Apple’s rushed decision making and half-assed implementations. This stuff feels seriously rushed.

Dave Nanian (tweet):

When a schedule starts, those prompts suddenly appear, referencing an invisible application called Copy Job. And while a user might recognize a prompt for SuperDuper, it’s quite unlikely they’ll know what System Events is, or why they should allow the action.

Worse, a typical schedule runs when the user isn’t even present, and so the prompts go without response, and the events time out.

Worse still, a timeout (the system defaults to two minutes) doesn’t re-prompt, but assumes the answer is “no”.


It’s more than a bit ironic that an approach that avoids the prompting can do far more, silently, than the original ever could, but that’s what happens when you use a 16-ton weight to hammer in a security nail.

Jason Snell:

This is such a disaster.

Dave Nanian:

My blog post’s summary video[…]

Rich Trouton:

As part of macOS Mojave, Apple introduced new controls for accessing data in the individual user home folders. Along with these controls, Apple introduced the ability to whitelist certain actions and interactions using profiles. This repository stores Privacy Preferences Policy Control profiles, also known as TCC profiles, which I’ve created using the following tool[…]

Previously: Apple Event Sandboxing in macOS Mojave Lacks Essential APIs, Apple Events Usage Description.

Update (2018-09-03): Felix Schwarz:

Using the x-apple.systempreferences URL scheme, it’s possible to open System Preferences right at “Security & Privacy > Privacy > Automation” by opening this URL[…]


Passing false, errAEEventWouldRequireUserConsent is returned even if the user was previously prompted and declined permission.

In consequence, even for running applications, AEDeterminePermissionToAutomateTarget can’t be used to silently determine the current status. To be usable for that, it would need to return errAEEventNotPermitted in case consent is required and the user has already been prompted about it and denied. This feels like a bug. Paulo Andrade has filed a radar about it.

Felix Schwarz:

Hidden gem in there: “TCC stands for transparency consent and control.”

Update (2018-09-04): The URL for opening the Full Disk Access preferences is:

Rui Carmo:

It’s not going to be the usual “fallback, update and regroup” update where it regards scripting and automation—there will be some serious breakage due to new security measures.

Paulo Andrade:

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).


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.

Paul Kim:

I cannot run a number of my automated tests. My tests test functionality that uses AppleEvents or the tests use AppleScripts themselves to verify test results. Adding the usage description keys to the Info.plists of the xctest bundles does not work. Also, it’s unclear which app the keys should be added to as it’s not documented whether a helper app, or its enclosing app needs to include them. On top of that, I don’t own the running app in this case so changing those keys will break the code signature.


In short, unless Apple fixes this soon, or even better, rolls it back to be released later, things are going to be a bit bumpy in Mojave. As a user, you may be surprised how often AppleEvents come up in the apps that you use.

Update (2018-09-05): Felix Schwarz:

The issue mentioned by @dnanian’s blog post – where AE prompts automatically timed out with “Don’t Allow” after a few minutes – seems to have been addressed: I have one open for 32 minutes now.

Other than that, I didn’t find any changes in beta 10.

Dieter Komendera:

The new Apple Event Sandboxing in macOS Mojave is going to be a disaster. This is the alert when auto-filling credentials from 1Password (v. 6.8) in Chrome. Normal users will bump into this & break their system.

Hal Mueller (tweet):

However, the view controller that needs camera and microphone access has multiple previews, and a live audio level meter. The calls from AVFoundation to request access are asynchronous. That means that bringing up that one view controller triggers six different alerts in rapid succession, each asking for camera or microphone access. That’s not a user experience we want to present.


There’s another complication, though. The user alert for each kind of privacy access (camera, microphone, calendar, etc) is only presented once for each application. If they clicked “grant”, that’s great, and we’re off and running. If they clicked “deny”, though, we’re stuck. We can’t present another request via the operating system, and we can’t bring up our recording preview.

Enter the nag screen. The nag screen points the user to the correct Privacy & Security pane. We will show the nag screen (optionally, depending on a parameter to our gatekeeper method) from the completion handler if permission is not granted.

Hal Mueller:

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.

Felix Schwarz:

Contrasting this #WWDC2012 slide with #Mojave’s AppleEvent sandboxing implementation provides a strong argument for why the latter should really be built on top of AppleEvent access groups:

- increased security

- better privacy protection

- prompt the user only if really needed

Building #Mojave AE sandboxing on AE access groups would also allow for a MUCH better prompt & full transparency – by enabling macOS to show EXACTLY the list of permissions requested.

“Allow app X to send an email?” vs. “Allow app X to do anything in Mail?”

Felix Schwarz:

In 2017, User Approved Kext Loading shipped, even though it was clear it’d cause lots of pain

The impact on my app sales was/is immense.

If AE sandboxing ships as-is, affected devs can expect refund requests, 1 star ratings & LOTS of mail.

Felix Schwarz:

If Apple insists on shipping AppleEvent sandboxing as-is, it’ll cause a lot of breakage for normal users.

And no time will be wasted by the media to (deservedly) mock Apple with their own ad.

Both of which would be a shame, because #Mojave is a really solid update otherwise.

Update (2018-09-06): Howard Oakley:

Mojave’s protection system, TCC (for Transparency Consent and Control), has to work with old apps, built before these controls were implemented, and new ones, which may have the protection of being App Store apps, or can be ‘hardened’ and notarized. To cope with this wide range, its rules may appear complex, so I have sketched them out in a diagram which explains what happens when an app tries to access protected data.

Update (2018-09-07): Norbert Doerner:

Honestly, I have never seen Apple adding such essential limitations so late in the beta. In this case, in beta 6. Add that to the more or less complete lack of communication about this vast limitation, and you are bound for trouble.

The limited way that Apple seems to offer to developers to tell the users why they want AppleEvent access to an app (only a single text string per application for all AppleEvent-related actions to all possible other applications!) - and the very lame idea from Apple to name this new dialog “xx wants to control yy”, will cause all kinds of important features in so many apps to break.

Developers now suddenly need to test every single one of these places in their code and add graceful, defensive code that explains to users, if and why a feature failed in macOS 10.14.

Howard Oakley:

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.

Mark Aldritt:

The first time you run a script that addresses an application, you will be asked to grant your permission. If you do not, the script will not run. Script Debugger’s Dictionary Explorer works by sending Apple events to applications, so you may be asked for permission when exploring an app’s dictionary, rather than directly running a script.

Update (2018-09-08): Mark Munz:

With macOS Mojave, I feel we’re returning to an Apple attitude of just dictating terms to Mac Devs instead of engaging with them.

1. User prompts for every app that uses AppleEvents.

Oh, guess what? A lot of apps use AppleEvents! That means A LOT of user prompting.

Who doesn’t love a ton of random prompting?

2. And if you choose poorly…

Like Indiana Jones & Last Crusade, the results are bad.

Right now, you have to make a trip to terminal. To me, that’s a demonstration of failure in this Mac UX.

3. AppleEvent security is important, but it needs CAREFUL consideration. IMHO, Mojave’s solution is not that.

It feels very half-baked. It feels like there was NO dev input sought before WWDC. And we are now using band-aids to try and “fix” some core design flaws.

4. And 3rd party developers will end up taking the brunt of the complaints by users.

It will be our support teams overwhelmed with complaints that (64-bit) apps that worked in High Sierra are now broken.

Jeff Johnson:

The more warning dialogs you present to a user, the more they just click through without reading. This is well known. How does Apple not know?

Or maybe they do know. The Mojave warnings are not to protect users, they are to protect Apple from blame. It’s your fault for clicking.

Update (2018-11-19): Tim Hardwick:

I’ve been testing Folder Actions in macOS Mojave 10.14.1, and the results aren’t good. Apple needs to look at how new security approvals are implemented for workflows containing Apple Event scripts, because the reliability of automated actions has taken a dive.

Update (2018-11-26): Jesse Squires:

This was my first real experience trying to write a Mac app after years of doing iOS development and the majority of my time was spent trying to understand how sandboxing works and which entitlements I needed to specify.

Update (2018-12-20): Paul Haddad:

The security model in Mojave is awful. Why isn’t this just Deny/Allow? Half of these types of calls pause execution, half fail. No way to re-ask. Just bad.

24 Comments RSS · Twitter

@Michael Seems like documentation has been getting increasingly lax. NSGridView had no meaningful documentation outside of the headers for months after 10.12 was released. Even today, I would argue that what's there is not nearly enough to get someone started who either hasn't watched the WWDC videos or doesn't know to read the headers.

i think if the event in 2 weeks doesn't show new mac hardware, plus everything in this thread, the inescapable conclusion is indeed that apple doesn't care about pro users anymore. ;(

[…] required more work than for other recent macOS releases because of Dark Mode, the security changes, and a number of framework bugs that I had to work […]

Paulo Andrade: "Automation has always been a staple of macOS. And there was a time where it was booming. Apple gaves us Automator, the Scripting Bridge … But a few years back (I can’t precise when), development stopped."

I believe Paulo just answered his own question. Automator failed to build any market outside of a tiny niche of semi-technical Mac users, while Scripting Bridge was absolute crap that, if anything, achieved negative growth. (SB knocked the legs from under appscript, which had 1000+ users by 2007, without being competent enough to replace it.)

AppleScript was already waning by the time AppleScript 1-2-3 (1st ed, 2009)and Learn AppleScript (3rd ed, 2010) were hitting the bookshelves and, with no alternatives to AS, Mac Automation would inevitably go down with it. In 2012, I publicly called the end of Mac Automation within the next 5 to 10 years.

2014’s surprise JavaScript for Automation could have changed everything, winning Mac Automation a million new users almost overnight as Apple’s answer to Node.js. But JXA was thrown out the door flawed and buggy, with absolutely zero marketing, education, community building, or user support. Not surprisingly, JXA immediately sunk without trace, even as Node.js was doubling its own market every year.

The reason Apple stopped investing in Mac Automation is blatantly obvious: because all their previous investment repeatedly failed to deliver any results worth a damn (i.e. bums on seats). Mac Automation is a Failed Product, and Apple knows it.

The only reason Apple hasn’t already Apertured the whole sorry lot is because it has a crap-load of legacy entanglements throughout the platform which they can’t quickly replace or eliminate. So they’ll do what they have to do to keep the Apple event infrastructure minimally alive, but don’t expect them to do a good or careful job of it because it simply isn’t worth their time. Just be thankful it’s on life support at all.

I hate to be the bearer of bad news, but I'm not terribly optimistic for Apple to change course. Let me be wrong! That's perfectly acceptable, but I think once the company became all iOS (yes, hyperbole, but "What's a computer?"), the chances of course correction were slim. "Innovate my ass!" gave us a trashcan that flopped.

Doesn't surprise me. I think the lack of shiny factor regarding automation technologies means marketing for the masses is a dead end. Therefore, it's not a priority. Apple is a consumer fashion lifestyle company more than anything.

I, for one, am really glad that Apple's doing what it's doing (even if I share the pain of their current, restrictive implementation). Once on Mojave, I was a bit shocked by the number of apps that were requesting access to control System Events.

I was also surprised by Quick Actions (aka Automator workflows) as one of the major features of Mojave and the way they're integrated with Touch Bar. That doesn't sound like 'a failed Mac Automation product' to me.

"That doesn't sound like 'a failed Mac Automation product' to me."

Of course it's a failed product. The success of a product is measured by ROI, i.e. number of users * cash spent by each, not by developers' ability to keep diddling around with the code years after it failed to yield either. (And if you think function key macros are a "major feature" for an OS, I'm not sure if that says more about you or about post-Jobs Apple.)

Hell, my old appscript bridge was a technically brilliant software technology that absolutely wiped the floor with AppleScript, but as a software product it crashed and burned just as it was poised to break through into the big time. (My bad.) Doesn't matter if you've created the best solution in the world; if no-one knows about or uses it, it ain't worth squat.

(The appscript debacle learned me a painful but important lesson about how NOT to do Product Development and Marketing, and ten years on I'm still learning how to do it right. And Python appscript still kicks ass.)


My guess is 10.14's small but fresh investment in Automator is being done in preparation of merging it into Workflow/Shortcuts. Enabling Shortcuts to run Automator Actions would be a nice cheap way to make Mac-specific capabilities available to Shortcuts users on Day One for no extra cost. If that spurs market interest, vendors can rewrite their existing Automator plugins as native Shortcuts plugins at their leisure. Or, if it's a total yawn, then it's not cost anyone anything to find that out.

(Or, it might just be some bored developer having a fiddle with a pet project that subsequently got tossed into a release as filler, in which case post-Jobs Apple's losing of its way is even worse than we thought and Michael Dell was right after all.)

[…] so glad that Apple is eliminating useful apps, nerfing others, and adding friction instead of acting on the actual malware at the top of its […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms, Apple Events Usage Description, Call Recorder for FaceTime Won’t Be Compatible With Mojave, […]

[…] macOS Mojave, there has been a lot of unrest in the macOS administrator community over some of the changes, and what role MDMs can play in […]

Those new anti-automation "security" features are absolutely useless and pathetic. All they do is pester users with useless dialogs, which 100% of users will automatically dismiss like annoying flies. Not to mention huge needless hassle for developers (and I am a developer of automation products for the Mac).

Apple, once again, is focusing on nonsense and making life worse for both users and developers - all under pretense of "security" (for which, by the way, the new measures don't contribute in any way).

On the plus side, this has forced me to learn a lot about Safari Extensions...

[…] Previously: AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms. […]

[…] Previously: AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms. […]

I understand that is deceptive as this is something your apps are relying on to work, but on a user standpoint I am happy that Apple focuses a bit more on security than on pure usability.
I certainly do not want Apple Events to become the macros/scripts security holes Windows’ security has been suffering for years.

Above all, I would be horrified by a “allow this lovely app to control all my current and future apps, and why not Keychain Access or the Security Settings Panel, that would be fun if this lovely app gets compromised one day” feature.

Yes, users will have to accept several prompts, but I don’t see the point he would have to do this a hundred times (if I understood Felix Schwartz’s biggest issue)… Is there a real use case where an app actually needs to request control of “a hundred other apps right now” instead of “the few apps I want to remote control when this is actually needed for the first time”?

[…] Previously: AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms. […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

It seems not much has changed in the meantime. What is really lacking is a way to preemptively grant an application permission to control another app, and for this permission to *stick*. Today I have noticed that the permission will expire even when nothing has changed about the app or the one it controls. For instance, I use a standalone AppleScript app as an alarm clock to control iTunes every morning. It has worked fine for 29 days. Then today it suddenly froze on the confirmation prompt, almost making me oversleep. Neither the app nor iTunes had changed since yesterday when everything still worked. Of course there is no way to add a timeout on this prompt because it freezes the whole app.
I just want to be able to tell OS X that I really trust this app and do not want to give it permission again until it has been modified. Why isn't there an ‘add’ button in the Automation security settings?

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms […]

Leave a Comment