How Dropbox Hacks Your Mac

I don't really understand the conclusion here. So the scenario is you trust dropbox with your files, and you trust them with a kernel blob implementing the filesystem, but you don't trust them to silently have accessibility rights?

You're assuming everyone trusts Dropbox with all their files and that everyone installs their kernel extension, which is a wrong assumption.

If we're worried about theoretical abuse, the client could access all of your files because it runs as you.

You can opt out of the kernel extension? Still, you give it root to install, and it has a long history of hacking the file browser to get icon overlays... it seems weird to me that this would be a deciding factor.

I was under the impression that the kernel extension was a separate product, it's being included in the standalone Dropbox application? You do have a point about giving it administrator privileges, the post however shows very clearly that they are abusing your trust which is enough for people to think twice before using their application..

What kernel extension? Dropbox has a Finder plugin for badges, but what would they need a kernel extension for?

This kernel extension:

/Library/Extensions/Dropbox.kext

And good question.

I don't see that on my Mac, probably a different client version. I guess it's related to Project Infinite:

https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...

>you trust dropbox with your files, and you trust them with a kernel blob implementing the filesystem, but you don't trust them to silently have accessibility rights?

The problem here isn't that you don't trust them to have accessibility rights, it's that Dropbox has phished your root password, stored it, and will continue to modify your system to meet it's desired operating criteria.

Trusting them with some files that you knowingly add vs giving them root permissions and password are two totally different things.

The kernel extension implements Dropbox Infinite.

>- We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

Direct from the DB engineer at top of thread.

If that's the case, How is it that the accessibility preferences are changed without root authorization?

Presumably with one of the suid executables you authorized when you typed your root password to the dialogue.

And one of them is writable by anyone -- great security, guys!

Does OS X not clear suid when a file is written to?