Apple Event Sandboxing in macOS Mojave Lacks Essential APIs
In the WWDC 2018 session “Your Apps and the Future of macOS Security”, Apple announced big changes to macOS security.
One of them - and possibly the one with the biggest impact: apps can no longer send Apple Events to other apps without user authorization.
Apple argues that Apple Events (which AppleScript uses under the hood) can be used to get access to otherwise protected user data in other apps, so the user should be prompted for authorization.
[…]
I am deeply worried that the implementation of Apple Event sandboxing in Beta 2 could make it into the final release of macOS Mojave unchanged.
As it is, it offers too little to developers who want to provide a good user experience. And not enough for utility apps and pro users who are in need of an option to exempt apps from Apple Event sandboxing.
He does a great job of explaining the issues with the current implementation.
Update (2018-07-12): Daniel Jalkut:
I ran into another usability challenge that Felix didn’t itemize: the problem of denying authorization to an application and then living to regret it. I guess at some point I must have hastily denied permission for Xcode (Apple’s software development app) to control the Finder. This resulted in a seemingly permanent impairment to Xcode’s “Show in Finder” feature. I’m often using this feature to quickly navigate from Xcode’s interface to the Finder’s view on the same files. After denying access once, the feature has the unfortunate behavior of succeeding in activating the Finder (I guess that one is whitelisted), but failing silently when it comes to revealing the file.
OK, that’s fine. I messed up. But how do I undo it? Unfortunately, the list of applications in the Security and Privacy preference pane is only of those that I have clicked “OK” for. There’s no list of the ones that I’ve denied, and no apparent option to drag in or add applications explicitly. For this high level problem, I filed Radar #42081464: “TCC needs user-facing mechanism for allowing previously denied privileges.”
[…]
What’s the service called, and does tccutil even support resetting it? After a crude search of the private TCC.framework’s binary, I discovered I was looking for “AppleEvents”:
tccutil reset AppleEvents
Update (2018-08-23): Mark Munz:
Having tried to navigate this myself, I suspect new macOS Mojave permissions are going to be a major cluster***k for more advanced users.
It feels like Apple rushed this “feature” with little or no usability/power user input.
Great idea – horrible execution.
Update (2018-08-30): Evgeny Cherpak:
This prompt is so lame:
1. Include
a) requesting app icon
b) icon of the app it wants to control
2. Add some new line characters to make it more readable
3. Data and documents in iTunes... documents aren’t data? Wording needs work.
With Mojave’s release possibly only a couple of weeks away, I’ve been trying to resolve problems in my own apps which seriously limit their functionality when they’re run in macOS 10.14. What I’ve learned is how complex its new privacy protection is, and how users, sysadmins and developers may be in for a shock when they upgrade to Mojave.
[…]
It’s worth pausing for a moment to consider whether Mojave’s current implementation of privacy protection is actually in the users’ interests. I know of no other situation in which an operating system deliberately crashes an app because it lacks an explanatory string like this. Unix and almost all other operating systems handle many requests to access the inaccessible, and respond by returning an error, which the calling app can trap for and handle gracefully, ensuring that the user is made fully aware of what went wrong.
