Comment by brentdax
10 years ago
> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
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. 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. (I don't work for Dropbox or anything; I've just been poking around.)
> - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
@newhouseb, I don't have Office, so I've turned off the badge. 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?
I understand the desire to make your features "just work", but circumventing the user's privacy controls to do that is never acceptable. Especially accessibility, which is basically a general warrant to snoop on everything the user does. You wouldn't be on my system anymore if my work didn't require Dropbox. You're going to lose a lot of trust over this, and it won't even be half of what you deserve.
And it's not even in your interest in the long term. This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement. Since Dropbox can't really do its job when it's locked in a sandbox, I really don't think that's what you guys want to happen.
Teams like yours are why we can't have nice things.
(P.S. plz respect NSFileCoordinator this isn't Tiger anymore kthxbai)
> @newhouseb, I don't have Office, so I've turned off the badge. 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?
Yep, we’re going to fix this so that if you uncheck it, we leave it unchecked.
> This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
As alluded to elsewhere in this thread, this is already happening in macOS 10.12. We’ll be switching to the same approach that Steam (among others) do to request accessibility.
Honestly, after the last year and a half, anything that wants root access, that is not open source, is out. Now, being open source does not make that automatically safe but it is a step in the right direction. Dropbox, MS Office, etc, are closed source tools that puts too much at stake.
Granted my team is small, but we just uninstalled dropbox today. Going to use the web interface and look for another solution in the meantime.
I'd love to hear what you find. My research has shown that Dropbox is mostly the only sync service supported in mobile apps. iCloud is next. After that it's very rare to see any other integration.
I'd love to see Box or someone else encourage popular apps to support their sync platforms, but I doubt it will happen. I blame Apple for not supporting easy 3rd party integrations.
10 replies →
Mac OS X is a mostly closed source operating system so I don't understand why you are drawing the line with third parties.
2 replies →
Try SyncThing. It's cross-platform (written in Go), fast and secure (BitTorrent Sync style, but open-source).
3 replies →
I should say, Ben, thank you for coming out in public and sharing your team's perspective. Your users are angry—and I think rightly so—but it does help that we are being told why it was done, that it was merely poor judgement rather than deliberate misbehavior, and that you are working to make the Dropbox client a more responsible citizen. Is it as good as not having done it in the first place? No. But it's much better than radio silence.
Wow, it's stunning that an app would install anything suid root.
Admittedly I'm not a Mac guy, but that can't be common practice.
And then the response isn't "we're going to stop endangering our users with this dangerous practice", it's "we're going to stop doing this one particular thing that happened to be called out this time".
> that can't be common practice.
It's not. It's very unusual.
> more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
Please feel free to duplicate my radar! Accessibility and Productivity/Utility app developers would love a Sandbox entitlement.
rdar://13570189 - Sandbox entitlement for Accessibility API to allow apps for the disabled
The Accessibility toolkit has always been off limits to Sandboxed apps, and no entitlement exists. This seems unlikely to change. It's unfortunate, as this keeps many good and useful apps out of the Mac App Store.
Is it worth adding that to OpenRadar?
https://openradar.appspot.com/search?query=13570189
I don't really see the point of taking a sandbox and then explicitly granting an app inside the privilege to step out of it.
I don't really see the point of banning Accessibility apps that can't be sandboxed but then allowing those same apps to be distributed outside the Mac App Store. Unless you're banning them from macOS entirely, why not allow these potentially "dangerous" apps to operate underneath the additional Reviews and Guidelines of the App Store?
2 replies →
Not from Dropbox but when you remove an app from accessibility permissions OS X will make you manually enable it again.
mikewhy: The article states that it re-adds itself to the list automatically the next time you log in, without asking for permission again. There's no option to keep it permanently disabled.
You could delete all of their suid helper binaries.