This doesn’t really mean it is insecure, just that the encryption key can be generated from the unencrypted data and stored along with the backup.

lets say you take a hash of an unencrypted chunk and use that to encrypt the chunk of data. You then encrypt the hash using your personal encryption key and upload the result with the encrypted chunk to the server. When restoring, that encrypted key is returned with the chunk so the client can decrypt the data.

Because the chunk is always encrypted with the same key on any system, the encryption key will always be the same even if the server never knows it and the encrypted chunk will always be the same for the same unencrypted chunk input. The encrypted version of the chunk can then be deduplicated as if it were unencrypted because it is essentially the same as the unencrypted version as far as the server knows or cares.

As for not storing meta-data, it is kept outside of the file and isn’t really part of it. Backup software could check it and store it if it wanted to, but I don’t think this is a priority as the creation date of a file is no where near as important as its actual contents.

Whole cloud de-duplication – All of the data you backup to spideroak, regardless of the source is de-duplicated

How is de-duplication supposed to work in combination with local encryption?

Wuala for example offers local encryption but cannot offer de-duplication at the same time …

I just downloaded the latest version of spideroak (3.6.9643) and the option you mentioned is still not present. Any idea what the ETA is on this? Also, to solve the problem of allowing a user to reset a forgotten password without knowing the current password, what about using another piece of information from the user? For example, you could ask the user to enter their birthdate and mothers maiden name.