Live data from Hacker News

Dropbox Is Probably Not Stealing Your Files

one.darrenpmeyer.com

41–50 of 105 posts

Re: Dropbox Is Probably Not Stealing Your Files

#41
post #4

This is a fine post, but all I can think about this situation is "or, you could just reverse the Dropbox client and find out for sure". Speculation about Dropbox stealing files seems premised on the idea that you can't know what the client is doing. But that's not even close to true. People reverse much, much harder targets than Dropbox for fun. If any version of Dropbox published to its user base ever did anything l…

I would be very surprised if a workplace name like Dropbox has never been reverse engineered by a bored hacker on a lazy weekend. Surprised and disappointed.

I reversed it back when it was version 1.1.something, it was basically all compiled Python modules with custom encrypted code objects and non-standard opcode mappings for the bytecode.

Quite interesting to see how it worked, and useful to get the key for the encrypted logs, to see it what it actually did while running. Back then you could intercept the https connections as well as they hadn't pinned the certificates yet, to get an even fuller picture.

There was nothing obviously nefarious going on back then, but that was quite a few years ago of course.

Re: Dropbox Is Probably Not Stealing Your Files

#42

"This is, by necessity, a system-wide process." This is, by design, a fucking huge defect of the underlying system calls. Give the OS a list of folders to watch. Dropbox should not even get a callback for a file it's not is supposed to watch.

See: inotify in Linux

inotify is by far the best of the filesystem notification APIs. It's wildly reasonable.

Re: Dropbox Is Probably Not Stealing Your Files

#43
post #27

As an aside, I've been using Sparkleshare (built on GIT and SSH) lately. It's pretty good, and sucks up less battery on my MBP than the Dropbox client (maybe because it's not watching every file in the system!) And not only is it open source, but you can see a log of all the git commands and fix things manually if necessary. My only lament is that it doesn't work that well over the intermittent connections. It'd be n…

[deleted]

Re: Dropbox Is Probably Not Stealing Your Files

#44
post #13
post #8

Earlier quoted context omitted.

To calculate the hash, it needs to read the whole file, which this post claims it isn't doing.

Did the author actually verify this with strace (or the mac/windows equivalent)? It sounds like he guessed this based on I/O activity of the process. It could be enough to hash the beginning of the files, and compare the rest if a match is found in the database.

Dropbox doesn't read the file content. There is also no proof that Dropbox directly accesses those files.

Re: Dropbox Is Probably Not Stealing Your Files

#45

Well, dropbox could just listen for fs events inside the DropBox folder; and it should, from a performance perspective as well as from a privacy point of view. And then "sends a few 100 kByte"? I hope this is a typo; if not, I would like to know what these are. (also: the OP's largish file (1MB) could easily fit into "a few 100kByte" after compression)

Well, dropbox could just listen for fs events inside the DropBox folder...

On Linux at least [1], this is exactly what the Dropbox client does. It only registers inotify watchers on the $HOME/Dropbox directory and subdirectories. To verify:

    strace -f -e trace=inotify_add_watch dropboxd
You could also strace open/stat/read/write syscalls to verify that, aside from shared libraries and the like, the Dropbox Linux client doesn't access files outside of your Dropbox directory.

Other OSes have different file monitoring capabilities though. Anyone up on file monitoring on Windows / OS X? Is directory-specific monitoring possible?

[1] https://www.dropbox.com/install?os=lnx

Re: Dropbox Is Probably Not Stealing Your Files

#46
post #45

Well, dropbox could just listen for fs events inside the DropBox folder; and it should, from a performance perspective as well as from a privacy point of view. And then "sends a few 100 kByte"? I hope this is a typo; if not, I would like to know what these are. (also: the OP's largish file (1MB) could easily fit into "a few 100kByte" after compression)

Well, dropbox could just listen for fs events inside the DropBox folder... On Linux at least [1], this is exactly what the Dropbox client does. It only registers inotify watchers on the $HOME/Dropbox directory and subdirectories. To verify: strace -f -e trace=inotify_add_watch dropboxd You could also strace open/stat/read/write syscalls to verify that, aside from shared libraries and the like, the Dropbox Linux clien…

> Other OSes have different file monitoring capabilities though. Anyone up on file monitoring on Windows / OS X? Is directory-specific monitoring possible?

yes

Re: Dropbox Is Probably Not Stealing Your Files

#48
post #21

Quote: "A simple protocol can give us an idea of whether data is being sent to Dropbox: 1. Create a large-ish file (1MB) outside of the Dropbox folder 2. Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file 3. Repeat with many different files, etc. Doing exactly that, Dropbox only sent a few hundred KB after “accessing” the target file. Seems unlikely that Dro…

You’re still missing the possibility of DB uploading a hash vs standard file compression. Even if they never upload the full file plenty of people would love to know if any of your files was on some list. (Classified information, piracy, etc.)

Re: Dropbox Is Probably Not Stealing Your Files

#50
post #32
post #24

Earlier quoted context omitted.

[deleted]

Dropbox for Linux runs just fine as a user-mode program. Besides, Dropbox does much nastier stuff than look at your files; it bloody hooks into your shell (Finder/Explorer) and manipulates the icons. It could decide to replace an .exe icon with the icon for a Word Document, for example.

[deleted]
Post reply on HN