I won't post to say "I haven't looked at the contents of the
file, but it's named 'cat.jpg'" either. I won't even post to
announce that the one hundred millionth file has been stored.
[...] This is because I have no way to obtain that information.
The contents of files [...] is all hidden from me by Tarsnap's
strong client-side encryption.
I agree that cat.jpg was a privacy violation and I do believe they did more than simply look at the filename. However, I'll take the unpopular position that this is within the limits of what one can reasonably expect from a website providing a service as 37signals does. Admins will, and are completely expected to, look at the data - if only to make sure everything is working. Looking at a file called cat.jpg because it's the gazillionth file is pushing the boundary a bit, but I still think this is OK. The moment I opt to use a hosted project management software, I implicitly accept that things like this (and potentially much worse) might happen.
Forgive me cperciva, but to me your post looks just like a giant plug for your own service. Client-side encryption is not warranted for everything, nor is it a reasonable goal for every app that shares data on the web. It's fine that Tarsnap does this, and frankly I would expect the same from a service like, say, DropBox - but it's not a reasonable expectation when it comes to the type of apps 37signals provides.
I do believe they did more than simply look at the filename.
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
I'm probably a little less trusting on this. An admin seeing the filename in the logfile and just calling its URL out of curiosity seems like a very likely scenario to me. They said something like "...and it was a picture of a cat", not "...and it was named cat.jpg".
How does looking at individual files help to confirm that things are working?
Not in this case, but having access to the file storage system per se is common and useful.
But I didn't write that post because I wanted to plug Tarsnap;
I understand. The combination of pointing the finger at someone for wrongdoing and then asserting your own superiority seemed inappropriate to me though. I understand where you're coming from, but I also believe to you the world is now full of places that should have client-side encryption, when in fact I don't think this is a good fit for what 37signals does at all.
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 not a 37signals user, and I haven't read their policy. I agree that changing the policy following this incident is very bad timing, but I think this maneuver does correct an unreasonable expectation users might have.
I don't think [client-side encryption] is a good fit for what 37signals does at all.
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.
I think most computer-savvy people, looking at a file called "cat.jpg," would make the leap to "it's a picture of a cat." The name is practically just a compressed version of that.
That was actually exactly the alternative I had in mind, an icon for a catalog feature in some sort of application (though a PNG would have been more likely.)
How does looking at individual files help to confirm that things are working?
"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.
The fact that they can notice private "illegal content" at all is a violation of trust. If I mark something private, I should expect that it will be private from everyone including employees of that company.
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.
If the bank sees you carrying in a body to put in the vault, I would expect them to call the authorities. However, if the bank guarantees privacy of what they store in the bank, I don't expect them to be looking inside anybody's safe deposit box to see what is inside. It doesn't matter if it is money, personal documents, blackmail material, jewelry (stolen or purchased) or even body parts.
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.
The problem is, you're missing the point. What they would do if they came across illegal content is irrelevant. They shouldn't be looking at the content in the first place, so this is a non-issue.
In a new theoretical world where browsers can encrypt and decrypt data securely without the server having any idea of content, and where you can solve all the issues around allowing other people you want to be able to access that data, then sure it's a non-issue. I was talking about reality ;)
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.
I think you're being downvoted because you're making a very similar argument to "if you have nothing to hide you have nothing to fear". The only circumstance where the bank would find a dead body in a vault is one where they open every vault just in case.
I totally disagree that this came off sounding like a plug for Tarsnap. This is one of those perspective-changing point which can only be made by using concrete examples.
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.
Forgive me cperciva, but to me your post looks just like a giant plug for your own service.
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.
I just wonder why they didn't say it was made up -a joke with no basis in reality. Just some poetic license.
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.
There are considerable technical hurdles in writing a web application that doesn't store unencrypted data. However, in principle, I don't see any compelling reason an admin should have access to user data like uploaded files. Ensuring an encrypted file is backed up and available for use is no different to doing the same for an unencrypted file.
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.
Forgive me cperciva, but to me your post looks just like a giant plug for your own service. Client-side encryption is not warranted for everything, nor is it a reasonable goal for every app that shares data on the web. It's fine that Tarsnap does this, and frankly I would expect the same from a service like, say, DropBox - but it's not a reasonable expectation when it comes to the type of apps 37signals provides.