I understand the desire to make your features 'just work', but circumventing the user's privacy controls to do that is never acceptable. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs? > - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI I don't have Office, so I've turned off the badge. (I don't work for Dropbox or anything I've just been poking around.) I assume that the client is presenting the normal OS X 'ask for elevated access' UI and then using that elevated access to configure and install these. To clarify for others: In /Library/DropboxHelperTools, you'll find a folder for each user full of setuid tools which run as root and do various privileged things. The dialog box you see is a native OS X API (i.e. > - We never see or store your admin password. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused. The intent was never to frustrate people or override their choices. We check and set privileges on startup - the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. We never see or store your admin password. We've been working with Apple to eliminate this dependency and we should have what we need soon. We use elevated access for where the built-in FS APIs come up short. We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions). We only ask for privileges we actively use - but unfortunately some of the permissions aren’t as granular as we would like. We ask for permissions once but don’t describe what we’re doing or why. Clearly we need to do a better job communicating about Dropbox’s OS integration. Hi HN - Ben from Dropbox here on the desktop client team.

Dropbox for mac stopped showing badge