12 comments

[ 4.6 ms ] story [ 18.4 ms ] thread
On a single-user machine all the interesting stuff (personal documents, configuration, browser history etc) is in userland anyway. And people are already entrusting Dropbox with their personal files.

I'd say this article represents Twitter-fishing -- search the comment-ome on any recent event and you'll find somebody panicking, or being crude, or whatever else you want to write an article about.

I cannot see any reason whatsoever, that this has to run in the kernel.
I guess when a program asks to read a file, dropbox has to intervene at quite a low level to get it from a remote server rather than the local file system where the program thinks it is.
On Linux you can use Fuse in userland. On OSX I'm not sure.
Fuse filesystems on OS X are user-land applications entirely outside the kernel. However, I believe OSXFUSE itself, atop which the filesystems are built and operate, requires/includes a kernel extension.

(Edited for better explanation than initial wording)

That's right. OSXFUSE includes a kernel extension (https://github.com/osxfuse/kext). There is no other technical way to achieve this without a kernel extension on both Windows and OSX.
There is FUSE on OSX, but Dropbox said it was not performant enough for them
Fuse in Linux also requires a kernel module. It's just that it is available everywhere these days.
Wow. Pretty garbagey article. Yes you can find some people on twitter that wouldn't want to load a kernel extension from Dropbox. Back in reality: nobody will even know, nobody will care, everybody will be happy if "it just works".
Tomorrow's headline: "Dropbox lays off enterprise sales team"
I would have no problem with a kext from Dropbox as long as they publish the source and use reproducible builds.

But given their ties to the US National Security establishment I would definitely pause before giving them blind kernel access.

Condoleeza Rice wants a kext now? Glad I never jumped on the Dropbox bandwagon.