We'll have to disagree there. I'd be very surprised if they did any more than looking at their log files -- most likely using tail -f -- as the 100 million mark approached.

Admins will, and are completely expected to, look at the data - if only to make sure everything is working.

How does looking at individual files help to confirm that things are working? Once you're operating at scale, looking at individual files doesn't tell you anything useful; if there's a big problem users will notice it before you do, and if there's a small problem the files you look at probably won't be in the affected set.

Forgive me cperciva, but to me your post looks just like a giant plug for your own service.

Was I plugging Tarsnap? Sure; I mention it every chance I get on my blog. But I didn't write that post because I wanted to plug Tarsnap; I wrote it because I saw the trust-is-fragile post on HN Daily and felt that revising their privacy policy wasn't the right response. (If I had noticed that post when it was first discussed here, that blog post would probably have been just a comment -- but since I was about 24 hours late to the party I figured that nobody would read a comment I made here.)

  We'll have to disagree there. I'd be very surprised if 
  they did any more than looking at their log files

  How does looking at individual files help to confirm that things are working?

  But I didn't write that post because I wanted to plug Tarsnap; 

  I wrote it because I saw the trust-is-fragile post on HN 
  Daily and felt that revising their privacy policy wasn't 
  the right response.

I'm inclined to agree with you. That's what I was getting at with my "even if 37signals doesn't want to offer cryptographically secure storage, they could at least remove the temptation to look at file names in log files by not writing sensitive information to log files in the first place" line.

http://cl.ly/0Y1M1D0z1g123I0S0u1R - cat.jpg ;)

"Hello, thanks for calling tech support. How can I help you?"

"I uploaded a file but it's not showing up in my account."

"What was the name of the file?"

"Cat.jpg"

"Ok, give me a moment to look at the logs..."

These are the kinds of questions that come up all the time in supporting a SaaS product with non-technical and semi-technical users. Debugging is not something only programmers do. Oftentimes bugs are found only after a client interacts with support.

Oh, another thing: deletes. At my last company I can't tell you how many times customers wanted us to restore deleted data. After many frustrating support experiences we implemented soft deletes for most objects. Hard deletes required written confirmation from the user and 48 hours to purge it from all backups.

Aren't there some instances where they'd be justified looking at data...

Attitude like yours gives us stupid privacy-violating terrorism and "protect-the-children" laws.

While it is reasonable to expect that they would contact the FBI in such instances, I would also hope that noticing such details illicits a "I shouldnt have been able to see that, so we're not doing enough to protect the privacy of our clients" response and corrective actions.

Surely there's some line somewhere...

edit: apparently HN thinks there is no line anywhere.

Investigating the contents of each safety deposit box, or even having the ability to do so is outside the scope of what a bank vault services are sold to do.

A bank vault, like encryption, sells protection. It is for all intents and purposes neutral. It can be used for good and can be used for bad. 95% of the time a bank vault or encryption is either being used for an ethically neutral or at worst ethically ambiguous use.

When any technology or product is used for bad it is a social failure. Crime will always exist. The quantity of crime committed can be mitigated by sound long-term policies that treat those causes that are statistically most likely to contribute to crime occurring in the first place.

Ever. I don't have the original source in front of me, but with enough bits, assuming there isn't some fundamental flaw in the encryption algorithm, you couldn't brute force a key before the heat death of the universe even if you recruited every particle in the visible universe for your computation.

Big "if".

I suspect he also means that they shouldn't be looking through files in the first place on the grounds that "there might be something illegal in them"

    Was I plugging Tarsnap?

That he happens to be an expert in the field of digital privacy and has a way to prove that he is such an expert shouldn't be held against him.

Reading his post was like an "oh shit, he's right" moment for me and using Tarsnap as an example was key in helping me understand it.

Considering that in the discussion around cat.jpg, many people here were talking about a secure back-up service which encrypts all data at the client side with auditable source-code as if it was an unrealistic, unobtainable goal, I have zero problems with that.

Would that be worse than admitting/pretending they actually saw a file called cat.jpg? If there was such a file, it could have been a JPG for catalog of some kind, etc.

I think they are responding to people's first expectations and that there was actually a file with the image of a cat. I doubt it and think it was just an attempt at being funny which backfired and they felt they had to take responsibility for the perceived breach of trust and that any other explanation, even if truthful would have been seen as a weak excuse.

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

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.)

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.

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.

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

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