Hacker News new | past | comments | ask | show | jobs | submit login

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.

[1] https://www.rohitab.com/apimonitor

[2] https://pbs.twimg.com/media/B_Kv4i3U8AEZLLt.png:large

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact