If taken at face value, this implies that Dropbox is spending their own bandwidth and storage space for data that's potentially much bigger than your actual shared folder, without charging you for it.
What's actually going on here? What sort of false positives might we expect from such a program?
The article draws a pretty solid argument, if you wanted to confirm results yourself I'd suggest creating a windows vm, installing dropbox, and getting a packet capture of the traffic leaving when you drop a .docx file in the C:// directory.
It's not a stretch of the imagination that dropbox could still be making a profit spending bandwidth and storage space this way. I can think of a government agency or two that would re-imburse the costs.
You say solid, but I don't see any proof that the client actually send the file. Without something like a strace analysis, you can't really know for sure if the file was even read completely and sent to the Dropbox servers
I really, really doubt that the client actually sends the file. But, imagine if they read only metadata and uploaded that.
I agree with what another commented brought up - it's probably just unfortunately overaggressive 'filesystem-watch' code - IE when you change a file it checks to see if it needs to be synced and re-uploaded. It shouldn't be able to affect other files, though. Makes me wish we had more nuanced security controls, like per-app permissions a la Android/IOS.
What's actually going on here? What sort of false positives might we expect from such a program?