In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action. That means it would have to read the file information and compare it against the filters that have been defined.
These actions will show up as at least 4 or 5 entries in Process Monitor (and maybe more, I'm not sure off the top of my head). This also means that applications monitoring for file access will catch each time this happens.
Unfortunately, whoever wrote that article does not seem to understand Window's internals, or how to determine what consists of bad or dangerous activity.
It should also be noted that Dropbox runs in the context of your own user account. It does not run as a service or elevated user, so it will only have access to the files you have access to (and that you have access to without requiring elevation).
I'm not going to claim to be a security expert, but I don't see anything that would suggest a security risk on Dropbox's part. Further, if a company has data important enough that they need to run DLP software on individual computers, they should not be allowing software such as Dropbox anyway.
That's a .Net contraption over one of two Win32 APIs that provide file system monitoring services. Neither of these requires opening files in response to file system notifications. That's 100%, guaranteed.
Correct me if I wrong but Dropbox is not written in .Net, so what you said is irrelevant.
I'm not sure if Dropbox is managed code or not. FileSystemWatcher does implement ReadDirectoryChangesW, which would allow them to set specific directories to watch. They may be using change journals instead, though, which function differently.
Either way, I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
Change journals are read from the volume directly and there's no evidence in the ProcMon logs (posted elsewhere here) that Dropbox uses them.
> I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
Bzzt, nope. Wrong again. You should really try and not comment on things that you are not well-versed at. This part in particular - "as would be done to check whether or not a filter applies" - makes no sense. Dropbox has the file path readily available from the notification itself [1], and that's the only thing they need to look at to determine if the file is in their managed directory or not.
Dropbox is always connected and continually checks for updates, just because one sees at the same time doesn't mean they are related. I see Dropbox connections all the time whenever I look through my network.
I am on mac, I have littlesnitch and I also have Geektool display network connections. Dropbox is not always "active". I don't see any kind of network traffic after syncing has been done under macosx.
Periodically yes, but open TCP connections can technically last for days (although this is implementation-specific) without any packets being sent across.
You're right of course, periodic data needs to be sent even if just to keep the TCP connection open, but it's not much and it's not often.
I don't think this is related to FileSystemWatcher (or ReadDirectoryChangesW) at all. I believe the author is just confused by the shell extension. Every time you right click a file in explorer, this type of "file access" would happen.
Doesn't tallavor address this in the first sentence?
> In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action.
Sounds like the very act of checking whether the file falls within the "agreed location" is what caught the author's attention. I can't say whether that's true, but it doesn't seem unreasonable.
It depends on the method they're using to monitor for changes to files and the type of filter being used. They're probably trying to reuse code across clients, so I'm not sure what method they're using. --ReadDirectoryChangesW makes the most sense, but maybe they've done it differently. If someone really wants to figure it out, it's probably possible to attach a debugger to try and catch the calls being used, but since we don't have symbols, it wouldn't be the easiest exercise (although it might be fun if I could find the time).
Well, it's not 'scanning files'. It's scanning meta-data about directories and files.
You can see three calls for each file in the ProcMon logs:
1. CreateFile
2. QueryBasicInformationFile
3. CloseFile
Let's go through these in order:
1. Opens a handle to the file, allowing the application to query meta information, read, and write
2. Queries meta information about the file.
3. Closes the handle to the file before doing anything else, including reading data.
There's no scanning of files, because no data is read. Its common for applications to traverse directories like this, and the behavior could even be a consequence of a file system library or API that dropbox is using. If you think of your file system as a filing cabinet, what DropBox is doing might be equivalent to opening every drawer looking for a single file.
ProcMon detects CreateFile and QueryInformationFile using these function codes:
As you can see, neither of these indicates a file being read. It also monitors a number of other codes (I'm not sure how specifically it detects CloseFile), including this one, which is triggered when data is read from a file:
This article does not prove "steals everything" claim. Very shallow work for "Information Security Specialist".
The reason Dropbox accesses files all over the drive may be that FS events driver generates events for every file accessed by every program, and Dropbox has to read their metadata for some reason (e.g. to check if their full path is under one of synced folders). He should elaborate by checking if Dropbox is actually scanning and reading all drives, which is hardly unnoticeable, or is it something else.
Having network activity at the same time does not mean this file has been transferred. It is incredibly hard for me to believe that Dropbox has sneakily transferred >1TB from my various computers without me and my ISP noticing. The author should monitor Dropbox traffic volumes over a week and check if it actually exceeds synced folders size before spreading panic.
Or maybe not. Your speculation is as good as mine. Or the op. Or everyone else. The point was Dropbox is accessing files outside the folder, something I would not want or expect.
"It is incredibly hard for me to believe that Dropbox has sneakily transferred >1TB"
Did they transfer hashes? name+type+size for fingerprinting? Searching for credit numbers or SSNs? Who knows. I don't. And don't do evil is no longer the basic assumption.
I would be very interested in seeing if Dropbox does the same thing the author claims, but on non-Windows OSes. There are official Dropbox packages for OS X, Debian-based Linux distros, Fedora/Redhat and derivatives, and a source release for packaging the binary for other OSes. If the same or similar activity is seen on other OSes, something's afoot. If the issue only shows up on Windows, it's likely a Windows-only issue or quirk (but could still be nefarious and only targeting Windows users, though personally I'm not that paranoid).
Would this really work? I would expect the SSL certificate of Dropbox's servers to be hardcoded in the client, so the client would refuse to connect to an interceptor.
The Dropbox client is running with normal user privileges on a computer that you have root access to. It should be possible to use reverse engineering/debugging tools to either bypass SSL checks or analyze the dropbox client binary to see what is being sent/recvd.
Sure, I'm just saying it would be less straightforward than mitmproxy. I wonder if there are tools to hook into whatever SSL library is being used (OpenSSL?) and intercept traffic before it gets encrypted and after it gets decrypted? (probably using LD_PRELOAD, like tsocks)
They could look for bitcoin wallet files, thats what typical malware does nowadays. Could theorethically only takes the infection of one computer to strike it rich.
That would be a solid line of thought if this would be some shady adware from some unknown company. But Dropbox is valued more than $10B, that's more than twice the market cap of all Bitcoin. Even if everyone at Dropbox went criminally insane, there would be no way for them to recover even a reasonable fraction of it in BTC markets. Not to mention it would completely kill their reputation and thus the highly-valued business.
Lenovo is a $16B company, and we learned they're breaking SSL and man-in-the-middle attacking all their customers. I think we should be careful in not assuming "big, rich company" means "sensible, responsible company"
Also, theoretically, it could be a single (or a few) developers going rogue, rather than an approved company policy. It wouldn't be the first time.[0]
Collecting "metadata" such as Address X stored on Computer Y on ip address Z could be worth quite alot to likes of NSA who I am sure have plenty of incentive to monitor crypto-currencies and would either pay Dropbox to do it or alternatively bang them over the head with a hammer and make them their bitches in order to collect all sorts of juicy "metadata" on millions of people world wide.
Hell access to so much information could make for quite a political tool, remember that general in washington who was kicked out because he was having an affair and somehow his private communications via gmail drafts became public. What would prevent an opportunistic dictator from gaining absolute control over political landscape of a country if this dictator has access/control to an organization such as NSA?
Americans get up in arms over their right to be armed all the time, but they ignore (or do not realize?) that without privacy and secure communications they would never be able to organize a resistance to a totalitarian government which is better armed and could potentially (already does?) monitor everything and everyone on a scale that would make Orwell blush and spin in his grave.
all of bitcoins, including every lost bitcoin, have a market cap of $3.8 billion combined, a valuation set based on worldwide trading volume of only $40m over 24h.
Dropbox has already closed hundreds of millions of venture capital money at a valuation of $10 billion. I think it's safe to say Dropbox has found some wallets that are much easier to open than bitcoin wallet files. :)
He has a tool that checks for accesses on specific kinds of files and he uses that and a few specially crafted files to see what happens. That tool might even influence other processes for all we know.
How does a security researcher not know about procmon? another user here did a test and found no problems.
This article does not prove "steals everything" claim. Very shallow work for "Information Security Specialist".
He has shown - and others here in the comments have verified (https://news.ycombinator.com/item?id=9136740
) - the file access. It's not a "read contents" though, but only reading metadata.
He has shown there is network activity.
He has NOT shown what exactly that network activity consists of. Without that, the "steals everything" claim is just jumping to conclusions.
As others here have mentioned, setup a proxy and look at the actual data being transferred. Replace the certificate in the client if you have to, to get around cert pinning. The most important part is to get the data. This should be pretty easy to do for someone who claims to have those qualifications.
Shallow work indeed. This reminds me of the Samsung keylogger story a few years ago where a "security professional" ran one AV software, which falsely identified the presence of a single folder's path as a keylogger, and then based on this one data point and blind faith in his AV, claimed there was a keylogger preinstalled on some Samsung laptops. This made the news and was spread widely... yet he had not even taken the most basic step of looking at the contents of that folder, which would've instantly disproved the theory.
This is an example of the right way to investigate and substiantiate your claims:
Sadly, we'll probably see a round of "Dropbox steals your data!" going through the media before someone steps up with the truth. I personally don't use Dropbox and don't have the time to verify these claims --- but the onus should be on the one making them in the first place.
I just had a quick look at dropbox with ProcMon, and I learned that
1) when I created a new text file on my desktop, it was not read by Dropbox
2) when I created a new text file in my dropbox folder, it was immideately read by Dropbox
3) I have to find some sync tool that doesn't feel the need to enumerate my network interfaces 3 times every second, when nothing is actually changing.
Just some more information:
Dropbox does not read the file outside the dropbox folder.
It does, however, 'QueryBasicFileInformation' and and 'QueryDirectory' when I create a file on my desktop.
I'm guessing this has to do with the explorer extension.
This is the first comment in this discussion I've seen that is actually interesting and might provide an explanation.
The Dropbox file status symbols are a -big hack-. Up until OS X 10.10, for instance, the file browsing interface didn't provide per-file badging at the OS API level. So they literally had to patch the running Finder process to do this.
I wouldn't be surprised to learn something similar is going on with Windows Explorer.
I know my company has had many problems that were pinned down to Dropbox hooking some Win32 API functions that we use. I am not familiar with the semantics of hooking, but could it be related to that?
Have you heard/tried Bittorrent sync? It's P2P, doesn't put your files on their server. Very fast for transferring locally between your phone and computer for example. You have to keep your computer running if you want your files accesible anytime though.
Unfortunately btsync is very much not open-source. There are alternatives, though. I am very satisfied with syncthing[1], although it didn't have usable mobile app last time I checked.
And requires port forwarding, which may not be an option for people who are not on IPv4 at home (e.g. my ISP uses DS-Lite, so I cannot use IPv4 port forwarding).
Bittorrent Sync works pretty good. Somebody should reverse engineer the protocol and make an open source client.
Edit: why the heck is the grandparent downvoted? He/she offers a good suggestion.
Independently of whether DB reads/uploads all the files or not, I've arrived at a difficult position about Dropbox: I'm looking for alternatives. No, it's unrelated with politics or pricing; it's just that in many cases Dropbox sucks.
Why? Well, I mostly don't care about all the new features (mobile, Carousel, etc.). What I care the most is that i) it syncs files and ii) acts as a quasi-backup. However, I see the same old bugs from years ago and nothing gets done. To name just a few:
- If I copy a file to the Dropbox folder in Windows, it will convert it to small caps, even if the file is in Camel Case. Yes, I get that for windows caps are just "optional", but do not change it just for the sake of it!
- Many people sometimes have temporary files. Photoshop, Matlab, Word, Latex, etc. leave crumbles of temp files and folders. Can't I just set a quick rule to avoid "tmp" folders and e.g. ".tmp" files?
- A few months ago their forums went down and stayed down for around a month? Why? Technical problems. But the real reason is that they don't really care.
There is no way DB can justify their valuation with just the syncing part, and I'm fine with that. But just stopping altogether to improve in that area is a huge turn-off, and on top of that they do not care to fix bugs (there were hundreds of bug requests about the lowercase bug in the forums, before they deleted it).
Now that my rant is over, I ask you: are there any useful alternatives? I've heard that GDrive is very slow and the MSFT alternative seems a bit risky to me (will it work on Linux in the future? will it be customizable?).
I use spideroak. It has been very reliable and fast, but you have to actually want its main feature, which is secure (client encrypted) versioned backup. Keeping versions saves you from data loss by overwriting but it also needs more storage space. However, spideroak does it in a pretty smart way. I am surprised how little space it actually needs.
Unison was the first thing I tried after moving away from DropBox. The main problem I had with it was that both machines involved in the syncing had to be running which made moving from laptop to desktop not as seamless as I would have liked. Still the syncing process was flawless. I had better results using Seafile, http://seafile.com/en/home/, their free account was sufficient for my needs and worked great. You can self-host if you are worried about keeping control of your files.
You'll have that problem with anything you don't run yourself so that seems like an unfair complaint. Can't this sync desktop <-> server and laptop <> server?
In Seafile the server doesn't notify changes to clients, instead the clients poll every 30 seconds, which means that changes are synced with a 30 second delay (and presumably bandwidth is wasted). See https://github.com/haiwen/seafile/issues/992. I'm not a fan of Dropbox but at least the lag is only a few seconds, which I think is because the clients notice changes with inotify and send them to the server, and the server probably pushes updates to the clients.
I haven't tried to use it seriously, but seeing that it doesn't do this right discourages me a bit from testing it further.
I'm using ownCloud[0] in version 7 and 8. In the early version ownCloud was a bit hard to configure and run on your own. But the new versions are really good (in my opinion). For me it's very reliable.
I once wrote a plugin for OwnCloud for work. But before running OwnCloud on a server I would first like to see an audit and/or analysis of the code. I read some code of IIRC version 5 or 6, which made me skeptical.
SpiderOak. When I decided I wanted auto-syncing cloud storage, I chose them exactly because of the temp file issue. I ended up also liking their security policies and pricing quite a bit. https://spideroak.com/
QueryBasicInformation is like a subset of stat(2). It can't access a file's contents. While I'd prefer Dropbox not to go looking at file metadata on my whole device, I'd chalk this one up to over-eager coding and not some kind of data-smuggling backdoor.
I don't see any evidence that Dropbox actually transfers files, and I'd be very surprised if that would actually happen.
But if the information is correct, it does transfer some kind of information to the Dropbox servers directly after accessing files outside the sync folder. I would have liked an examination of the tranferred data, or at least a comparison of the amount of data transferred compared to the size of the accessed file.
There are different levels of information, with the last being the actual file contents. I doubt dropbox would sync file contents from unrelated files (that would be the biggest security scandal ever), but there are multiple levels of metadata that you may or may not expect Dropbox to upload. If something is uploaded after you create a file in a separate directory, I'm guessing it's one of two things
1) metadata such as a timestamp when all files in the synced folder were found up to date.
2) metadata about the non-synced file changes, such as timestamps, checksums or etc.
While 2 isn't an upload of the file contents, it's still bad enough. I wouldn't expect Dropbox to upload any data OR metadata related to my unsynced files at all.
This is probably an unfortunate combination of a broad watch for file changes, code that opens changed files to determine whether to proceed (hacks for hardlinks/junction points? collecting more information before bubbling the event up to higher layers?), and built-in analytics.
I'd be shocked if it's actually uploading a comparably sized payload.
No, Dropbox is not stealing your stuff. Apparently people have never heard of Windows Shell Extensions, the approved non-hacky way to overlay icons over files.
Dropbox's call to inotify_add_watch [1] is properly scoped so this is either a platform problem (but it looks like Windows' analogous API [3] allows only one directory to be monitored), sloppy development on Windows, or something else. I ran Dropbox under a Docker container under strace and grepped strace's logs for inotify and got this [2]. At least on Linux, it's impossible for Dropbox to receive any notifications about new files outside the Dropbox folder.
"Access" is a bit vague. It's one thing if their 'fstat' is leaking, it's another thing if they are actually reading all the bytes of those files.
Another piece of evidence I'd like to see is a mitmproxy checking out what's under that TLS session. Improper local reads are one thing, it's another thing entirely if they are communicating back file names, hashes and/or the file data actual.
My personal theory is it's something to do with Dropbox's Explorer shell extension.
(But I really don't know enough to day for sure. Still, if the shell extension mechanism is such that you get a file or list of files, it'd need to figure out whether they're in a Dropbox folder or not and play with the icons.)
Even if it's just fstat and thus metadata it's a pretty remarkable turn of events. This would mean Dropbox would have access to a list of all the files on my computer, when I've last accessed them or when I've last written to them for example. I don't think this is something dropbox should do.
I agree that it's important to find out if they are phoning this information back home, because if they don't this is still very bad but a lot less harmfull.
I'm not a Dropbox user, but why doesn't anyone with Dropbox just install a local proxy and try to read out the requests made to the Dropbox servers. The speculations on spying, etc. in this thread are completely worthles, just look at what they're sending to the servers.
FYI - they do certificate pinning for their clients and won't let you proxy the HTTPS connections, last I checked.
I'm not saying this as cause for alarm. Obviously if they were sending the files you could measure the volume of traffic if nothing else.
Make a completely random non-compressible file that's of an arbitrarily significant size (say 1M+) and see if that amount of traffic goes out to them.
I do think Dropbox is watching for filesystem events outside of the locations users specify, but I see zero evidence they're uploading information about the files / the files themselves so far.
One can hack Windows HTTPS libs (or OpenSSL, whatever it is) inside Dropbox process and read unencrypted buffers from memory. Standard and well-documented APIs are easy to locate and hook, especially in dynamic libraries.
Synchronizing all your files sounds like space-waste. It would be trivial to determine if dropbox does that, simply by monitoring the number of bytes sent to dropbox (Create a new file of size x, determine if the stream to dropbox transmits at least x amount of bytes) or by replacing the SSL certificate in the program with your own and then set up a fake server (This would be harder) to determine exactly what is being transmitted.
If this is indeed something nefarious, I would much rather assume it would transmit file hashes rather than the files itself. Although I can't possibly imagine this is actually true, the implications would be devastating for dropbox and it should be easy to verify by an independent third party.
What if they upload file hashes? What if they upload name+type+size to fingerprint files? They don't need to upload file contents for fingerprinting your drive content.
Fingerprint popular torrent movie/tv/games etc files and then monitor (via dropbox) their spread and how many computers around the world they end up on, I bet movie studios would love to measure exactly how much piracy affects them
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.
I know that HN is not a help desk, but I have noticed DropboxOriginal eating a lot of my CPU (on OS X), when I am writing files to folders which are NOT under (official) control of Dropbox (or at least: out Dropbox folder, not synchronized). Any ways to block this behavior on OS X?
Security aside, it is really annoying for scripts which modify a lot of files.
Dropbox doesn't access all your files, it just hooks to explorer.exe and then whatever directory you open in explorer Dropbox will query info about that directory, files and subdirectories. To test this, just close every explorer window, run Total Commander and Process Monitor, and use Total Commander to do your stuff, you will see that Dropbox won't be quering directories/files.
And about that connections to dropbox servers, it needs them to sync files if they were uploaded from another computer/smartphone.
Same thing for temporary directories (/private/var/folders), Chrome caches, etc. So, at the very least they seem to monitor the whole filesystem for events.
I didn't really think about it before, but I now feel very uncomfortable that Dropbox has copies of my unencrypted files. I would feel much better if the files were encrypted before being synched. Is there a service that does this?
I don't want Dropbox to be able to see the contents of my file system at their end.
If you don't trust Dropbox you should encrypt your files before copying them to the Dropbox folder because you can't trust the client too. You should encrypt them with a key the client cannot read from fs. Basically you're going to use it as a backup service because you won't be able to work on files in the DB folder. Maybe one of those file systems that work in user space and store only encrypted data will do. Check this http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage...
I'm not sure what your OS is but I do something documented at [0] to encrypt my Dropbox files. The encfs approach also makes it easy to decrypt all of them for use. I'd even say with a little more fine tuning (running encfs on startup, for example), the process could be pretty automated. There's even an Android app that you can use (though it's a little more tedious) to decrypt the files on mobile.
But I wonder why we don't have application isolation as a basic design principle. Imagine an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. Would that work?
So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe?
The idea is not sandboxing, it's "multiverse". Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
> So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe?
You could make the same argument about a vulnerability in the OS itself. There's nothing magic about kernel code that gives it extra protection here. :)
In fact, I'd argue that the most probable attack against Docker would already be via a vulnerability in the OS. Docker uses a lot of kernel-level technologies, like cgroups. Beyond that, the most likely way to escape a Docker sandbox would be by finding a buggy syscall, since these weren't always designed with containers in mind.
> Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
That would be an interesting research project, at the very least. You'd probably have to rewrite much of userspace, since it breaks many of the assumptions the current generation of system tools rely on.
This would completely defeat the point of Dropbox, then; If your Word document is in your Word folder, how does it get to another computer? Do you give the app developer, Microsoft, exclusive right to 'sync' your files elsewhere?
Sandboxing is a good idea. An old idea, actually; chroot was added to unix in 1979. But shared filesystems evolved and are the norm, and even if many apps could be sandboxed, Dropbox exists outside the sandbox for a reason.
> Of course, then we just give all those permissions back to any apps that ask for them.
At least in the case of Android, there is no permission that will give you access to the root filesystem or other apps' sandboxes. Categorically not allowed.
App data is restricted to /data/data/$PACKAGE_NAME. The rest of internal storage is either read-only or completely off-limits (especially in the case of other apps' data). The only way to access data that belongs to other apps is to share the same developer signing key, or explicitly share the data using a content provider.
The only exception is external storage (the SD card, if present). But that's because SD cards use FAT and therefore can't support per-application permissions.
What I meant is the app/service isolation on the OS level. It should not apply just to a subset of apps, but to each and every process that runs on a device.
Because then every application would be an island and useless.
Red Hat Linux tried a variation of this with the SELinux policy that preceded the 'targeted' policy (I forgot its name). Processes that did not have a policy adding permissions would be allowed to virtually read/write nothing.
The net result was that nearly everyone switched off SELinux.
Afterwards, Red Hat worked in the opposite direction. In the so-called 'targeted' policy processes are allowed to do what a normal UNIX process is allowed to do, unless there is a policy defined for them. Since they provide policies for commonly used daemons it adds security, while not making life too hard for sysadmins. Net result: most people keep SELinux enabled and have safer systems.
They might or might not steal your files, but the mere fact that to use their service you have to install proprietary software is a reason not to trust them.
This might be shallow, inaccurate and sensationlist in tone, but it is inherently alarming.
Getting a list of files from the good old /Torrents directory that everyone has, but pretends they dont can be incriminating enough to raise some very serious privacy issues. They can explain this any way they want, but Dropbox certainly has no business accessing any files outside of its config and its sync folders.
As you see below, Dropbox says that "only checked folders will sync to this computer"
Very interesting wording. I don't want to play conspiracy theory, but it only says what will sync to the computer. It doesn't say anything about what will sync (or upload) to the cloud.
That is because that is the ACTUAL purpose of that (Selective Sync) dialogue he is showing, contrary to his implication that it is related to upload configuration. When you have 2 work computers and one personal laptop, perhaps you have a CAD Drawings folder that you would like to sync between your work computers but don't want 100 GB of work stuff on your personal laptop. What the Selective Sync feature allows you to do is untick "CAD Drawings" on your laptop Dropbox settings, so that you don't fill up your disk with stuff you don't want in that machine's context. It's a nice feature.
In a while, this will be disregarded as a bug, might be fixed and maybe Dropbox will even state that they apology and will be deleting all mistakenly uploaded files from their server(s).
But you don't know. The lesson to be learned here is that proprietary software cannot be trusted.
These actions will show up as at least 4 or 5 entries in Process Monitor (and maybe more, I'm not sure off the top of my head). This also means that applications monitoring for file access will catch each time this happens.
Unfortunately, whoever wrote that article does not seem to understand Window's internals, or how to determine what consists of bad or dangerous activity.
It should also be noted that Dropbox runs in the context of your own user account. It does not run as a service or elevated user, so it will only have access to the files you have access to (and that you have access to without requiring elevation).
I'm not going to claim to be a security expert, but I don't see anything that would suggest a security risk on Dropbox's part. Further, if a company has data important enough that they need to run DLP software on individual computers, they should not be allowing software such as Dropbox anyway.