[sunchild]

It tells us that they looked at customer data, and that's a really, really big deal to people who are doing serious business that involves private information that is: (1) regulated by government, and/or (2) has significant commercial value.

You can waive your arms and talk yourself blue in the face about your security protocols, but in the end it all comes down to trust. This kind of slip-up erodes that trust.

[walkon]

> It tells us that they looked at customer data

Have you ever supported a product that has external users? Eventually have to see their data in some way, shape, or form. Whether it be a username, email address, ip address, user-agent strings, filenames, etc; there are times when troubleshooting, verifying functionality, validating report data, etc where you will have to look at at least some subset of actual customer data somewhere. It is simply unrealistic to think otherwise.

How would you go about providing customer support or auditing without looking at the customer data required to complete such tasks?

(edited to add quote)

[sunchild]

And announcing the content of the one millionth file upload is serving the customer how?

[huggyface]

>Have you ever supported a product that has external users?

And if an apartment dweller had a plumbing leak, the landlord would enter their apartment and fix the leak. They would access on a need basis. They wouldn't do casual sneak and peeks and then post analysis on the entry door that seven residents have bongs in their living rooms.

Seriously, though, mechanisms to deal with exception situations, such as customer support, has nothing to do with "looking because it made for a fun blog post".

I only engage in this conversation because this is important for many HNers -- spin all the justifications you want, or blame users (a good attitude that guarantees business failure), however this was a serious blunder that other businesses should look to avoid.

Even if you do casually trawl the data of your users, for the love of all things unholy don't talk about it.

[daemin]

Actually it only tells us that they looked at their own logs.

You could maybe classify that as looking at customer meta-data if you wanted to.

Though if you think that is bad, what do you think of when you call a bank and the person at the other end can see all of your private banking data? Or even when you call some other company and some random call centre employee has your whole transaction history in front of them. Shouldn't that worry you more?

[54mf]

All we know for sure is that (a) they counted the number of files, and (b) they read a filename. I'd be willing to bet they don't even know who the user is - in a properly normalized database, all they'd likely see is a user ID unless they explicitly have an interface that correlates user ID and file data with personally identifiable user information.

Perhaps saying, "it was a cat" was a poor idea if they only read the filename, but a lot of people are making a lot of assumptions here. If you're dealing with regulated or high-value data, you probably shouldn't be using 37signals without doing any kind of audit of their operating practices anyway.

[csallen]

Erodes what trust exactly?

You're assuming 37signals made an agreement ("we won't be able to see your filenames in our logs") that they intentionally never made, and then you're claiming they violated said non-existent agreement.

If you're a company with super-sensitive data then it's on YOU to choose the appropriate place to store that data. There are services made explicitly for that sort of thing. It's absolutely ridiculous and irresponsible to require a certain level of privacy features, sign up for a service that doesn't have those privacy features, and then act as if they violated your trust.

[sunchild]

Actually, I agree with you. 37Signals is characteristically up-front in their security policy about not being an appropriate solution for sensitive data. That's why I don't use them for my own client work. I respect their decision not to take on that responsibility.

Having said that, their security policy does suggest that customers expect some level of privacy. It's just bad form to publicly announce that you've been poking around the content of customer data as part of a fun blog post about metrics.

Nobody is building classified weapons on Basecamp. If you say that Basecamp customers shouldn't expect any measure of privacy, I'll respectfully acknowledge that you might be correct about that.

[csallen]

> That's why I don't use them for my own client work. I respect their decision not to take on that responsibility

I respect that viewpoint immensely, and I wish more people would think like that.

I think the main issue here is that the words "privacy" and "security" are so vague as to be meaningless. Consequently, people have mapped their own personal definitions on to them. For example, different people may care about different subsets of the following:

- Do you use SSL when I transfer sensitive data to your servers? - How secure is your database? What do you use to protect stored data from hackers? - Do you share user data with third-parties? If so, do you anonymize it? - Do you prevent your own employees from accessing my data? - Do you have an SLA that guarantees I will be able to access my data the vast majority of the time? - Do you have measures in place to ensure my data is never accidentally deleted?

Etc. The list could go on and on. If the customer is worried about any of the above (and sadly, most aren't), then she's in luck, because privacy policies and company email addresses are usually a click away on the web. I doubt I know anyone familiar with all the privacy and security processes employed by banks, doctors, financial aid offices, etc. Which is why it's confusing to see so many technically-savvy people up in arms about the name of a jpg file.

[mtts]

Right. Because no ISP sysadmin will ever keep some sendmail logs open and thus see that secretive_user@other_isp.com is sending mail to another_secretive_user@this_isp.com