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