I'm using the same techniques for my apps to enable accessibility access (which is needed for window management), although I'm asking users for confirmation before doing so.
It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users.
Why not displaying a simple yes/no popup similar to the "allow access to contacts / calendar items" dialog?
Because granting accessibility access is far more dangerous than granting access to contacts / calendar. The latter just exposes some of your user data. The former gives the app a huge amount of control over your computer.
What exactly is so dangerous? Any app can take screenshots , listen to keyboard entries, send keys, move the mouse pointer and upload stuff to a server without any AXApi permission.
Forbidding window movement doesn't add any security at all.
Anyways, all I want a simple prompt explaining what the Accessibility API does and yes/no buttons.
One example that comes to my mind, is that you won't be able to copy any data from keychain. In fact, no one can access protected keychain data, if any app that is not in Accessibility "listens to keyboard".
I'm not saying that accessibility enabled apps can't do any harm, of course they can. My point is that they can't do more damage then regular applications you run on your mac.
The only way to run third party apps in a kind of secure environment is sandboxing.
All this accessibility api lockdown stuff from Apple is just pseudo-security.
> My point is that they can't do more damage then regular applications you run on your mac.
Well, they can autoconfirm Keychain prompts with simulated keyboard events (and access all the keychain data in general), for one. This is something non-accessibility apps can't do after some update.
Keylogger can't steal your password, if it's in keychain, even though it knows your root password. But I guess now it'll add itself into accessibility, so… waiting for Sierra :)
> Well, they can autoconfirm Keychain prompts with simulated keyboard events (and access all the keychain data in general), for one. This is something non-accessibility apps can't do after some update.
Simulating keyboard (and mouse) events is easily possible for non-accessibility apps (CoreGraphics CGEvent api). In fact, AXUIElementPostKeyboardEvent is just a simple wrapper around CGPostKeyboardEvent.
It is, but OS X won't accept it and will not unlock Keychain item, unless all the apps that do this are in Accessibility. So if there is an app that uses those APIs but not in Accessibility, even you yourself won't be able to copy anything password-protected from Keychain.
SecurityAgent
Available for: OS X El Capitan 10.11
Impact: A malicious application can programmatically control keychain access prompts
Description: A method existed for applications to create synthetic clicks on keychain prompts. This was addressed by disabling synthetic clicks for keychain access windows.
CVE-ID
CVE-2015-5943
Pure speculations: Wouldn't it be possible for an app without accessibility access to just kill and relaunch another app in a wrapper? This wrapper having hooks into system APIs?
It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users.
Why not displaying a simple yes/no popup similar to the "allow access to contacts / calendar items" dialog?