Spideroak after Sugarsync… is disappointing

Around four months ago, I moved from Sugarsync to Spideroak. I’d been using Sugarsync for over a year, and had been a keen advocate for the platform – indeed, I’d referred about 30 people to the service, and it had been my go-to cloud storage as that sector emerged, a few years ago.

However, although I loved the service and the app, one thing that concerned me was the security wasn’t up to my requirements – the fact that data might be encrypted using AWS standard techniques, but would still be accessible to any staff, any US federal agency that served a warrant (or didn’t) to the company, anyone who hacked my password (no 2FA), and anyone who found a vulnerability.

I wanted to store client data in the cloud, and feel some level of confidence that no-one else would be able to read or hack it, and if they did, then I had done everything I could have possibly done to protect it

So – I moved to Spideroak. Spideroak offer a similar service, but only you hold the keys to your data; no-one else can decrypt it. They also offered some convenient secure-sharing options that Sugarsync don’t, like password-protected ‘sharerooms’ where you can share a folder with a third party, and temporary download links you can send to share a file, but which expire after a few days. As a bonus, they offered massively more storage than Sugarsync, competing with Dropbox at the new standard of 1TB for $10/month.

The trouble with Spideroak is… everything else. The service is way clunkier for a number of reasons:

• No mobile upload. With sugarsync, when reading documents or attachments in my email, I could file them away on my disk, there and then, by sending them to sugarsync and choosing the folder. Done! Finished! With Spideroak, the mobile client has no ability to upload! I’m back to flagging and emailing files to myself, to store away later when I’m back at my PC
• Lack of mobile search. You can’t search for a file in the mobile client, unlike Sugarsync filename search, or full google-style search in Dropbox. While this is to be expected – you can’t index server-side when data is encrypted – there are acceptable partial solutions; such as storing a filename index on the mobile device, just to quickly jump to a file by typing its name.
• Lack of mobile caching. If you access a file from your mobile device – and it is quite slow at doing this, sometimes unusably so – you’d expect it to cache recent files so that if you open then a second time, they’re just there, right?  Well – no. You have to download the file all over again, each time. The workaround is to ‘favourite’ the file first, so it’s downloaded and cached locally.
• No collaboration. You can’t sync a folder with a colleague/friend. This is a fundamental capability of Dropbox, Sugarsync, Box, and almost every other service, but Spideroak’s security model seems to prevent this. I have a folder of all household documents shared with my wife’s laptop, and in the end, I simply logged her desktop sync client into my account.
  Yes, there are sharerooms, but they work with you as the master folder owner and others signing in on the web client; there’s no desktop sync
• Slow, unpredictable sync. Spideroak uploads in groups of files that total a certain chunk size, which is interesting; they do explain this on their blog. What is more interesting, are the long periods where I see zero upload bandwidth on my bandwidth monitor, while the Spideroak client seems stuck at nn% of the upload. Why? Why isn’t it uploading?
• Inability to prioritise/cancel uploads. Sit and wait is your only option
• Unable to handle PST files. Outlook PST files are a pain, since they appear to break the Windows Volume Shadow Copy Service model that most backup/cloud storage apps use. Even Crashplan has issues with this. They all backup the whole file each time, even though not a single email has been added to the PST.
  With Spideroak, it means every time it checks for new files, it queues my five PST files totalling 10GB, and starts to upload them all over again from scratch! I get the impression other services do manage to do a diff and upload only the changed blocks – Crashplan ‘uploads’ (or block diff/syncs) in a few minutes, and Sugarsync never complained – but Spideroak tries to upload the entire 10GB each time. I have to remove those from the backup list
• Slow to generate sharing links, unusable for new files. Spideroak has plenty of options to right-click a file and generate a 72-hour unique link to a file. But it’ll take 30-60 seconds to do it… you wait patiently for 20 seconds while the client struggles open (I have a mobile i7 laptop with 16GB RAM), then it tries to create the link, and then…. usually, nothing. Nothing, because for all the reasons above, I have a 30GB upload backlog, and the file I want to share probably isn’t synced. Particularly for new files you’ve just created, they’re added to the upload queue with no prioritisation possible (and will be grouped with other files and slowly uploaded in a batch), so it’s entirely useless for quickly uploading new files. I always end up using Dropbox.
• Mystery downloads. I use Spideroak to sync my main content-creation laptop to a rarely-used convertible laptop and occasional access from my iPad. Nothing is created on these. So why do I see my bandwidth monitoring showing a download at 15Mbps, which TCPView identifies as going to the Spideroak service. What is it downloading? I guess it could be a program update, but I’ve not noticed any updates in the app, and it happens too often for my liking.

In comparison to Sugarsync, Spideroak feels generally more clunky all over – the app, the desktop client, the web service. You can expect much of this given the additional effort of encryption and key management across all this, but there are also many unexpected/uncontrollable behaviours that cause concern.

Sugarsync recently submitted a poll for new features, and client encryption was one of them. I suspect that it won’t make it – although privacy is gaining pace worldwide – and they will be faced with many of the performance/accessibility trade-offs that client encryption present. But if they do implement this, and get it right, I would happily jump back to their service, even for the much smaller storage allowances.