- Clearly we need to do a better job communicating about Dropbox’s OS integration. We ask for permissions once but don’t describe what we’re doing or why. We’ll fix that.
- We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.
- We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
- We use elevated access for where the built-in FS APIs come up short. We've been working with Apple to eliminate this dependency and we should have what we need soon.
- We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
- We check and set privileges on startup — the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. The intent was never to frustrate people or override their choices.
We’re all jumping on this. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused.
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)
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.
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".
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.
If I unzip a large archive in /tmp, Dropbox is eating 60% of my CPU.
If I open the new Xcode for the first time (and the system verifies all the signatures) Dropbox is eating 100% of one CPU.
It really seems like the Dropbox client is monitoring the entire filesystem (all FSEvents) instead of just the dropbox syncing folders, and doing it relatively inefficiently at that.
At this point if I'm doing anything filesystem intensive I close Dropbox first.
It started with my laptop running incredibly slow. A bit of digging showed dropbox saturating an entire cpu core despite no recent changes being made to my dropbox folder. What was happening at the time is a lot of disk activity on a folder that Dropbox should know nothing about. I'm not 100% sure but it also seems to me that Dropbox is monitoring all FSEvents on my machine and doing something with them.
I've been a paying Dropbox user for several years, but this has tipped me over the edge. The only way to regain my trust at this point is providing an official explanation of what's going on, with technical details. I'm paying for a service to keep my files safe and sync them across devices, nothing more, nothing less. Now that I got the impression that Dropbox is doing something outside of that envelope, even if that impression is wrong, my money is going to go elsewhere, probably to a competitor.
As to the original article, I think you have a lot of explaining to do and a lot to clean up. Too much has been swept under the rug.
Would definitely like an explanation of what's going on here.
(Support was prompt but basically “let us know if it happens again”)
Then I start getting console messages like this: mds (Error) FMW: WE ARE DROPPING FMW EVENTS!
All disappears after disabling Dropbox (and rebuilding caches and the spotlight database)
Behaviour seen on multiple macs I own.
This has been a long-standing thing with them - some years back there was some stink about the forced Dropbox branding in the Finder (which we now see is related to this). Many people (including me) found it rude that it insists on adding useless widgets, badging icons and inserting crap in the Finder sidebar. For whatever reason, Dropbox (the corporation) apparently believes that junk to be important enough to their business to disregard what the owner of the machine wants, and now we see the lengths they go through to force themselves on the user.
I used to simply consider Dropbox rude enough to make me not want to use it. Now that I see the company is actively going out of their way to break the intended function of security-related OS components, I now consider Dropbox malware and will begin warning others about the company.
Permission systems in general seem like a solution without a problem to me. Nobody but a minority of people very concerned about theoretical security problems wanted them on platforms that didn't have them, almost nobody cares what permissions programs use on platforms that have them now, and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights today on Windows and Linux.
The reason for needing Accessibility API listed in your response is pretty vague, especially for those Mac users not having Microsoft products tainting their systems.
I've deleted Dropbox from my Mac for now. I'm not installing it back till there's reasonable explanation and remedies.
I'm not affiliated with Dropbox, but compare the UX of Dropbox (type in your admin-password and that's it) with the one of Steam (opens the System preferences and forces you to make manual changes). Both need to be allowed accessibility access for one feature or another, but only one of them provides convincing UX.
For us power users, the "official" way is better, sure, but what's the percentage of power-users compared to normal users who actually enjoy the office intrgration and other things made possible by the accessibility API?
I would be happiest if it didn't do the dirty thing and also didn't offer office integration. Maybe that's the change they need to make. But if they insist on doing the things that need accessibility, then the current solution is so much more convenient than the steam dance.
One wonders what Dropbox would say if someone decided to obtain elevated access on their servers by surreptitious means because Dropbox's API "came up short".[1]
[1] https://www.dropboxforum.com/hc/en-us/community/posts/204550...
Can you please provide an example of such shortcomings and accessibility APIs that are better?
When you designed an agent that specifically overrides the user's choice to turn off Accessibility rights for Dropbox, frustrating that attempt, I suspect that was intentional.
Bob (who less technically savvy) installs Dropbox for use with Office. Chuck (someone more technical than Bob) removes Dropbox from the accessibility list. Chuck has now broken Bob’s Dropbox, and Bob (being less technically savvy) blames Dropbox resulting in another ongoing thread about broken Dropbox.
I completely understand how Dropbox reached this point, and purely from a technical support point of view, how it is justified. There are probably better ways for them to have done this (still have the “hack”, but only insert it if Office applications are detected to be installed; have an option that can turn it off even if Office is installed, but warn about it and make it “easy” to turn back on).
If that's the case, How is it that the accessibility preferences are changed without root authorization?
Other Integrations: Too vague to justify what is potentially a large security threat. You've really got to do better than that.
Which API are you using that allows you to circumvent the OS X Accessibility Permissions control dialog? Or do you mean you're simply asking for administrative permissions in order to write directly to TCC.db? And in that case, what mechanism are you using to circumvent the permissions structure to permit you to rewrite to TCC.db without re-requesting the user's permission?
Nice euphemism for "catch all" permissions...
- There are numerous setuid binaries without any documentation or source code available. These have the potential to breed nasty zero-day privilege escalation exploits, possibly worse.
- Dropbox goes out of its way to obfuscate its Python bytecode. This doesn't prevent intellectual property theft: there will always be people capable of reverse engineering it (e.g., https://github.com/rumpeltux/dropboxdec). The only effect that it has is to significantly decrease the security of the application: technical users can't easily review the inner workings without a substantial time investment. Hackers, on the other hand, have massive profits to gain from reverse engineering something as popular as Dropbox, and won't hesitate to do so. This represents a lack of regard for security on Dropbox's part, indicating that they favor intellectual property protection over the security of their customers. When I buy a car, I can open it up, check the brakes, and be sure I'm not going to crash into a tree. I expect to be able to do the same with the software on my computer.
Output from extracting a Dropbox-signed tarball (in this case, DropboxHelperInstall's own tarball):
<pid>52229</pid>
crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
mkdir '/Library/DropboxHelperTools' 0755 -> 17
extracting ./._DropboxHelperInstaller
extracting DropboxHelperInstaller
<ok>
<pid>52286</pid>
missing magic number
unable to read_digest
couldn't verify signature
<failure> -1
<pid>52142</pid>
crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
crypto error while Verifying Signature: bad signature (in rsa routines:INT_RSA_VERIFY)
couldn't verify signature
<failure> -1
Off topic: can you help me understand why when a file is locked (e.g. Outlook accessing .PST file) this causes Dropbox to peg the CPU to 100%.
I've opened multiple bug reports over the years and support dismisses my finding.
This makes Dropbox un-usable for me. I literally have to run Dropbox as "paused" 90% of the time and only "unpause" Dropbox when I close Outlook.
Is it a native OS X dialog API, or native OS X authentication API? I could make a password prompt myself, and call that "being official Win32 API".
Can you show me the class where you invoke it, so I can judge for myself?
https://developer.apple.com/library/mac/documentation/Securi...
If you look under "Authorization Services Tasks" you'll see there's details about calling a privileged installer.
Apple really should kick you from the App Store and blacklist dropbox as malware.
And as for the rest of the privileges, we just take them without asking. Who knows, someone might refuse!
AMP articles are so much easier on my eyes (and the author can't include their own javascript on an AMP page, so there is less bloat). I wish all bloggers started to publish AMP pages.
[0] - http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
[1] https://www.ampproject.org/docs/get_started/create/basic_mar...
Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." [1]
Who gave them the authority?
AMP worries me greatly.
[1] https://github.com/ampproject/amphtml/blob/master/builtins/a...
Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.
(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)
AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.
AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.
This isn't really a solution when many authors use a CMS, like WordPress and others, where the bloat is built-in. Sure you can write a custom theme etc, but not everyone (1) has the ability to do that, and (2) wants to dedicate the time to do that.
AMP integration still a work in progress, but getting better: https://github.com/Automattic/amp-wp
I wish all bloggers with sites so bloated that AMP is a fundamental difference didn't feel they needed to include large image assets, custom fonts, and fancy JavaScript libraries (not suggesting this blogger does - just a general complaint).
In my mind Dropbox became a company not worth supporting when Rice joined Dropbox's board (http://www.drop-dropbox.com/). Personally, with a board member who advocates warrentless surveillance it seems unlikely that we share similar views on the security of my data, and I wont be using their service.
What better way to gain access to users' files than through a startup's free app that demands your password?
So even outside of this surveillance stuff I don't get the point in using them.
Another significant advantage is that they support a stable command line client for Linux.
I know it's CS 101, but neither Google Drive, iCloud, or OneDrive do this.
Not to mention the other services have bizarre naming limits (e.g., dotfiles are forbidden on OneDrive).
Also, DropBox supports Linux officially.
Oh, and they always supported the big three OSes.
These last two features makes them stand out against the myriad of alternatives. (Especially the offerings from Apple, Google and Microsoft are laughably bad.)
Dropbox is more expensive but not that more expensive given that it just works.
That said, I switched a couple of months ago to Seafile (the German branch) and it has worked almost as good as Dropbox.
The reasons for switching were: not based in the US, supports more OSes, Rice, cheaper.
Some features like selective syncing do not work as well but others like multiple libraries are a solid addition.
I have run into a Git repo issue on Seafile that I never had on Dropbox and the client on Windows could not sync some files due to the filenames (luckily those could be renamed).
It's the only service with decent cross platform support, and by that I mean first class Linux support is a 100% requirement.
And Dropbox is among the only ones with Linux support.
I switched all my data (about 250Gb) to them from Dropbox a couple of months ago and it has worked out well enough.
Features:
- servers not based in the US
- encryption
- privacy
- open source (thanks lima)
- multiple libraries (like multiple separate Dropbox folders)
- nice file manager for unsynced (parts of) libraries
- price
- payment options (Bitcoin)
- supports more OSes
- one can run one's own server
Cons vs Dropbox:
- syncing problems not always obvious
- some UX issues
- photo support
- selective sync cumbersome (if not using libraries)
- no LAN sync
Totally distributed, works like magic. Being distributed means you do have to blindly trust a third party, but also that don't have to worry about $ per megabite. For example, one of the machines I have in my Syncthing network is a Raspberry Pi with a 3TB drive getting a backup of my laptop $HOME and important stuff from other machines all the time.
I don't actually know if I fully believe that. I haven't seen the internals of how it's implemented, but at the very least most users can assume that only the OS can bring up the prompt, and only the user can make it go away.
With the current OS X password prompt being a benign looking window, Dropbox (or others) can easily say they're just "following standard UI patterns" or something like that.
Almost all of the viruses reported for Macs were in fact Trojans.
And even if there were a few legitimate viruses over the years, none went very far as to cause much trouble to any sizeable number of people. Contrast with the barrage of Windows viruses and widespread mayhem they cause, on a platform were almost everybody uses an antivirus too.
It's not "just" due to the Mac being less popular either. Mac OS up to 9 got lots of viruses back in the day, and Macs had just 1 to 2% market share in the US. Nowadays they have several times that.
So yeah, on my Mac and Linux boxes, I'll care about viruses to the point of running an antivirus or such when people actually start getting some...
If every app I installed did this then my mac is closer to getting hacked.
Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.
You don't need root to do any of those things. If you're going to run the SSH server on port 22, sure, but it can be run on any port above 1024 by a regular user in user space.
If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.
Think a NAT is going to save you? A malicious program can SSH out and create a reverse tunnel to circumvent it.
Short answer: running anything you don't know or trust is dangerous, root access just makes it more dangerous.
So, "How Dropbox uses the root access you give it during installation to gain full control of your Mac without triggering the usual popup."
The first bit, for me, is key.
So it's more like "how dropbox uses the root access you give it after installation to install software which will permanently re-add itself to accessibility even if you attempt remove its authorization".
Being an app developer that was bitten in the ass by the new "security" in El Crapitan, and having spent 2 weeks trying to get our app back to normal, this makes me really mad that Apple makes us developers jump through all these hoops for security that isn't actually secure anyway.
Perhaps better for limited use cases that don't really apply to the vast majority of Dropbox's user base.
You start off comparing apples to oranges, and with your latter solution, you aren't even comparing to fruit anymore.
I appreciate the trend of Apple forcing Dropbox to stop doing dumb shit, though. (Previously, of course, the SIMBL-style Finder hacking)
There was no other way to do what they did. The only reason Apple added API was because Dropbox came up with an idea that demonstrated the need for such an API to exist.
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.
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.
Direct from the DB engineer at top of thread.
setuid binaries:
$ tree -p /Library/DropboxHelperTools/
/Library/DropboxHelperTools/
├── [-r-s--x--x] DropboxHelperInstaller
└── [drwxr-xr-x] Dropbox_u501
├── [-r-s--x--x] dbaccessperm
├── [-r-s--x--x] dbfseventsd
└── [-r-s--x--x] dbkextd
$ kextstat -b com.getdropbox.dropbox.kext
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
163 0 0xffffff7f835b5000 0x6000 0x6000 com.getdropbox.dropbox.kext (1.7.5)If anything Apple have put so many restrictions on OSX and isn't pushing for much innovation on their side to allow people to build ever more powerful apps.
I understand general security concerns but I don't understand the critique of a company like Dropbox. They are doing the user er service not a disservice by finding a balance between pushing the platform forward while still taking your security concerns into account.
I would personally be more concerned with the fact that Apple haven't done anything fundamental for the osx platform in quite a while which is the exact opposite of what they have done for iOS.
All this from a company who recently had one of the largest credential breaches in the history of the Internet
and you think it's okay to "push the platform"?!???!
It's pretty popular these days to say "Delete your account" online. If this wasn't an accidental knee jerk response, please go one step farther and delete any professional involvement you have with software or technology implementation. You don't understand security concerns, nor does your poorly rehashed half-argument about OS X explain why this would be okay on any platform.
A bit emphatic, but if those goes to the greys, so be it. HN is clearly frequented by people with meaningful input in business, product, and engineering decisions. This kind of scapegoat deflection needs to be highlighted as an unacceptable security practice not justified by anything that seems to qualify as entrepreneurial disruption.
Of course you can claim it's malware, but sometimes malware works FOR the user not against them this is an example of that.
If anything you should put your anger towards Apple who haven't done anything to osx platform for ages.
With regards to security I both understand it and take it very seriously but I have no interest in theoretical debates. In this specific case I have no issue with what Dropbox is doing. I have an issue that Apple haven't found a way to make these things possible without the exploit.
If you feel strongly about it, be my guest delete all your accounts. I see no reason not to trust Dropbox, but hey each to their own.
This isn't what SQL injection is.
HN has mentioned this several times in the past. I'm now looking at the prior comments about this.
How do I get rid of the backdoor in /Library/Application\ Support/com.apple.TCC/TCC.db even after uninstalling Dropbox.app and rm -rf'ing ~/.dropbox and /Library/DropboxHelperTools? Do I just sudo sqlite3 and delete the row? Or is there an official tool (tccutil)?
Edit: Crap, there's a /Library/Extensions/Dropbox.kext too now. :(
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db
sqlite> delete from "access" where (service=="kTCCServiceAccessibility" and client=="com.getdropbox.dropbox");
...and it seems to have done the trick.
Now I'm getting paranoid. My /Library/Extensions/ directory contains the following kernel extensions. I purchased Little Snitch so I knew about theirs. Anyone have any comments on the rest of them?
ACS6x.kext
ATTOCelerityFC8.kext
ATTOExpressSASHBA2.kext
ATTOExpressSASRAID2.kext
ArcMSR.kext
BJUSBLoad.kext
CIJUSBLoad.kext
CalDigitHDProDrv.kext
HighPointIOP.kext
HighPointRR.kext
LittleSnitch.kext
PromiseSTEX.kext
SoftRAID.kextWe've had requests for this feature for years. I can't stress how much customers request this feature; it's put a lot of egg on our face that Dropbox beat us to it.
In order to do this on Mac, we'd need to register ourselves as an accessibility client. I don't remember the details about registering ourselves, but from what I remember, it doesn't require hacking into OSX.
We've had to hack into OSX in the past: Adding menu items and icons to Windows Explorer is supported via well-documented Microsoft APIs. It wasn't until about 2014 that Apple supported this, prior to that, we had to reverse-engineer Finder. We didn't get OSX APIs to do this until we hired a contractor with "connections" to Apple he petitioned his connections to provide an API. I know that Dropbox, Google Drive, Box, and an open-source project called Liferay-Nativity all performed the same hack.
Based on my Syncplicity experience is that, what happens in these cases, is that a product manager gets so focused on the pixels that he/she is completely blind to the practical implementations. There's probably a bit of "I told you so" coming from some of Dropbox's engineers now.
Most bad things can be done without the Accessibility API, e.g. apps can act as key loggers, take screenshots, encrypt all files your user can access, upload arbitrary things (unless you have a firewall enabled), synthesize mouse & keyboard events etc.
The Accessibility API makes some of those things easier, but if someone really wanted to attack you, he wouldn't need the Accessibility API.
For sandboxed apps the situation is quite different, because the Accessibility API would allow those apps to break out of the sandbox.
But of course Dropbox should have asked the user...
It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users.
Why not displaying a simple yes/no popup similar to the "allow access to contacts / calendar items" dialog?
Because granting accessibility access is far more dangerous than granting access to contacts / calendar. The latter just exposes some of your user data. The former gives the app a huge amount of control over your computer.
Forbidding window movement doesn't add any security at all.
Anyways, all I want a simple prompt explaining what the Accessibility API does and yes/no buttons.
I'm guessing it's not going to be different from what it does on a Mac, but it would be nice to know exactly...
http://commandlinemac.blogspot.com.es/2008/12/find-suidsgid-...
I wonder if this will get to Apple's attention to "fix" it?
http://stackoverflow.com/questions/17693408/enable-access-fo...
I love the first comment on the question:
> No, there is no way to circumvent the need for visiting this screen. It is one of the operating system's base protections. Any way that is found to circumvent this will almost certainly be patched out. – Jul 17 '13
Needless to say, I never asked or gave consent for Dropbox to integrate with the Finder (and sync still seems to continue to work after I disabled it).
[Disclosure: I used to work at Dropbox.]
Now, why how did Evernote get on the list?
I don't get it. What's so delicious about "dbacces"?