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 like this, we'll all know soon enough.
I couldn't be fussed to reverse it again, so instead used Rohitab Batra's excellent API Monitor [1] to figure out what's really going on.
Firstly to address files being accessed outside of Dropbox - this is true, but literally all it does is read the file attributes: https://i.imgur.com/TADvHp1.png. Moving up the call stack and disassembling the calling function, we can see that it's part of the Python runtime: https://i.imgur.com/1TBong4.png (presumably python27_lockdown.dll is Dropbox's custom hardened copy). A bit later on it does a comparison to ".bat", which identifies it as the function win32_stat() in Modules/posixmodule.c - the ensuing behaviour of this function corresponds to QueryBasicInformation as shown on the original author's Process Monitor dump. Why the Dropbox client calls stat() on files outside of the Dropbox folder (but on the same drive) is not clear, but, as the article above also mentions, that is all it does, so no problem there.
Secondly, the original author also posted evidence of Dropbox accessing various shell folders [2] - Desktop, Documents, Music, Pictures, and so on. This is true but again it's a side effect of an innocent function call, this time SHGetFolderPathW(): https://i.imgur.com/uXN31BI.png. It's actually SHELL32.DLL that is responsible for opening the folder and querying its attributes, not the Dropbox client: https://i.imgur.com/YCyTwNe.png.
Without reversing the entire program we can't say for sure that Dropbox isn't siphoning out data in some other sneakier way, but the accusations of data theft from these file events are simply not true.
What happens here is that Windows Explorer asks Dropbox whether it should display a green or blue icon for a file. It does this for all files, including those outside of the Dropbox folder.
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.
So what you're saying is that, if I wanted to launch a nefarious file-stealing Dropbox-like application, I should first launch the non-nefarious version, and then when it gets up to 3.6 or so, turn evil?
Even without having to go open IDA, I'm sure windows has enough system monitoring tools that you should be able to tell what Dropbox actually reads outside of its own data, if anything.
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.
Thought they just used icon overlays, much like all other status-icon shell extensions such as version control (TortoiseSVN). Not exactly some low level windows hack, it's a plugin system in Explorer. I probably have five or six such icon overlay extensions on my machine.
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.