Hacker News new | past | comments | ask | show | jobs | submit login

You almost have my opinion changed to agree with you that the people who are offended are right to be offended. But honestly, isn't it a little naive to think that the company holding your data won't have some access to it? I tend to believe that unless it's on a machine you own then someone else can and will look at it in some way. They may not look at the contents but they most certainly will check out the file type, size, name, date created, etc.

Now if you upload "HowToBeat37Signals.docx" to Basecamp you should probably assume two things. There's the possibility, however remote, that someone not authorized will see it (that possibility exists on every farmed out service, no server is hacker proof despite GoDaddy's little badges) and if someone does see it and it gets leaked or used against you, you'll have a damn good chance of suing the bejesus out of them.

The word trust is the key word here. Whenever you use a service to store sensitive material there has to be some level of trust. I think it's a mistake to trust that no one within the company or as a result of a security breach will absolutely never ever see what you've stored. What you do trust is that the odds of that happening are supremely low and if someone were to see your data (at least within the company) that they won't use it against you or share it. History has shown us that no web service is 100% secure and reliable so if you aren't comfortable with your odds then you shouldn't use the service. I for one assume everything I've ever put online is not secure. I'm comfortable with my odds though and bank on the fact that no one will take something written or created by a nobody like me very seriously or care at all.




If the app is written appropriately for this sort of thing (see Tarsnap), then no, the company has no access to any of your data.


Can you actually make that work for a collaborative app?

User A uploads file_a.txt and you want to encrypt it. What key do you use for that? It can't be attached to User A (e.g. their password or password hash) only otherwise User B won't be able to decrypt it. How would you set that up in a way that's still reasonable considering Basecamp use-case? (meaning: one of their goals is to make project collaboration simple)


I dunno, maybe generate a keypair to en/decrypt the content, then encrypt multiple copies of that keypair with per-user keys? A key-getting-key or something like that.

There's probably some huge issues there, but it's a start to answering the question.


> isn't it a little naive to think that the company holding your data won't have some access to it?

That's a good question. Hopefully my answer does it justice.

First, having access to something and accessing something are two completely different things. I'm not suggesting that they should not have access to something they need to do their job. However, that doesn't mean we can't expect them to minimize the risk.

Next, you argue that someone not authorized will see the document, however remote. You mention suing, and while it sounds great, it's a long, painful struggle that I imagine isn't a quick fix. More importantly, would you knowingly hand over private data to someone who has proven incapable of keeping your trust? This is the reason 37Signals is jumping on this so quickly and doing damage control (and I say that in a complimentary way). It's not just their paying customers they have to concern themselves with, but also all the people that use their various services in one form or another.

Finally, you mention trust. In this case, you suggest trusting the odds. I'd prefer to trust that the company isn't banking on odds, and is instead actively working to mitigate that risk. Odds are a funny thing. I'm not under the belief that they can provide 100% security and privacy, but that doesn't mean I need to blindly accept failure.

> I for one assume everything I've ever put online is not secure.

But I bet you still actively work to ensure everything is secure as possible. You don't share your password to your bank. You won't hand over your credit card data, you make sure you are using SSL before making a purchase, SSH, different passwords. A variety of things to mitigate the risk.

Honestly, I think part of the reason people are defending 37Signals is that for many of us (myself included), we never really think of these things, and we see how easy it would be for us to make the same mistake. Instead, we should be focused on the fact that even for a company like 37Signals, they can make mistakes.

They can also admit to them, apologize, and work to correct the problem. We should learn from this, and try to improve.


You make a good case but I'm still torn. You may be partly right about why we're defending them but what's foremost in my mind when I defend them is how innocent what they did was. All they did was look at a file name of their 100 millionth upload. They were proud, wanted to brag about, and I really empathize as they meant no harm. I trust that they only did this a single time only to mark the special occasion and mentioning the name (or assuming the contents of, in this case) the file only happened because it lent itself well to the joke they referenced, otherwise I have no doubt they would have just said they hit 100 million uploads and left it at that.

When I talk about odds we're on the same page in a way. We absolutely should expect them to minimize the risk but let's not fool ourselves into believing that no one will ever take the opportunity to access one of our files. The best we can do is mitigate the risks and hope for the best. I don't feel that their pulling up the file name in this situation is a meaningful breach of trust. As programmers we like nice, neat, black or white answers, absolutes but in this case you have to take the circumstances and the company's track record into account. 37Signald has never shown itself to be untrustworthy and I really think this is much ado about nothing. I'm having a hard time arguing your point because I agree with you for the most part. I just think that this one instance is very obviously a special circumstance and any casual observer would certainly let it slide without a single red flag being raised.

I usually don't go down this road but I've yet to figure out what person or group made this an issue? Did 37Signals bring this up on their own? I know there were a few comments questioning them when the original post cake about but it didn't seem like anyone was that upset ver it to the point that a blog post was necessary. There are a lot of individuals who are just haters and take any opportunity to come out of the woodwork and point out any itty bitty flaw they see and make it into the end of the world. I hope that's not what started this. I also wonder if some competitor or "enemy" for lack of a better word decided to make this am issue. Or maybe it was really just some of their users in which case all I can say is, fair enough. I don't agree but a company does serve at the pleasure of its customers to a large degree.


I can respect your opinion, despite disagreeing with it. =)

> any casual observer would certainly let it slide without a single red flag being raised.

Casual observer, sure. But, I imagine it was more than just a casual observer making a fuss, as I suggest below.

> I usually don't go down this road but I've yet to figure out what person or group made this an issue?

From what I know of 37Signals, they aren't the type to bow to the pressures of haters. I imagine there was some real concern here brought forth by people not in the public eye.

Anyways, thanks for the good discussion.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: