sure, if the server is compromised there's really not much that will save anyone. but the user must necessarily trust the server at least with the data they intend to encrypt. for authentication they can trust some third party like oauth or persona/browser-id.
> but the user must necessarily trust the server at least with the data they intend to encrypt
not true. if i distribute an app that encrypts user data (based on a username/password-derived key), stores it on a server, and lets them access it anywhere (from the app), the server can be stupid as a bag of rocks and know nothing about the data, and more importantly, require absolutely no trust from the client because the client encrypts everything via code it owns. at this point, the user only needs to trust the app and the platform it runs on, because the server has absolutely nothing to do with the encryption.
if the sever does nothing but storage, you're right. i was talking more about something like SaaS and encrypting in transport, such as passing CC info or other sensitive data that the sever must know to pass through to gov't backends, payment processors or other apis.
you can't say, for example, that Lavabit could still provide a service without knowing the recipient's decrypted email address.
In those scenarios, client side crypto isn't even applicable to begin with. If the service requires trusting the server with sensitive information, then the best we can hope for is to secure the transport of the data, which is done with https. Client side crypto only comes into plays with apps where you don't want to trust the server with any sensitive data.
