Hacker News new | comments | show | ask | jobs | submit login
Dropbox is using an unsigned binary to install kernel extensions on your Mac (twitter.com)
263 points by tnorthcutt 267 days ago | hide | past | web | 70 comments | favorite



Hi folks, I work at Dropbox...

- We assert the validity of this binary through other (cryptographic) means in the Dropbox Application.

- We're going to start sign it using the means that JZ's tweet refers to, in addition to our existing checks, to avoid confusion.

- The kernel extension / driver is signed by Dropbox (and this binary asserts that anything we install is signed only by us).

- The kernel extension / driver is opt-in and not enabled for the general population (it's used in our implementation of Smart Sync, née Infinite).


Can you please make installing a kext an option, rather than trying to install it behind our backs? If you unload + remove the kext, it gets installed again automatically.

The only way to block the kext is using e.g. Little Flocker.

Moreover, the kext does get installed on my machines and I have a Pro account without Smart Sync.

I have been pondering to uninstall Dropbox, because all this behaviour is not acceptable. Unfortunately, I haven't found a good alternative yet.


Can you check if you're in the (opt-in) Beta Channel by looking at https://dropbox.com/account at the checkbox that says "Include me on early releases"? It's not uncommon for folks to have clicked this long in the past and not given it thought since.


Yes, I am in the early releases channel, sorry for not mentioning that in my earlier comment. But I still don't see why it should install a kext for functionality that is not provided?


The beta channel exists so that we can ensure upcoming components are stable, if you're uncomfortable with this you can always switch back to the stable channel. We'll add a help center article to make it more clear what happens when you opt-in to early releases.


The only reason for this kext to be installed as aggressively as this, is because it is vital for Dropbox Inc. to use to capture their users. There is no valid reason for this kext: none, zilch.

Frankly, I find this use of kext's offensive. I'm putting Dropbox in my "do not recommend" list.


These shenanigans finally made me delete my Dropbox account, and set up an OwnCloud instance on Digital Ocean.

I've found the OC client to be very nice on the platforms I use (Linux, Windows, iOS). The Dropbox client on Linux was terrible to the point of being unusable.


> These shenanigans finally made me delete my Dropbox account, and set up an OwnCloud instance on Digital Ocean. I've found the OC client to be very nice on the platforms I use (Linux, Windows, iOS

So an implementation-detail for a feature on a platform you don't use caused you to shift to another product, which doesn't even support the feature you are complaining about? Am I reading you correct?

By all means. If you're happy running a FOSS solution on servers you control, more power to you. I'm just confused about your reasoning.


> So an implementation-detail for a feature on a platform you don't use caused you to shift to another product, which doesn't even support the feature you are complaining about? Am I reading you correct?

I don't think he's talking about only this one issue. Dropbox had an issue with something of this sort recently [0]. They secretly gave their Mac application root privileges. They may have crossed the line for him here. I should say that I'm not speaking for him but I can see how something like this could have been the last straw for someone.

I personally think that the way a company treats it customers is a good display of how good it's culture is. It's not a good sign that they did this.

[0] https://news.ycombinator.com/item?id=12619722


Is this a different issue, or just a different part of the same thing ?


I hazard the latter since they have had a series of problems except the one here.

There was also a time that when you uploaded to Dropbox a file that was already on its servers, instead of storing the new file they stored a reference to the old one (that they already had) as per https://news.ycombinator.com/item?id=2478567


If it's a feature I don't want and can't disable, yeah, I'm going to investigate alternatives that don't have it.


More likely referring to the fact that Dropbox has had many an issue lately of doing things that may not have been intended to look nefarious, but look that way nonetheless. This is just the last straw for some users, whether or not the feature was used by them.


I actually do have a Mac machine, but I use it so little I didn't include it.

Anyway, there have been other Dropbox issues of a similar nature reported here on HN, and while I haven't been harmed by them personally, it speak to a style of development I don't agree with.

But what finally pushed me over the edge, was this racist initiative at Dropbox. I want no part of that.

https://blogs.dropbox.com/dropbox/2016/12/diversity-at-dropb...


Automatically self-installing a component when I have removed it is malware, not "implementation detail".


Yeah, can vouch for Owncloud (although I've moved to the NextCloud fork), its a convenient replacement for Dropbox, just thrown an OrangePi Zero ($7), a JMS567 USB 3.0 to Sata adapter ($3) and any old HDD and you've got yourself a libre Dropbox that uses just a few watts and works consistently on all platforms.

Note that the Wifi drivers aren't libre, but besides that everything else on the OrangePi Zero, from audio to ethernet is in kernel 4.10 under GPLv2.


Do you think something like this is feasible for a home media server? I suspect things like video streaming from this would be slow, am I wrong?


Am not OP, and not speaking from direct experience,

but a coworker was using a Pi-2 as a home media server without issue in some situations - basically he did the math on the bitrates per second and determined that the disk/wifi I/O (on the shared USB bus) was fast enough for his use case (IIRC streaming to main TV, possibly 1-2 more devices)

I do know he was looking at upgrading to another mini-arm board with a dedicated PCI Nic or separate SATA due to the bus contention on the USB limiting data/network I/O because he wanted to serve more clients (family of 5 and associated devices)

so I guess the short answer is 'maybe, depending on use case'..


The OrangePis have much better IO (with the exception of the OrangePi+ 2, which is a bad buy), with each USB port being direct wired & capable of 40MB/s, and an onboard 100mbps PHY. Comparatively, the Raspi shoves all that over 1 USB port, ethernet included, so 4 to 5MB/s is about the best your gonna get with it.


You don't need to stream the data from the OPi, that is the wrong way for watching video because it would transcode the data on a light processor then send it unpacked on the network, which would consume a lot more bandwidth.

Once you have the files on the disk attached to the board just set up a NFS and/or SMB server on it and let the clients players mount it as a network drive and suck the data. This way you can for example have all home TV sets playing each one a different movie at the same time.


>Do you think something like this is feasible for a home media server?

Absolutely. It's easy to install, works great, the only problem you need to solve is DNS. Either you need to use a service to point the domain to your dynamic IP or rent a static IP for your home address, which could pot expose your home network to attacks.

>things like video streaming from this would be slow

Depends on your uplink. Probably. If your home internet is fast you can stream for yourself or even a couple of people, but you can't really run a video streaming operation. It's easy math, just watch your bandwidth while your stream a video. On private customer plans, uplinks are usually artificially made a fraction of the bandwidth of downlinks by ISPs because they want businesses to be unable to run on them and buy the more expensive options instead


Well, you're probably not going to push 4K reliably. I have a feeling that tech will actually catch on, as opposed to 3D.


If you get an OrangePi 2e ($35) or an OrangePi PC2 ($20) both have gigabit that performs well, you could easily push 4k reliably from either. They also have libre VPU support so you can playback 4k content if you plug in an HDMI cable.


I like OwnCloud as well and use it for all my dev stuff, keeping things synced between desktop and laptop (and my hosted server).

The one issue I've had was sometimes if it tried to sync while I was working in my IDE (gamemaker studio), somewhere between saving and compiling it would lose sync and want to redo the whole folder. I tended to pause sync until I finished working. Could have been a bug that was since fixed, but I still do it just in case.



I second this. I would much rather not have Dropbox install any kexts at all, and the only thing preventing me from replacing it (so far) is widespread support on iOS apps and Linux (which I rely on for a few things).

Otherwise I'd have switched by now - as many folk point out, this is the third or fourth time this kind of approach has come to light, and it reflects badly on the company and the product.


For Google Drive on Linux I've been using Insync happily for a long time now: https://www.insynchq.com/


I installed that software on Linux. It then randomly spread my music library around my Gooogle Drive. Support's answer "Your local sync db must have got corrupted. But here is a list of all the files that got moved" wtf?!


I've had an extremely good experience with syncthing. There's no kext and volunteers run relay servers to get around NAT (everything is encrypted so you don't need to worry.)


I wish they'd combine the relay server functionality into syncthing itself so that it could automatically use peers as relay servers.

I'd prefer not to rely on the generosity of others or running the relay server and having to manually configure syncthing clients to use it.


Thanks for the Little Flocker tip! Didn't know this app yet!


+1 shut up and take my money :)


My personal experience here only: Google Drive + INSYNC is a pretty damn good combination which replaced Dropbox entirely for me. (edited... written insync wrong).


Is there a culture at Dropbox that just encourages these kind of dark patterns? I originally started using the service out of respect for Guido's work, but it seems obvious at this point that Dropbox has little respect for users' security or privacy and will push through this kind of nonsense, hoping that their less-knowledgeable user base won't catch onto the implications.


Well, as far as I'm aware, there have been no actual implications. I think it's a perfectly reasonable summary to say that Dropbox does a bunch of weird shit to enable features customers want that can't realistically be delivered any other way, and so far there have been no drawbacks to the approach in practice.

I get the argument from the other side as well, but if you're Dropbox, you just want to make the best file-syncing application you can make, and any other choice they could have made in these situations would be worse in lots of ways. We can quibble over which set of compromises is the right set, but I doubt you'll find a single set of uniformly preferred options. To be sure, there are probably some low cost wins they could make -- making the signing status of everything more obvious, etc., but I'm not sure what your desired outcome here really is.

I guess I mostly just find it annoying that people seem to think anything other than presenting my 67 year old mother with a dialog of full disclosure about kernel extensions is somehow the nefarious work of a shady company rather than a conscious design arrived at through a reasonable comparison of the options.


Because there is no middle ground here, like, say, a sensibly labeled checkbox in the preferences, which defaults to on?

As for implications: We're here talking about it. That is an implication. This is not the first time either.

As for uniformly preferred: not futzing around with system level stuff without a preference or notification tends to be pretty much universal.


What is a "sensibly labeled checkbox"?

    [x] Enable Smart Sync
    [x] Install Dropbox drivers required for Smart Sync
What happens if I uncheck the second checkbox but not the first? Does Smart Sync just sit there and look sad?

Maybe just a note under the Smart Sync thing saying "Smart Sync drivers are installed. Disable Smart Sync to remove"? Will that actually make anyone happier?

Also—Dropbox is a filesystem. (Logically, the entire product is a filesystem; pedantically, traditional Dropbox might not be but Smart Sync definitely fits the definition of a network filesystem.) Traditionally on UNIX, if you're installing a third-party filesystem like AFS or Lustre or ZFS or whatever else, you're installing drivers. The fact that installing a filesystem installs both userspace software and drivers doesn't feel weird to me at all.


> What happens if I uncheck the second checkbox but not the first? Does Smart Sync just sit there and look sad?

Is this a serious question? I've seen dozens if not hundreds of UI's that gray out a checkbox (either with or without the box checked) once you click a different one. Obviously this might not be an optimal solution for this specific dialog, but you could easily do something like:

[x] Enable Smart Sync (NOTE: This requires installing a driver onto your computer)


This is actually what the opt-in looks like for Smart Sync (except at an admin level since team admins opt their users into it). There's also an individual opt-out if your team admin has opted you in and you don't want things enabled.


Traditional UNIX filesystems didn't backdoor the accessibility panel for persistence.


Well, where the analogy falls down a bit is that traditional UNIX filesystems have traditionally been installed and maintained by UNIX systems administrators.

My point wasn't to blindly defend everything Dropbox has done. I'm sure they've made mistakes, both in design and implementation. My point was that things like their hack of the accessibility panel are, in my opinion, overblown by the average technical reader.

I think bothering the user with an accessibility panel is tedious "Charlie work" that I'd prefer be avoided. I understand why it works the way it does, and I understand the theoretical risk the OS is trying to mitigate. But I'm already trusting Dropbox with my data. It's silly for the OS to treat them like some unknown piece of malware, it's just that the OS isn't a generally intelligent agent able to make accurate determinations of that sort.

I get all that. It doesn't change the fact that I as the user of my computer just want Dropbox to do whatever it needs to do to work. I'm capable of doing the accessibility dance that most applications require, but not everyone is, and I think it's a reasonable position for Dropbox to take that if users are signing up and downloading our app, then implicitly they trust us to check the accessibility box. Is that an objectively acceptable argument? No, but all I'm arguing is that it's reasonable. It doesn't imply maliciousness that that's the argument that won the day inside Dropbox.


I think at least some people object more to the less than forthright disclosure of what they're doing than the technical tricks. If they had a blog post "behind the scenes at dropbox kext headquarters" that'd be fine. It's the coverup, not the crime.



Yeah, something like that would be pretty good. :)


I'm not sure that's true, actually. The ways that AFS hooks into the kernel, especially on kernels that don't have actual loadable module support (older commercial UNIXes) or on kernels that try to limit syscall hooking (e.g., Linux), are distressingly close to the ways that a rootkit hooks into the kernel.


>I originally started using the service out of respect for Guido's work

Guido has nothing to do with Dropbox, apart from being an employee at the company. He is neither the one who created the platform, nor is he responsible for how it operates.

It would be like using Gmail because you respect Brian Kernighan.


And what would be the issue with factoring that into your choice?

At the time I was choosing between these kinds of services, Dropbox and its competitors were all pretty comparable. I have great respect for the Python community and it's values, so when I learned that Guido was working there and that they were giving him time to work on Python, I thought it indicated a positive company culture. Why not go with Dropbox, all else being equal. Then they pulled this kind of BS repeatedly and appointed Rice to the board. I guess lesson learned about thinking good people will work at places that align with their values.


>And what would be the issue with factoring that into your choice?

Obviously that it would be an irrelevant criterion?

Besides you answer that yourself: "I guess lesson learned about thinking good people will work at places that align with their values."


I don't think that hoping for quality work and a promotion of good values from someone with a track record on those issues is an irrelevant criterion. I may end up being repeatedly disappointed, but I'd rather weigh it than not.


Dropbox has been willing to get their hands dirty in their pursuit of user-friendliness since day one, especially on the Mac¹. Didn't find any examples where they walk it back; usually they stick to their guns with a few minor tweaks (and top-of-HN-discussion PR replies).

Dropbox Hasn't Learned Their Lesson https://news.ycombinator.com/item?id=12619722 (2016) "You seem to completely miss the point. It's not about the feature itself, it's your way of "hacking" or "injecting" Dropbox features into places the user didn't expect."

How Dropbox Hacks Your Mac https://news.ycombinator.com/item?id=12463338 (2016) "It's very strange that after I remove Dropbox from the accessibility list you think it's ok to add it back in again."

Dropbox accesses all the files in your PC? https://news.ycombinator.com/item?id=9136546 (2015) "It does, however, 'QueryBasicFileInformation' and and 'QueryDirectory' when I create a file on my desktop."

The Tech Behind Dropbox’s New User Experience on Mobile, Part 2 https://news.ycombinator.com/item?id=8203164 https://blogs.msdn.microsoft.com/ieinternals/2014/09/04/cave... (2014) "what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does"

Dropship — successor to torrents? https://news.ycombinator.com/item?id=2478567 (2011) "Apparently Dropbox notices they already have that file, and instead of you uploading it they just make it appear in your account." CEO Drew Houston actually did the PR for the cleanup: https://news.ycombinator.com/item?id=2482712

¹ http://mjtsai.com/blog/2011/03/22/disabling-dropboxs-haxie/ (2011) "Dropbox injects code into the Finder in order to draw the green and blue badges atop your icons"


> Dropbox has been willing to get their hands dirty in their pursuit of user-friendliness since day one, especially on the Mac¹.

Where Apple is providing zero of the APIs you typically find on more open platforms, like Linux and Windows.

Can't say I blame them. The other option would be to have a completely user-hostile installer and we all know how well they fare with the general public.

Installation these days has to be one click, or nothing at all. Otherwise you've lost your user.


> The other option would be to have a completely user-hostile installer

I'm unconvinced that a horrible installer is the only alternative, but even if it were, you are asserting that you see subverting OS security mechanisms and intentionally ignoring user intent as somehow not user-hostile?

From my perspective, DB was kinda nifty when it first came out. The gap has been filled by commodity software for folks who can deal with self-hosting, so I'm personally happy. For other people, everyone and their pets wants to offer us all seamless hosted storage; there's no need for a glorified rsync service to be this creepy, evasive and intrusive.

> Otherwise you've lost your user.

I remain unconvinced that the various actions linked in the above were all required for a nifty install experience. Indeed, some of them are only required for forcing "features" on users that many have repeatedly indicated they don't want, after that all-singing, all-dancing install experience is over.

Which, turns out, is a great way to lose your user.


to be quite honest. I am happy they do these little hacks to improve the usability. If anything i find Apples lack of pushing OSX forward to be the real issue.


Not enough companies do this. User experience and ease of use is frankly one of the most important things (and this is coming from a developer).

I can't remember the amount of times I've gotten frustrated with (beautifully written) open source software, but with a horrible complex UI that takes hours to figure out how to use. Those are hours of my life I'm not getting back.

Why can't stuff just work?

Disclosure: I've actually made a fair penny taking open source projects (not adjusting anything) and slapping a nice UI on it, doing nothing more than that. Good UI and UX matters and people will pay for it.


Agree but if you want thing to work on appstore it become even worse. Thats why i pulled my app from the app store 6 months after lunch and instead are selling directly. Havent looked back since.


How was the revenue from the App Store for your app? How is it now in comparison? How do you market it?


The rev is the same. I was in top 10 on the app store for a good while it didn't do much to my sales so the benefits unless Apple decides to promote you for OSX are more or less null. At least in my experience.

I realized that for the kind of niche productivity software I made Google is a much better app store.

I mostly live of organic traffic and only do actual marketing once in a while. The best is when the product gets exposed to communities who are into productivity.


Out of curiosity, do you know if competitors (like Google Drive) are doing similar things like injecting code into Finder?


Not really. In the latest versions (maybe since Yosemite?), Apple has provided a Finde Extension API that has hooks for badges and right-click menus. That's what everyone's using.


To be fair though: Dropbox is using that Extension API too for all the features it provides which basically is: Overlay icons and context menus.

They patch the Finder for all the additional features like their overlay toolbar and other little things, none of which I particularly like, but still - they are additional features lacking in Google Drive and friends.

As such I think it's not quite fair to say that Google Drive is much better for using the official API when it also doesn't provide additional features that are not supported by the official API.

Also remember that without DropBox and friends patching Finder in the past, we would likely never have gotten the API in the first place. Sometimes, in order to make a platform owner advance a platform, you have to work around their existing restrictions.


I was hoping for an answer like yours. Thanks!


Is Condoleezza Rice still working for Dropbox?



What value of "kernel" is involved here? It's a tweet, so there isn't much to go on. I ask because I have this possibly naive view that one shouldn't need an actual "kernel extension" to sync some files...


Probably the "Infinite" extension [1] that lets you evict files from your disk while still storing them in Dropbox. It's an opt-in feature (and perhaps only available to Business customers?).

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


One shouldn't need a third-party to get involved in sync'ing some files, but .. we do.


Uninstalled and closed the account. Thanks Dropbox!


The Twitter account seems to have been deleted.


mirror: https://webcache.googleusercontent.com/search?q=cache:CgzTBD...

content:

> So @dropbox is using a completely unsigned binary to install kernel extensions on your Mac. This behavior is indistinguishable from malware.


archive.is copy: http://archive.is/Wl7Ma




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: