See also this follow-up that explains more.
Before we bring out the pitchforks, we have to answer a few questions:
is that password dialog really a dialog painted by dropbox? Or is this the normal sudo dialog that’s used to authorise Dropbox to install a privileged helper (which is the official method)?
if it’s a dropbox dialog, the question remains whether they actually store that password or not. If they just use it once to install a privileged helper it’s ok-ish even though they could just use the official API.
Why is that SQLite file that defines the accessibility settings not in a location protected by system integrity protection? While it’s certainly not nice to hack yourself into that file, there is a technical means to prevent this which Apple has not used
As I have not much experience in OSX programming, I can’t say anything about 1), but I did a few experiments with regards to 2): If you remove the privileged helpers installed by dropbox, then it will ask for a password again instead of just installing them. This suggests to me that they’re not storing your password somewhere.
With regards to the helpers that are installed as SUID. One is called dbfseventsd. I haven’t reverse-engineered it beyond looking at its name, but I would say that this is a component to learn about changes to watched folders and as such this pretty much feels like a component needed for Dropbox “to work correctly”, so I would not say that the claim in the sudo dialog is all made-up.
However, the issue remains that dropbox asks for a lot of privileges even for stuff a user doesn’t need. With regards to the accessibility access, I would say that’s needed in order for the hacked integration into MS-Office to work - and maybe for the automated screenshot upload.
It would be preferrable if this was optional, but I really think that their hack to get themselves registered provides superior UI compared to what, say, Steam does which will have the user manually open System Preferences and add hand out permissions there.
So from an end-user perspective I can see why they are taking this path and once Apple closes that loophole (see 3. above), then the other vocal group will come out of the woodwork and yell about Apple taking away their freedoms to tinker with their systems.
Dammed if you do, dammed if you don’t.
If someone is a user of dropbox (I am not), then I think pitchforks are semi-warranted.
Why is that SQLite file that defines the accessibility settings not in a location protected by system integrity protection?
While it’s certainly not nice to hack yourself into that file, there is a technical means to prevent this which Apple has not used.
Not sure what you are trying to argue here. Should that file be protected, even from sudo/root (which dropbox asks for)? It seems the answer is “clearly”. Does the fact that it is not make it ok to directly modify it? I posit that it does not.
Dropping suid binaries seems a bit fishy too, but without knowing what that file does, I will reserve my judgement on it.
I don’t know any details personally, but https://news.ycombinator.com/item?id=12464730
So it’s an OS X dialog? That changes my position slightly.
Impersonating an OS dialog is shady business. Full stop. Either let the OS present the dialog, or present something that looks like your own dialog.