Dropbox if you must
January 3, 2015 — May 20, 2023
I’m not a fan of Dropbox as a file sync option, but sometimes you need to use it to communicate with a colleague. I talk about Dropbox here, but also GDrive and OneDrive fit in here, as things that we sometimes need to work with but which I fundamentally do not trust.
1 Use rclone to get Dropbox data on demand
The upshot of rclone is that I can pull changes from Dropbox into my git repository like this:
and push changes into Dropbox from the git repo like so:
My colleagues need never know that I am using modern version control, change-tracking, merging, diffing and so on.
In practice, to exclude a lot of files at once, I recycle a standard exclude list from syncthing and replace --exclude=".git/" with --exclude-from=".stignore" in those commands. And to make sure I am not accidentally syncing git repo stuff I use the --dry-run option to verify that the expected files are getting copied/deleted/whatever.
2 Maestral the open-source Dropbox client
Maestral is an open-source Dropbox client written in Python. The project’s main goal is to provide a client for platforms and file systems that are no longer directly supported by Dropbox. This was motivated by Dropbox temporarily dropping support for many Linux file systems but extends to systems that no longer meet Dropbox’s minimum requirement of glibc >= 2.19, such as CentOS 6 and 7. Limitations
Currently, Maestral does not support Dropbox Paper, the management of Dropbox teams and the management of shared folder settings. If you need any of this functionality, please use the Dropbox website or the official client.
Maestral uses the public Dropbox API which, unlike the official client, does not support transferring only those parts of a file which changed (“binary diff”). Maestral may therefore use more bandwidth than the official client. However, it will avoid uploading
3 Host-proof sync with encryption
There are tools to turn even my awful unencrypted untrustworthy system into an encrypted one. Cryptomator is one cuddly friendly option. So is the more austere rclone, as mentioned earlier. These encrypt everything inside a certain sync, in particular stopping your snooping corporate sync provider from reading it. Even a crappy spying provider such as Google, Microsoft or Dropbox can be made safer. Both those options are free and simple.
The drawbacks that immediately occur to me are
- this does not help with sharing files with peers, who still need to decrypt stuff somehow (although that’s a challenge for any encrypted service)
- you still have to run the provider’s sync software on your computer, which means trusting their client code if not their server code.
- files are encrypted individually so you are still leaking some information about what kind of files they are in their size and usage patterns.
- There are several solutions to do this, but they use AFAICT incompatible encryption, so I can’t benefit from sharing files across many apps securely
NB I could do this anyway by manually encrypting everything, but would I? No, because it’s slow and tedious. I want a nice GUI so that this option is easy and lazy.
If you don’t mind whether the files are local or not, you could use rclone’s encryption mode, which talks directly to the remote file store and also encrypts the content. Rclone can do everything.
4 Run Dropbox proper on a spare computer and then sync using syncthing
This works pretty well. I was running Dropbox and syncthing on a spare computer I had lying around campus to automatically synchronise the Dropbox stuff I need. One minus was that occasionally I got logged out of that machine when I was away, causing syncing to break. These days I use rclone to communicate with Dropboxers, which is both cheaper and more reliable.
5 Use a FUSE virtual mount
dbxfs or ff3d or rclone (above) allow you to mount the remote Dropbox file system without installing Dropbox’s suspect client software. This seems slow and clunky; I think I would only do this if I needed to coordinate on some Dropbox thing in realtime but mistrusted the client. This sounds like hell to me. Can I not just use git and handle coordination in my own sweet time? For my offline collaboration style, manual-and-asynchronous syncing with rclone is better.
6 Run a sandbox
If I must use Dropbox, I could perhaps sandbox it. Dropbox itself doesn’t seem to ship any of the sandbox systems natively, (aside: Why not? Does some part of their business model depend on intrusive access to everything I do?). I did try a containerized version using docker. However in practice for me it was fragile and RAM-heavy, difficult to debug and overall not recommended. Possibly other sandboxes would be better? But meh.