Mac OS X 10.9: Accessibility privileges need to be more granular
| Originator: | jb.rubin | ||
| Number: | rdar://14277466 | Date Originated: | 26-Jun-2013 3:01 PM |
| Status: | Closed | Resolved: | |
| Product: | Accessibility | Product Version: | Mac OS X 10.9 DPs |
| Classification: | Enhancement | Reproducible: | Yes |
Summary: Accessibility privileges are not granular enough to separate out intent to observe a Mac from intent to control a Mac. Combined with the new per-app controls in 10.9, this leads to a very poor user experience. The app I work on uses universal access to passively track application activity on the Mac. It in no way controls the computer. However, there is no way for me to declare this or limit my app's access to only those Accessibility API calls used for observing, not interacting. So when I ask for accessibility access for my app, the user is told my app wants to control her computer. That's the last thing I want to do, and it needlessly scares the user. I understand and support Apple's decision to lock down security for Accessibility. And given the current all-or-nothing privileges, it makes sense to warn the user about the worst case scenario (a malicious app controlling the device). But if we're going down this path, then we need a way to turn on different parts of accessibility depending on an app's needs. I should be able to tell the system that my app only needs access to read and not write accessibility info, so the warning can instead alert the user that my app wants to observe their Mac, not control it. Steps to Reproduce: Feed AXIsProcessTrustedWithOptions() an options dictionary. Expected Results: The options dictionary passed to AXIsProcessTrustedWithOptions should be able to contain a new key, maybe kAXTrustedOnlyForVoyeurismCheckOptionPrompt or something. This would alert the user that the app wants to observe but not control the computer. Then, the Accessibility API would grant read but *not* write access to AXElements for this app. It could be represented in the security preferences as a "-" on the accessibility checkbox instead of a full check. Actual Results: The only option in the AXIsProcessTrustedWithOptions() dictionary is kAXTrustedCheckOptionPrompt, and the user is told the app wants to control the computer. Regression: N/A, although with previous OS versions one could just modify /private/var/db/.AccessibilityAPIEnabled to turn on accessibility without causing a negative user experience. Of course that was very unsecure and left the machine vulnerable to any app that wanted to abuse AX. Notes: In case you're curious, my app uses accessibility to observe: - When apps launch, quit, or come to the foreground - When windows open, close, or come into focus This is done with the user's explicit consent, and the information is aggregated and used anonymously.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Closed with the comment: "Engineering has determined that this is not to be fixed."