While the tone of the post is fantastic, I can't quite believe that anyone would be as offended as they suggest. I would like to believe that people can apply common sense to this situation and realise that they disclosed 'cat.jpg' exactly because the name was entirely inoffensive and anonymous.
You miss the point. The point is with regards to privacy. If I'm paying them for their service, and I upload files, I can limit who sees them. If that can be circumvented, this is disconcerting. What if I had a file named "How to beat 37Signals.docx"? Or "Next iPad Specs - Official.pages" uploaded? And then someone reviewing the logs happens to see that. And they get curious.
The idea isn't that cat.jpg is bad. It's that over at 37Signals, someone was browsing the logs, reviewing the file uploads, and did see "2011 Financing Report for X Public Company - Unreleased" or something akin to that.
I understand your point of view. But the people offended by this are in the right. It's not what happened, but that it happened, and what it shows.
The idea isn't that cat.jpg is bad. It's that over at 37Signals, someone was browsing the logs, reviewing the file uploads
Rather, they did "SELECT filename WHERE row_num = 100000000".
Honestly, if you're concerned about something like this then you should not be using a third party solution to store your files. Of course 37 Signals can look at the names of the files you are storing- they could probably hide that information from themselves, but then they'll get a support request saying "we can't open file-x.jpg" and they won't be able to do anything about it.
Rather, they did "SELECT filename WHERE row_num = 100000000".
They're the ones who have repeatedly described it as "looking at the logs". That struck me as weird -- to have a log that ordinally attributes every upload -- however that's how they describe it and is hence why others describe it so.
Honestly, if you're concerned about something like this then you should not be using a third party solution to store your files.
I engaged in the prior argument, and there too this was the common last line of defense.
It misses the point.
Everyone knows that SaaS vendors can access your data and files, so it is bizarre that this keeps getting mentioned like it was unknown. Yet critical businesses engage vendors to hold their most confidential files -- the sorts that auditors grill them over and various bureaucratic organizations monitor them on.
Because they know, or at least believe and hope, that the organizations they entrust with their data use discretion, and have standard policies and standards -- if not actual data security and auditing controls -- to ensure that data is only used on a need basis. For instance for support purposes.
Writing a blog post that flippantly mentions a customer's data sends the wrong message. While we all know it is possible, it gives the entirely wrong impression to customers. Data security is the #1 impediment to the adoption of SaaS.
SaaS depends upon the trust of customers, and DHH is approaching this in the right way. It is quite a contrast from the many laissez faire responses on here.
Like you say, everyone knows they can access your files. It's naive to assume that they won't. Of course you wouldn't expect them to be doing this on a large, detailed scale but I think we all assume they occasionally see someone's file. The laissez faire responses wouldn't be the demise of SaaS, we're just being realistic about things. Trust is absolutely paramount when using these services but I think you're focusing on the wrong thing. Trusting that they won't see the files isn't the thing to trust. You trust that you have a better chance of being struck by lightning than of having an employee or attacker read and/or share the contents of that file.
I agree, Jason. While it's unavoidable that we at times will see things through log files in order to ensure the performance and uptime of the system, it certainly shouldn't be for these causes and it double certainly shouldn't be in order to reveal anything publicly.
>What if I had a file named "How to beat 37Signals.docx"?
They wouldn't have released it, and you would be a moron for storing that data on _their_ servers.
> Or "Next iPad Specs - Official.pages"
You'd be a moron for storing that data on their servers.
The existence of cloud solutions doesn't beget the use of self controlled servers for truly critical data.
The reality is that the vast majority of business data is not interesting to anyone but themselves and possibly competitors. And the vast majority of those businesses and competitors are well outside the scope of 37. Thus your data is relatively safe. If you're that worried about the hosting provider being able to view you data, host it yourself. Simple...
I think if you upload your data to some cloud service, you should assume that the employees of the company can look at it. The error here was some employee leaking information to the public (the name of a file).
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.
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.
