5 ms·

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

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.

dhh 15y ago
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.
untog 15y ago
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.
- huggyface 15y ago
  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.
  - billpatrianakos 15y ago
    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.
Tichy 15y ago
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).
billpatrianakos 15y ago
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.
- count 15y ago
  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.
  - Timothee 15y ago
    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)
mbell 15y ago
>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...

dhh 15y ago

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.

untog 15y ago

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.

huggyface 15y ago
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.
- billpatrianakos 15y ago
  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.

Tichy 15y ago

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

billpatrianakos 15y ago

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.

count 15y ago
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.
- Timothee 15y ago
  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)

mbell 15y ago

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