Apple Events Usage Description
Until Paul mentioned his own problems, I glossed over these failures because I was satisfied that my production built versions, linked against the 10.13 SDK, were “working fine.” But Paul’s report got me thinking: was it possible there is some unspoken contract here, whereby linking against the 10.14 SDK opens up my app to additional privacy related requirements?
I tapped into Xcode’s Info.plist editor for FastScripts, added a new field, and typed “Privacy” on a hunch, because I’ve come to realize that Apple prefixes the plain-English description for most, if not all, of their “usage explanation” Info.plist fields with this word[…]
Aha, that first one looks promising. You can right-click on an Info.plist string in Xcode to “Show Raw Keys/Values”, and doing so reveals that the Info.plist key in question is “NSAppleEventsUsageDescription”. After adding the key to my app, I built and run again, and running the same script as above now yields the expected authorization pane[…]
I believe the WWDC session said that the other usage descriptions are required if you build with the macOS 10.14 SDK. NSAppleEventsUsageDescription was not added until Beta 7, though. It’s kind of odd that this key just has a single string value, since an app might want to send events to any number of different apps, for different reasons. Everything needs to go in that one string.
And it’s too bad there’s no corresponding usage description or prompt for Full Disk Access. Your app just gets a permissions error, and you have to explain to the user how to enable access in System Preferences.
Previously: Apple Event Sandboxing in macOS Mojave Lacks Essential APIs.
9 Comments RSS · Twitter
The thing I really don't get with this concept of usage string is that if you trust the app is doing what it says it is doing, then why is the dialog needed at all? And if you think the app is going to do nefarious things, then why would you trust the message it puts in that authorisation request?
Add that to the plethora of new authorisation requests in Mojave and you just get straight back to the situation of 99% of the users just auto-clicking the dialogs, especially when the app messages is just going to be something like “Wonder App needs permission to do X so that it can do what you asked it to do.”
And there is still no way to just say “I trust BBEdit, let it do whatever it wants”.
And BTW, apparently if you link with macOS 10.14 SDK, and you don't include the relevant usage descriptions, then your app just spontaneously exits when the authorisation is required. So if your app hardly ever uses AppleScript, or hardly ever looks in the Mail data folder, or whatever, and then the user asks it to do something that triggers it and you haven't thought about or tested that case, they are going to get a nasty, possibly data destroying, surprise.
Yes, these usage strings and usage dialogs ends up being just annoyances to both developers and users.
IIRC, the first one was related to using the AddressBook APIs from your application. It was quite pointless considering that it was still possible, at the time, to access the contents of the Address Book data via the sqlite3 tool without triggering such a warning.
@Peter Yeah, it seems to me like the main benefit is that if you don’t expect the app to need Contacts/microphone/whatever access, you at least get some warning that it’s trying to do that. If you do expect the app to need access in that area, you have to trust the message in the request. I would be nice to be able to grant blanket access to certain apps or to have one combined prompt that requests everything the app needs to do at once. If I’m running a long workflow with FastScripts or Keyboard Maestro for the first time, the system won’t prompt me to allow control of all the apps until the point in the script where they are first messaged. So I could go away and come back to find that it didn’t finish running because it got stuck at an authorization prompt. :(
I think there may also be a bit of a security hole because you have to give Terminal access if you want to do anything from there yourself, but then another app can create a .command file and tell Terminal to open it (which is treated as a trusted event).
Killing the app because you forgot an Info.plist string does seem overly hostile to user data to me, although I don’t think that would happen from looking in the Mail data folder because Full Disk Access is treated differently.
[…] Previously: Apple Event Sandboxing in macOS Mojave Lacks Essential APIs, Apple Events Usage Description. […]
[…] AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms, Apple Events Usage Description, Call Recorder for FaceTime Won’t Be Compatible With Mojave, Ghostery Lite, Little […]
I believe the pane URL schemes (anything beyond simply launching the app) do not work under sandboxing!
I'm using the workaround that Daniel Jalkut mentioned in his answer, but pretty nervous that I'm seeing related AppleScript changes at all in 10.13...
