The Dropbox shell extension that’s most likely triggering these events as described in @razvanh’s Medium explanation. the application routinely communicates with its sync infrastructure at Dropbox and AWS (AWS CloudFormation) endpoints. By this logic the provided evidence doesn’t show that the application is reading or transmitting any files outside your Dropbox folder; but it doesn’t disprove it either. Is it possible to test this hypothesis, yes. Dropbox only sent a few hundred KB after “accessing” the target file. Similar to communications patterns when Dropbox is doing routine server checks. According to this evidence Dropbox only sent a few hundred KB after “accessing” the target file. The same patterns when Dropbox is doing routine server checks. If Dropbox is scanning any files, it should read a larger number of bytes than the kilobyte range which makes it probable Dropbox isn’t scanning these files beyond a call to stat() as part of its file monitoring service. Bottom line: Evidence is weak that Dropbox is stealing your data, they do have a set up through monitoring changes on your system. But that is to be expected with applications of this nature that sync data. A better question is could they. Short answer, yes, any third-party application that utilized OS level monitoring tools can. Long answer no, but not for technical reasons. The few kilobytes that are monitored are enough for detecting changes in the files current state, this would increase if data was being funneled or transmitted to a third party server.
