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".<p>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 like this, we'll all know soon enough.
"This is, by necessity, a system-wide process."<p>This is, by design, a fucking huge defect of the underlying system calls.<p>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.
Quote:<p>"A simple protocol can give us an idea of whether data is being sent to Dropbox:<p>1. Create a large-ish file (1MB) outside of the Dropbox folder<p>2. Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file<p>3. Repeat with many different files, etc.<p>Doing exactly that, Dropbox only sent a few hundred KB after “accessing” the target file. Seems unlikely that Dropbox is uploading files outside your Dropbox folder."<p>This test approach has a problem. A more realistic test would be to place a well-compressed file, one that by definition cannot be made smaller, on Dropbox and see what the system traffic size is for that file. For an optimally compressed file, if the system is reading the entire file, the read size will more or less equal the file size.
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)
The cycle of security is this:<p>1. Security experts see a security hole and note that it could only be used by a widely trusted company or government.<p>2. People note that it's also possible that it's <i>not</i> happening, and claim that the widely trusted company or government would never use the security hole.<p>3. It is discovered that the widely trusted company or government has been using the security hole.
Read their TOS and compare it to Google Drive's TOS.<p>The insane rights the Google TOS grants to Google are why it costs ~ 1/2 as much.<p>It is also an indicator that Dropbox is less shady. They don't grant themselves rights to do anything with your data outside of the normal things you need them to do to offer the dropbox service for your use.<p>Unlike Google, which could for instance, use your personal photos of your kid eating ice cream to try to sell you ice cream via road side LED billboards.
"
1 - Create a large-ish file (1MB) outside of the Dropbox folder<p>2 - Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file<p>"<p>I can not really say if Dropbox steals them or not. But if i were a Dropbox engineer and want to know about those newly created files, i wouldn't want to send the whole file to server at all.<p>- Send file name with its extension<p>- Send file size<p>Compare these to dropbox's blacklist file (imagination only) in another server. If there are any matches, mark user as "whateveryouwant"<p>As long as there is a network activity when a new file created, it is and will always be suspicious to its users.
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.<p>My only lament is that it doesn't work that well over the intermittent connections. It'd be neat to have something robust like mosh (<a href="https://mosh.mit.edu" rel="nofollow">https://mosh.mit.edu</a>) for file sync.
The original article is titled "Dropbox Is Probably Not Stealing All Your Files". From bandwidth consumption, you can tell it's not stealing all of them. Whether it does so selectively, on command from the mothership, is another matter.
"The Dropbox application uses a filesystem monitor to detect when changes are made by monitoring filesystem write events. This is, by necessity, a system-wide process. So DLP alerting that Dropbox is “acccessing” a new file shouldn’t be surprising."<p>I think this SHOULD be surprising to any competent software engineers. That isn't how the file system watcher works.
About every form of backup software will use change journals to identify what to backup and how it changed.<p>Change journals are streams that are per volume (so to monitor some directory in C:\ i have to monitor the C:\ change stream).<p>It's just how NTFS works. It's shocking that this was allowed to reach this kind of publicity because it's just a guy attaching a diagnostic tool to a system where he doesn't know whats happening and then proceeds to freak.<p>Software like this will have plenty of file access for metadata, not only on the backed up files.
This article makes me irrationally annoyed by how lazy the author was. I was able to produce a test in under 5 minutes that disproves the article's core assumption:<p>> The Dropbox application uses a filesystem monitor to detect when changes are made by monitoring filesystem write events. This is, by necessity, a system-wide process. So DLP alerting that Dropbox is “acccessing” a new file shouldn’t be surprising.<p>THAT IS NOT HOW THAT WORKS!<p>Sorry, I am calm now. As someone who has spent quite a lot of time using Windows' File System Watcher functionality, I know that that is nonsense. Windows monitoring/watching is conducted at the kernel, when an IO operation occurs that hits a registered monitor it fires off an event (windows message) to that process to let it know, the process itself never accesses that file directly.<p>But just test it for yourself.<p>1) Download Process Monitor [0]<p>2) Start Process Monitor, turn off Registry, Network, Profiling, and Process events.<p>3) Set the include (included processes to monitor) to [whatever executable you build]<p>4) Build this (see examples section) [1] in C#/VB.net and run it<p>5) Set the process name in #4 in the include in #3<p>6) Write to a file in C:\ (that's the default in the example program/source)<p>7) You should see some Console.WriteLine() output indicating the file watcher is working. If not run as administrator.<p>8) There you go. As you can see, no direct file accesses to the file. The monitor events are fired as you can see, but the file remains untouched directly by your program.<p>The author could have done this. Why didn't they? It isn't like I had to even write one line of code or have some kind of specialist knowledge of low level kernel functionality...<p>PS - I don't know/care if DropBox is stealing your stuff. I just wish the article's author had at least fact-checked before they claimed that "that is how this works!!!" when in reality that is untrue. That is how it works for Anti-Virus because AV scans within files to see contents, it isn't how it works for most processes which just use the file watcher functionality. If DropBox chooses to look inside files, then why? There is no need for that.<p>PPS - If DropBox do have a system wide file watcher, that is just lazy. It will reduce system performance, and they could have just as easily set it up to point just to folders DropBox is configured to watch.<p>[0] <a href="https://technet.microsoft.com/en-us/sysinternals/bb896645" rel="nofollow">https://technet.microsoft.com/en-us/sysinternals/bb896645</a><p>[1] <a href="https://msdn.microsoft.com/en-us/library/system.io.filesystemeventhandler%28v=vs.110%29.aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/system.io.filesyste...</a>
It's very unlikely that dropbox would upload every changed file from your computer, that would not go unnoticed.<p>A desirable capability would be on-demand upload or download of any file on the clients system. For that you would need the entire filetree+checksums so, imo, that's what it's syncing.
Dropbox has too much to lose and not enough to gain by stealing your files. The accusation borders on paranoia. That said, Dropbox is a closed system, and I always trust open systems more.
The tin foil hat is strong with this thread. People should read up on Windows Explorer shell extensions before making comments. It's like saying regexing email addresses to check for valid input is the same as stealing emails addresses.
If dropbox get to send metadata about files outside of the folder could be damning enough.<p>Hey you have in your downloads folder 3 new files per day whose file names hints they were send by FB user X. I could make an educated guess about their content.
Reminder that Dropbox was mentioned, by name, in NSA documents released <i>two years ago</i> as the next target they intended to subvert. Also reminder that not long after <i>that</i> they named Condoleeza Rice, celebrated apologist for warrantless wiretapping during the Bush administration, to their board of directors.<p>Yes, it's <i>possible</i> they named her to their board in good faith, and it's <i>possible</i> they also resisted the NSA somehow, where Google and Microsoft and Yahoo and countless others failed. But, do you consider it likely enough to bet your privacy on it? It seems to me you would be foolish to do so.<p>The only other excuse for it I can think of is that it's <i>so obviously corrupt</i> that it proves they aren't corrupt after all - that no one could be that stupid. I reject such meta-reasoning. They are simply corrupt.
If you are an ordinary guy then even if Dropbox steals a file it won't matter much. If you are a government, Airbus, Snowden, Aselsan, or Comodo you should not install Dropbox even if you trust Dropbox.
Pure speculation follows.<p>I wonder if they could be calculating hashes of files and sending them off? That would be useful for automated exfiltration and targeting.<p>For example:<p><pre><code> 1. Calculate the SHA-256 hashes for files in places of interest.
2. Report the hashes upstream.
3. Hey, this file matches one that the FBI/NSA is looking for via NSL.
4. Download more stuff. Also identify the person and their location.
5. Send agents/drones after them.
</code></pre>
This is unlikely, but still in the realm of possibility. It's also untestable without more information. (Packet captures from the DLP device would be far more helpful in determining if anything of the sort is happening.)
Speaking of which, does anyone run apps like this with a different user than their own?<p>I'm thinking of something like<p><pre><code> /home/dropbox drwxrwx--- dropbox <youruser></code></pre>
Surely tradition requires that the title of this piece be "Is Dropbox stealing your files?".
I mean, it's a complete waste of a Betteridge event.
You upload your files to dropbox servers, how in the world can you come to the delusion that you would notice when they accessed/searched/data mined your files?!