Slashdot Mirror
Reasonable Expectation of Privacy From Web Hosts?
Shafted writes "I'm in a bit of dilemma, and I'm wondering what fellow Slashdotters think regarding this subject. I've been hosting web sites for some clients for years using my own server. About a year and a half ago, I got a reseller account with a company that will remain nameless. They are, however, fairly large, and they did come highly recommended. Other than the usual slow tech support, occasional server overloading, and... well... typical support staff, it's been pretty good and has saved me from having to deal with problems like hardware and driving down to the colo at 4AM to figure out a routing problem. All-in-all, it was acceptable. Until yesterday, when I was asking for a relatively minor email-related fix, and by the tech support staff's response, they had accessed my MySQL database directly and looked at the contents; presumably, in order to tell me what I was doing wrong. Regardless of the fact that they missed the boat with regards to the support question, I found it surprising that they would access my database data without my consent. When I asked them why they were accessing the database without my permission, they've pretty much ignored me, despite repeated requests asking why they think this is acceptable. So, my question is this: Do I, as a customer who, according to the acceptable use policy, owns my data, have a reasonable expectation of privacy for the data which I own, despite it being hosted on a third-party's server? Or do web hosting companies have the right to poke around at everyone's data as they see fit?"
Read below for the rest of the question.
Shafted continues: "I did get a response from one of the higher-ups, who said it was ok - they were perfectly within their rights, and their privacy policy supports that. Problem is, I've read the privacy policy, terms of service and acceptable use policy, and nowhere does it make mention that they have the right to look at files or data. It does indicate that I am the one who owns the data (presumably to cover copyright infringement). Another fellow indicated he felt that, as site admin, he had the right to look at whatever he wanted on the site, whether it's his data or a customer's (he, from what I can tell, is not an employee). I can understand looking at data to determine whether it violates the AUP or TOS, provided that it's justified (i.e. a scanner or audit indicates that something fishy is going on). But since I haven't violated the AUP or TOS, do they have this right? Is this something all web hosting companies do? If it isn't expressly stated, either that they do or do not have the right, does that automatically give them the right? Is this an industry norm, or did someone make a mistake and they're simply unwilling to admit to it? I'd really like to hear what some of you have to say, knowing that many of you probably have sites hosted by third-parties, and some of you may work for web hosting companies. Since this is the first one I've ever dealt with, I'm unsure whether I should expect this anywhere else, and if so I may end up going back to self-hosting."
there isn't much you can do. if you choose to co-locate your server at another location, be prepared to have other people looking at your stuff all day. If you have issues with that, either encrypt your private data, or dont co-locate your data at some hosting provider.
that no matter what, when you sacrifice control for convenience there is always going to be a chance that someone is going to poke around your stuff. It's a risk of the business.
load "$",8,1
Hmm... I can see your point. Nothing anywhere in their policies that you agreed state they have that right. And you also seem ok with it IF they suspect or even have proof that someone broke the agreement that both parties made.
Often times people will put private stuff on a server they rent/own and make the files/folder private so that they and a select few can only view the files. So what right does hosting company have to look at information that's private without my consent?
I think this goes beyond the "well I own it!". Guess what? When you rent out a house to other people, you don't have the right to snoop on your renter's. You can't just access their house whenever you please. There's an expectation of privacy and I think the same applies here.
My suggestion? Kindly tell them to fuck off and find another hosting company. I would suggest you make it public who this company is and what their practices are so the rest of us can avoid them too.
We had some affiliate software, X, on our servers.
The internal mailing script was buggy, so I'd written another one, scrapeX.php.
We had some unrelated problems, which required them to have access to parts of the box.
All of a sudden, I'm receiving confirmations of email receipts: their incompetant 'tech' had fixed the problem, then poked around, found a script scrapeX.php and thought: well, I'd better run this, to see what it did - and ended up mailing all our clients.
Action taken: a virtual shrug.
You have to bear in mind that on hosts that are geared towards entry-level users, that the clients have a tendancy to destroy things in ways possible, which is why they probably did a look around, similarly how when you call your ISP for issue X, they normally give the list: is your power on, can you ping this, can you do that..
Who is this hosting company, and why are you protecting them? People should know what they're getting into when they enter into an agreement, and it sounds like this company isn't doing that. I don't know if this is "industry standard", legal, or whatever, but I'd run away very fast from this hosting company. Find another hosting company that'll give you assurances in writing that they won't look at your data without your permission. They can't ALL be douche bags.
AccountKiller
Wow.. I think this is the first time I've seen an Ask Slashdot so comprehensively addressed in the first comment. Nice going, dude!
As this issue has been so speedily resolved, I propose this discussion be archived immediately and we all move on to more contentious, problematic issues in other stories.
Dreamhost repeatedly did this to me when I was hosting with them. They even modified my databases more than once. Mainly adding indexes (including ones that already existed...), but they changed the type of a column once.
That's one of the many reasons I'm not using them anymore.
I respond to your sigs
Isn't this the great flaw of Cloud Computing?
Playing in the clouds is convenient, but should probably be focused that way. Do serious stuff locally and transmit it as needed.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
There's no standard way to give out a permission that allows only the operations a co-location facility might need to perform - startup, shutdown, IP address change, and maybe encrypted backup
Actually, there is. First thing to note is that 'root' is just a name. It is UID 0 that is powerful, not the user named 'root'. You can create an account called root which has a different UID and it is just another user - give this account / password to the colo company and they will only find out that it's not root if they try to do something evil. Then, just give them permissions to modify the network config files and run shutdown / reboot as root and you're set.
Alternatively, you can create a 'colo' user which has write access to the network config files and has sudo access to the shutdown command, which might be cleaner, and if they complain about this limited access then move hosts.
I am TheRaven on Soylent News
Half of you people replying are completely missing the point of the post. He is NOT Co-Locating a server, he is a reseller. He is using the companies equipment and hardware. He owns absolutely nothing hardware wise.
As such, the company is perfectly within their rights to inspect what data is being stored on their servers, in a SHARED database. He's not the only customer using that MySQL server. He is not the only customer using that CPU, that hard drive, that webserver.
The hosting company has every right to be sure there is nothing in the database or elsewhere that is going to compromise the other customers.
That's why you colo a server. Then it's YOURS and YOU control access to it. No one is going to be inspecting anything on it without your consent or at worst, if they hack your password and/or reboot it without your consent into single user mode. Either way, then you'll know something hinky was going on. Whereas if you are just a "reseller," the hosting provider can do whatever they want as root on a box you do NOT own.
So yeah... if the original poster doesn't like it, he needs to colo a server. If he doesn't want the hassle of that, then you're at the mercy of the system admin.
So long as "enough money" is enough to employ multiple competent administrators. If a server goes down, somebody needs to bring it back up in a reasonable timeframe. Being on call 24/7 is not fun. What if you are sick or injured? What if you want to go on holiday? As you said, "Yay redundancy!" It's not just hardware that needs redundancy to be reliable, wetware needs it too.
Bogtha Bogtha Bogtha
Yes, because I can't possibly have read your post and disagreed with it too, right? Get over yourself.
Lucky you. Just because the gamble paid off for you, it doesn't automatically mean that it's a good idea to do it.
When you take on the burden of hosting, that involves making sure somebody is around to fix any problems that arise. Sure, you can cut corners and gamble that nothing is going to go wrong, but that's a big risk, and it can result in a lot of stress and downtime.
Bogtha Bogtha Bogtha
You are way overreacting here.
As an ISP, I look at anything and everything that I think may be related to the problem. Absolutely I look at databases.
The expectation of privacy is that I won't repeat this information to anyone else. If you have a doctor, it is the same thing. You have no privacy as to the contents of an X-ray, or as to your medical condition. You have expectations of privacy as to disclosure. And if you were damaged, even due to negligence like en clair data streams used by the ISP for their inspection, then you would have a basis for court action.
If you want privacy from the vendor, seek encryption and take all the upside and downside that it entails. Don't expect support that requires your constant attendance to grant permission. "May I look at this file? At this one? And how about this one?" If you hosted with me and wanted calls like this every ten minutes, I would charge you $200.00 per hour from the moment my hand reached for the phone dial (or IM key, or whatever.)
Unfortunately for you, since acceptable use for both parties was laid out *in a contract* your point is moot. If the contract says "we will not do x" and they then proceed to do x, they have just broken a legally binding contract.
here's a good analogy for you:
If I go to stay in a hotel, does that mean that when I go to the front desk to ask where the pool is they're allowed to search my room? No? Then the "it's their property" thing is null. In fact, since you are PAYING for this service...
Anyway, it's *his* data. Just because it's on their machines does *not* give them a right to the data, especially since he is paying them for the privelege. He's not paying them to search through his DB, he's paying them to provide hardware and support.
Show this to your friends and family that don't know what a real hacker is
Isn't this the great flaw of Cloud Computing?
No, because that's what encryption is for. I use Jungle Disk to mount my Amazon S3 data as a network share on all of my systems.
Jungle Disk allows me to encrypt my data before it is sent to Amazon's servers. Short of cracking the 256-bit AES key the data is encrypted with, Amazon can't dig through my data.
Maybe for a web-based application, this wouldn't make sense, but at least in terms of storing my data in the "cloud" for retrieval and use by various client-side apps, there's no "great flaw".
'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'... if you're reading this, it didn't work.