| I really appreciate you taking the time to respond. Thank you. Seems like my memory was reduced to "have to give you the key". I'll be more precise in the future. I used to have my drives encrypted back when TrueCrypt was still a thing. From what I understand I'd lose a bunch of features, like de-duplication or the ability to restore individual files without having to download the entire state of the encrypted container. But maybe my knowledge is outdated... I'd love to read how to set up good local encryption that doesn't conflict with the backup. Only having to trust Backblaze in the moment of restore is better than no encryption. But when that drive died a month ago I certainly wasn't in the state of mind to make optimal decisions. Setting myself up for such a situation doesn't seem that great, though more routine might have helped. Actually, routine would mean sending my key to Backblaze more often as well. I'd entrust you to pretty much "archive" my entire digital live. Getting jailed now is less of an issue, but I do worry about two or three regime changes down the line. Especially with demagogues and dictators on the rise seemingly everywhere. People with other backgrounds likely worry less about something like that. But here in germany, especially east germany, we kind of have a messy past in that regard. Right now I do not trust US intelligence to ignore an as awesome treasure trove as countless personal backups. I also do not expect individuals at Backblaze to risk their freedom/livelihood by violating NSL's, if received. I certainly would not. But yes, at the same time I'd highly value a company taking the extra effort to require me to only trust in what is running on my hardware. And thus I could theoretically audit. Bonus points for making an audit as easy as possible, by e.g. choosing open source or an easy to reverse engineer tech without relying on obfuscation. Though I'd understand this not fitting into / being part of Backblaze's businesses plan. May I ask why Backblaze doesn't offer client-side decryption? Is it just the design you've chosen and a change not worth the effort? Maybe to somehow prevent abuse? Or it saves a bit of traffic, like in case the encrypted blocks contain additional data that don't need to be restored? |
Kind of a historical accident mostly.
When we built the very first product, we just thought we would build a web based restore process, and the ability to view your files online with a web browser, which means you have to hand us the private key ONLY FOR the web session to view your files, and it is only stored in RAM.
What followed (12 years ago) was that we immediately found out the maximum download size of many web browsers was only 2 GBytes (which was a complete shock to me personally). So I had to VERY QUICKLY write this hacky "bzdownloader" which could download arbitrarily large restores -> but again, I was just dealing with what we had built already so we never got around to decrypting on the client side.
After a while, it became clear that we only lose like 1% - 2% of our business to people who wanted the other model (download the encrypted file and decrypt it on the client side), and so we kept prioritizing other features ahead of that. :-) For example, businesses had a very particular problem that prevented 20% of our sales from occurring. Businesses wanted to pay for many backups at once, but not necessarily have access to do the "restore", just pay for all their employees backups in a kind of "site license". So we created "Backblaze Groups" which allows you to pay for other people's backups, and our sales jumped up 20% after that. Then businesses wanted "Single Sign On" so that when they revoked their employee's ability to sign into their email account, it would automatically revoke the employee's ability to prepare a restore. Sales jumped up again, yay! :-)
It is absolutely a requested feature to add "client side restore" which combines several features - get rid of the clunky "zip" format which can cause some issues, and decrypt on the client side. I fully expect it will percolate up to the top of the requested features list and get done in 2020.
One of the fun, but challenging aspects of never raising any Venture Capital is we can only hire more software engineers when our sales rise to support their salaries. Currently the only voting board members at Backblaze are all 100% employees, and employees own 95% of the company. (We did raise a very small friends and family round more than a decade ago, which is where the other shares reside.) But sometimes our slow progress is frustrating to customers who are more used to massive software shops with millions or billions of dollars of funding. :-)