I don't see any compelling reason an admin should
  have access to user data like uploaded files. 

Mostly, uploaded files are stored unencrypted on a webserver though. The reason for this is that those are mostly "public" files in the sense that they can be accessed by a URL. Encrypting these does nothing really, except place additional load on the webserver when it has to decrypt them on-the-fly and admins would still be able to retrieve the key used for this from the software that is running on the server. This scenario is the most common one when it comes to user storage, and for good reason.

Encryption protects against a compromise of the backend. This lets 37signals, for example, store user data on S3 without leaking the user's information outside of the organization.

The overhead of decrypting an image is minimal compared to the latency introduced by a network fetch and by handling the rest of the request cycle in Ruby.

(And FWIW, people don't often have access to production encryption keys like this. Privacy is a big deal.)

Sure; that's what I meant by "considerable technical hurdles". But if these technical obstacles did not exist, if browsers had APIs to handle encrypted data for instance, would there still be a reason to give admins access to those files?

Browsers having APIs to encrypt and decrypt data in these scenarios is worth looking into - however, I do believe there might be a lot of apps that can't really profit from such an API. For example, what happens when you want to share an encrypted file with other users?

That's what public key encryption is for, no? The server just needs to store the encrypted files and the public key of each user, and files can be shared without the server being aware of their content.

To make this work, we'd need a pretty complicated system to distribute and manage those keys (and in a way they stay encrypted during transfer and storage). Furthermore, your client key pair would have to be stored on your machine, that means a service where you can't log in with just a password. Don't get me wrong, I think it's an interesting idea, I just don't see how this is not going to be a huge complexity and usability nightmare in applications that are designed for sharing data.

It's not complicated to distribute public keys. They're public keys, so put them in a public S3 bucket.

Private keys are marginally more complex, but not much. If a password is sufficient security, then the private key can be stored remotely (in S3 or whatever) but encrypted (symmetrically) with a password.

So say Alice wants to share a file with Bob. Alice's client downloads her encrypted private key, and prompts Alice for a password. The private key is decrypted with the password and stored in memory. Alice then downloads the file she wants to share with Bob, and decrypts it with her private key. Then she downloads Bob's public key, and re-encrypts the file with Bob's public key. She can now send the file to Bob securely without the server being aware of the content.

So now that we've got Alice and Bob covered, what happens when Alice wants to share a file with a group of people. And what if that group is dynamic? Is there something that addresses this scenario?

One of the members of the group can generate a new key pair, and share it with all the other members (in the same way one would share a file with each individual). If Alice sends a file to the group's key pair, anyone in the group can read the file.

Adding members to the group is trivial; just send them the group's key pair. Removing a member would be more difficult. Perhaps the most convenient way would be to add an additional layer of security on top (so members would need server access permissions, plus the private key). The only other option would be to create a new group and to re-encrypt all the existing files with a new key.

> It's not complicated to distribute public keys. They're public keys, so put them in a public S3 bucket.

AViD's answer on this security stack exchange is useful.

(http://security.stackexchange.com/questions/406/how-should-i...)