Dropbox if you must {#dropbox}

or gdrive, onedrive etc

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.

Use rclone to get dropbox data on demand

The upshot of rclone is that I can pull changes from dropbox into my git repository thusly

rclone sync --exclude=".git/" --update dropbox:ProjectForGitHaters/ ./ProjectForGitHaters/

and push changes into dropbox from the git repo like so

rclone sync --exclude=".git/" --update ./ProjectForGitHaters/ dropbox:ProjectForGitHaters/

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.

host-proof your sync with encryption

There are tools to turn even your awful unencrypted untrustworthy system into an encrypted ones. 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 are 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.

Run dropbox proper on a spare computer and then sync using syncthing

This works pretty good. I was running dropbox and syncthing on a spare computer I had lying around campus to synchronise the stuff off dropbox I need automatically. One minus was that occasionally I get logged out of that machine when I am away, causing syncing to break. These days I use rclone tom communicate with dropboxers.

Use a FUSE virtual mount

dbxfs or ff3d or rclone (above) allow you mount the remote dropbox file system without installing Dropbox’s suspect client software. This seems slow and clunky; I think you would only do this if you 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 syncing with rclone is better.

Run a sandbox

If I must use Dropbox, I could perhaps sandbox it so at least I don’t need to run their stupid software on a real machine that I actually use. Dropbox itself doesn’t seem to ship any of the sandbox systems natively, (aside: why not? Does some part of their business model depends on intrusive access to everything you do?). I did try to a containerized, 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.

No comments yet. Why not leave one?

GitHub-flavored Markdown & a sane subset of HTML is supported.