September 16, 2010
Two-Way Mobile Clients & You
I’ve been taking a bunch of requests for two-way functionality from our mobile clients, and I would like to address that. Let me start by saying that I *fully* understand how much of a killer feature that would be for all of us. I use SpiderOak for my own personal file storage, sync, and share, as well as using it for work (Android beta testers know I use a ShareRoom to distribute the beta builds, for example). I use my SpiderOak iPhone app several times a day. For mobile users, your pain is my pain as well.
That said, traditional two-way interaction with SpiderOak would be nontrivial for a mobile phone. Our zero-knowledge system takes full advantage of the power available in modern computer systems to run the encryption/decryption and file de-dupe locally before uploading to our servers- see our engineering description page for more details on that. I think most of the latest generation of smartphones (1 GHz Android, A4-powered iOS, generally) are finally powerful enough to even think about doing this. That said, there are still a few obstacles to overcome:
- Most of our application code is written in Python. Either this can be ported to both ObjC and Java, or I can figure out how to tie in some sort of framework to connect it across from Python. Either way, it won’t be pretty or quick.
- Battery life is generally the biggest concern I have, once the above could be done. SpiderOak would be sucking down the device’s battery, as well as sucking down data usage (important for those of us on metered data plans). Running the CPU as hard as we can certainly do will run down the battery just as hard. CPU and memory usage of our desktop client is one of the most common complaints about our service, and moving that to a phone is only going to exaggerate this.
I have ideas ideas we’re working on to incorporate our very cool DIY storage system into our mobile platforms to offer secured backup to our storage. This would take advantage of built-in cryptography on the phone, and use a shared key between the desktop application and the phone to encrypt data and then upload that to our servers. That can then be tied in desktop clients to offer zero-knowledge backup from mobile widgets. I can’t guarantee this is going to happen overnight, but it’s where I want to take us until the ARM Cortex A15 gives us the power to do this efficiently.
By using our HTTP-based DIY system, we can bypass the most CPU and memory-intensive portions of SpiderOak interactions, and as I don’t anticipate typical mobile load being that much, it shouldn’t overwhelm the desktop client to ask for just a little bit more help.