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:

x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles

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.

AppleScript Documentation Mac macOS 10.14 Mojave Notarization Privacy Programming Sandboxing Security SuperDuper Transparency Consent and Control (TCC)

24 Comments RSS · Twitter

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ