Agreed, it's just got to work.
We're working on an alternative: https://www.sync.com/your-privacy/
We're working on an alternative: https://www.sync.com/your-privacy/
If the service provider controls the code in the client (as you do), the fact is the service provider definitely can access the data, you're just choosing not to.
I don't think there is much difference between encrypting client-side when you control the client, and encrypting server-side before storage. Either way you have encryption-at-rest.
Overall though I would agree that you can't trust it much, because some code is downloaded from the server and then you trust that code (which can communicate with the server) with the key... Perhaps if it was in a local sandbox whose policies were enforced in a browser pref, or there was taint analysis applied to sensitive local data.
In years to come people will snicker at how wide open and insecure things were back in 201x.
But just because you encrypt server side doesn't mean you store keys.
What's the difference between:
1. Get key from user on client
2. Encrypt on client
3. Discard key
4. Discard unencrypted data
5. Send encrypted data to server
6. Store encrypted data
1. Get key from user on client
2. Send key and data to server over SSL
3. Encrypt on server in response handler
4. Discard key
5. Discard unencrypted data
6. Store encrypted data
Big picture: either way the developer sees the key and the unencrypted data. Either way, you are completely trusting the competence of the developer at implementing this scheme, and their trustworthiness with the key and unencrypted data.
There is no such thing as "host-proof" encryption as long as the client is provided by the host.
Will you have a Linux client? (I'm sure that's the least favorite question new services like this get.)
I ripped Dropbox out by the roots on all of my systems some time back because of the contempt they display for their users. New, more privacy- and security-conscious services are nice (as are ones that don't break their users' machines and then go weaselly when caught). But I really want the option to use my own infrastructure for apps that want to store data somewhere remote.
Especially for file-based services, the only argument for Dropbox is "because they're big and probably already installed"[2]. I'd deeply appreciate it if these sorts of apps would add a preference-pane for scp, at least. I have no idea if the crusty-folks-like-me market is big enough to constitute a noticeable bump in app store sales or not, but I promise, given two competing apps, I'll forgive a lot of other warts in and pay more for the one that lets me own my own data.
[1] I know cloud is king, but there are a lot of us out here that want to own our own data, rather than having the cloud-overlords rent it back to us. The Omnigroup's apps are great examples of this - you can use their sync servers, but you can also (and I do) run your own WebDAV server for it. Works great, and I have paid the Omnigroup substantially more than any other single mobile app vendor for their apps.
[2] Synchronization is difficult enough in some contexts that I completely get writing something more complicated there, but then we're not talking about Dropbox or their competitors anymore.