This article has moved to our new Help Center and will no longer be updated on this page. Please see the Help Center for the newest version.
Neither FTP clients nor web browsers are very well suited to doing cryptography as part of the upload/download process, so accessing your data this way would require the server to first decrypt your data, and then give it to your browser. This breaks our zero knowledge model, where SpiderOak does not have your encryption keys, and SpiderOak servers are entirely unable to decrypt, read, or send any data.
While there have been recent developments in Java and Javascript to handle intense cryptography in the browser as a part of a web based application, the libraries involved are not efficient, and more importantly, not vetted and security audited the way C libraries have been. At least for the time being, we think the best place for intense cryptography of the contents of one's filesystem is within a desktop application. As this changes, we'll be among the first involved.
So, SpiderOak's approach to uploads and downloads is that upload transactions are created in encrypted form by the local client, then uploaded to the server. Downloads happen in the reverse order. Never does a server know any plain text data -- not even file or folder names. In the datacenter, we store only sequentially numbered data blocks. If you lose your password (from which your encryption keys are generated) we cannot recover it for you.
Nevertheless, convenient web access is important to many people, so we did build a web access option. It stores the user's password (and derived keys) in memory only -- never writing the session file to disk -- and purges them from memory as soon as the session ends. On our website, we actually recommend against using the web interface at all due to this issue, but we provide it anyway, due to overwhelming customer demand.