> Finally, we describe the design and implementation of an open-source version of Dropbox client (and yes, it runs on ARM too).

I wonder how long that implementation will continue to work. The official Dropbox client auto-updates (well, the Windows one does; Linux doesn't, afaik), so Dropbox can almost change the protocol whenever they like.

This part of the talk is probably the part I have the least interest in, honestly.

It would be cool, yes, to act like a first-party Dropbox client and have full access to my account via open tools.

But in the meantime, they do have a python API and SDK:

https://www.dropbox.com/developers/core/sdks/python

This lets me setup a sub-folder under my account with no more than python present on a machine and perform upload / downloads of content. Nothing processor architecture-specific about it. And with python modules like https://pypi.python.org/pypi/watchdog it's pretty trivial to trigger a re-upload of local content when it changes. The API provides counterparts for detecting changes in remote content (the /delta command).

In fact, this is how I've got Dropbox access running on my gen1 AppleTV :)

I'm more generally interested in the process of reversing of the code and protocols.

Building your own is great, but all I really want is a small package that I can drop on my ARM NAS that will keep a copy of my Dropbox data. Dropbox themselves have been dragging their feet on this for some unexplained reason.

> drop on my ARM NAS that will keep a copy of my Dropbox data

Do you also have Dropbox installed on a desktop at your place?

Maybe you could co-monitor your desktop Dropbox folder using this: http://sparkleshare.org/

It appears to be a Mono/.NET based project, but apparently there's Mono for ARM.

There's probably other options as well - just a thought :)

When did Windows Dropbox start auto-updating? I've never seen it update; one of my machines had a client from like 3 years ago and another machine had a client from a year and a half ago.

It's been that way as long as I can remember, though I could be misremembering. It's mentioned in the Dropbox help [1].

[1] https://www.dropbox.com/help/13/en

That's the point.

Time to lift the veil on Dropbox. Maybe it's just librsync, Amazon S3 commands, and some Python duct tape. Built from open source? Maybe the biggest coding challenge for the founder was getting their icon to display well on Apple OSX? Could it be true? Nah. Pay no mind.

Looking forward to this paper. Will Dropbox try to censor the authors? DMCA?

Should there be an open source client to do what Dropbox does and should we all be paying for AWS S3 instead of paying Dropbox? Never. Perish the thought.

I would be surprised by Guido Van Rossum left Google to work on "some Python duct tape" at Dropbox ; ).

I wouldn't. Maybe they offered him a better deal. I'd be surprised if he evaluated the job opportunity by reviewing the Python script they used to launch the service.

Having worked there, I can say with 100% confidence that you underestimate the problem space.

Why such negativity?

Who defines the "problem space"? Dropbox, or computer users? I would never claim to have 100% confidence in my ability to speak for users, but I think you underestimate the readiness users might have for other solutions to online storage (that might define the "problem space" differently).

I'm very positive about this upcoming paper and I'm enthusiastic about open source alternatives to Dropbox. Not sure what you mean about negativity. Why so defensive? Is Dropbox like Microsoft or something? Are we prohibited by some clause in an EULA from criticizing the company or comparing its software with competitors?

Seems like BitTorrent Sync would be a likely alternative.

http://labs.bittorrent.com/experiments/sync.html