Slashdot Log In
Reasonable Expectation of Privacy From Web Hosts?
Posted by
Soulskill
on Sun Jul 27, 2008 10:18 AM
from the it's-my-internet-i'll-do-as-i-please dept.
from the it's-my-internet-i'll-do-as-i-please dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
encrypt your data or dont co-lo (Score:4, Insightful)
Re:encrypt your data or dont co-lo (Score:5, Insightful)
Parent
Re:encrypt your data or dont co-lo (Score:5, Insightful)
Every colo I've seen in the US has a similar policy. In a colo situation it's your hardware in their facility. Some places have it setup so if a drive (or some other piece of hardware, RAM, power supply, etc) they can replace it for you, if you have a spare and you pay for that service. But other than that, they don't and can't (well not suppose to) touch your server.
This guy was in a colo, but decided to move to a webhost. It's no longer his hardware, just his data. Even if he has a "dedicated server" plan it's still their hardware. If your site is causing performance problems on their network, they can and do look into things without ever asking for your permission. They probably won't even inform you unless they determine it is your site causing problems. Then most hosts will shut you down or disable the script/database causing the problem, THEN inform you of the problem.
Parent
RTF Summary at least (Score:4, Informative)
He said he switched from colo to hosted to avoid having to take care of his own server.
Parent
Re: (Score:3, Insightful)
Whether or not the co-location could access it or not, I doubt they would do so. Every time you're logging into a box in that situation you're opening yourself up for liability if something goes wrong later or just because.
If the policy is to not touch the boxes without written authorization the facility can push responsibility for those sorts of issues to the box's owner or employees should they get sued.
It's a lot easier to just focus on keeping the facilities in proper order and billing than to worry abo
And the moral of the story is (Score:5, Insightful)
Re: People looking (Score:5, Insightful)
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.
Parent
Re: People looking (Score:5, Interesting)
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".
Parent
Re: (Score:3, Interesting)
I don't know if it's the great flaw. There are multiple costs you have to weigh.
It seems to me that vendors would key into it and charge premiums for more protection. That's the solution I would expect, the googles of the world will just charge more of more privacy, and that's kind of fair. The fact that those people were reading your database wasn't too alarming, the fact that they could do so so easily is a bit more, all it takes is one flawed SQL statement and they might not your application down
Slippery Slope? (Score:5, Insightful)
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.
Re:Slippery Slope? (Score:4, Insightful)
Well, in my State landlords have the right of "reasonable access". Maybe they can't just snoop as they please, but they do have the right (upon 24 hours notice, I believe) to enter their premises.
Parent
Re:Slippery Slope? (Score:5, Insightful)
They also have the right to enter when the tenant makes a maintenance request. If you think that "support call" = "maintenance request" then, well, there you go.
Parent
Re:Slippery Slope? (Score:5, Funny)
Parent
Re:Slippery Slope? (Score:5, Funny)
I see we've lived in the same apartment complex...
Parent
Re:Slippery Slope? (Score:5, Insightful)
That's not the same. Imagine that you call your landlord because, I don't know, a window's broken. He comes in while you're at work and fixes it (which is fine), but then you find out that he also went to your bedroom and read your diary.
This is exactly the same situation. Your landlord doesn't need to read your diary to replace the window, and despite the fact that he owns the property and despite the fact that he's there with your knowledge and consent, he doesn't have the right to read it, either.
The same goes for the webhoster.
Parent
Re:Slippery Slope? (Score:5, Insightful)
Keep reading the legal requirements and you'll find out that 24hr access also requires a legitimate reason, not just any reason. Generally this means they need to justify it, even if it is afte the fact. They have the right the deal with emergency situations immediately, even without 24hr notice. This would include such things as smoke/fire as well as visible signs of a water leak. Still wouldn't give them the right to go through your dresser.
It is entirely unacceptable to access a customers database without explicit permission. Period.
Maybe they were trying to be helpful, that unfortunately isn't the point in this case. They have no business accessing it now without some more direct permission. I usually handle such things by talking with the appropriate customer on the phone and telling them what I am going to do. I let them ride along to the extent possible (shared screens, whatever) so they can see what I am doing. If that level of their involvement isn't possible I still ask for permission and do what's required then.
If they refuse then they are left with the possibility of losing access to the server, or its data, etc, as required to protect my servers and my business. That still doesn't give me the right to access their data because I feel like it. Even if they asked for help.
note: I will say that I've had understanding with specific customers in the past that let me do what was necessary whenever it was necessary. This is followed up by a report of what was done, giving them an opportunity to complain about it if they so choose. If they were to complain I accessed their data without permission then they would receive an apology, I would refer to the previous understanding, and confirm that it would not happen again without their explicit permission. Period. Anything else is unprofessional.
The problem here is the tendency of admins to feel like they OWN a server, instead of them having certain, specific responsibilities for that server. It's an industry wide problem, and is somewhat exhibited by the recent issue in San Francisco. (Of which I believe both parties are significantly in the wrong. It's a pissing match and the system admin is not entirely right. Without explicit cause (imagination isn't cause) you do NOT configure a device without storing it's configuration in Flash. If you do that on a number of routers and there is a power failure it would take far to long to get everything back up and running.)
If, by nature of trying to track down an unknown problem an admin sees data that is otherwise not theirs to see I expect them to keep it to themselves. Not to discuss or disclose the contents. Depending on the nature of the data I would, however, expect them to disclose that such an incident occurred. I don't want them hiding the fact they saw 100 credit card numbers while packet sniffing for a specific problem. However, actual disclosure of those credit card numbers make them subject to termination.
You own the box, not it's data. You are responsible for keeping it running to the best possible, if that means deactivating a clients access, or applications then so be it. It doesn't mean you can go digging through their files.
I don't get why people don't understand this.
Parent
Re:Slippery Slope? (Score:4, Informative)
Where does he say that? It's unusual to have mail configuration depend upon a database, but it's not unheard of. For example, the simplest way of setting up a web interface to SpamAssassin is to configure it to read rules from a database. The only thing the Ask Slashdotter says on the matter is:
It sounds like he has put some mail-related configuration in his database and they looked at it because his mail wasn't working correctly and they suspected he had screwed it up somehow.
Parent
Re: (Score:3, Informative)
I used to do Tier II support for a major ISP. Much of my day was devoted to taking calls after a junior tech had failed. I'd say that in at least a third of the cases, that tech had gone haring off in the wrong direction and wasted time playing with things that had nothing to do with th
I've had worse. (Score:5, Interesting)
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..
Re:I've had worse. (Score:4, Insightful)
Wouw... Just wouw, he runs some code without knowing what it is supposed to do on a live server?
In a company I used to work we had an object with the function "destroyDatabase" which did exactly what it said (well cleaned up data for testing purposes). For some reason someone allowed this to get on to the live servers.
Several generations of coders later some smart guy decides to run this function on the live server, because he was wondering what the function did...
Parent
Re: (Score:3, Funny)
A zillion years ago, I had a shell account at an ISP. One day I saw evidence that a program in my directory had been run by root (it created several files as a result of running). That, in itself, didn't much matter, there were no privacy implications in that case, but the idea that root ran some unknown binary laying around in a customer's home directory was concerning.
Resolution: I left another binary in plain sight that when run immediately spawned several copies of itself and claimed it would wipe the f
Re:I've had worse. (Score:5, Funny)
REN Now, listen, Cadet. I've got a JOB for you. See this button? (Stimpy reaches for the button) DON'T TOUCH IT! It's the HISTORY ERASER button, you FOOL!
STIMPY So... what'll happen?
REN That's just IT! We don't KNOW! Maayyyybeeee something bad?... Mayyyybeeee something good! I guess we'll never know! 'Cause you're going to guard it! You won't TOUCH it, will you?
(Stimpy salutes. Ren leaves.) REN Hehhhh... hehhhh... hehhhh... hehhhh...
(Stimpy marches back and forth, staring at the button.) ANNOUNCER Oh, how long can trusty Cadet Stimpy hold out? How can he possibly resist the diabolical urge to push the button that could erase his very existence? Will his tortured mind give in to its uncontrollable desires?
(Announcer grabs Stimpy, forces him closer to button) Can he resist the temptation to push the button that, even now, beckons him ever closer? Will he succumb to the maddening urge to eradicate history? At the MERE... PUSH... of a SINGLE... BUTTON! The beeyootiful SHINY button! The jolly CANDY-LIKE button! Will he hold out, folks? CAN he hold out?
STIMPY NO I CAN'T!!! EEEEEYAAAHHHH! (pushes button)
Parent
I don't know if it's legal, but it's unethical. (Score:5, Interesting)
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.
Re:Not necessarily unethical (Score:4, Insightful)
It depends on the motive. From the text it seems as if they looked at the database to determine whether the data in it was causing the problem. I would say that it is reasonable for any sysadmin to look at data when it pertains to the smooth running of their system
I don't agree. I don't think it's ever ethical to look at private data without permission, even if you're trying to "fix" the customers problem. If the customers website is interfering with the smooth operation of the hosting business, disable the website and get your customer to fix it. If they don't know how/can't, then ask permission to fix it.
unless there was some explicit agreement that under no circumstances whatsoever were they to look at data.
That should be the norm, not the other way around. It's their hardware, and their system, but it's your data. It may not be legally defined like this but I'd never use a provider that didn't have this as part of the explicit agreement. It's rather sad that the attitude around here seems to be that admins can and should do whatever they please because "it's our hardware".
Parent
Unusual (Score:4, Insightful)
I've never had this happen as far as I know (obviously hosts can snoop without telling you). I'd say that this was quite unusual, if for no other reason that hosting companies rarely help you diagnose problems that are likely of your own making. They'll usually just tell you to revert to a supported configuration.
It seems quite odd that they'd be poking around in your database to debug a mail configuration unless you are doing something unusual. But if it is indeed technically related, I doubt you could support the argument that they shouldn't be inspecting your configuration when you ask them to help you debug something. If the database can cause your problem, then how do you expect them to help you without giving them access to it?
Lemme guess, Dreamhost? (Score:5, Interesting)
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.
From home? (Score:4, Informative)
I run a few servers here at home that are web-facing.
I have never found a provider that will accommodate me in any ways that I see fit, so the home solution has won me over every time I go looking.
I host my own work as well as customers. I'm running it all on a Business Class 7Mbit ADSL line... never any problems as most sites are pretty low on bandwidth.
I've recently got a new client (signed and sealed -- working on the project right now, actually). Their project is going to require their own server(s -- Yay redundancy!) for some power behind their project... if all goes well I'm going to lease some office space outside of my home and upgrade the connection to whatever the best is I can get.
The 'at home' solution offers total control. If you're making enough money off your clients, it's worth it in my opinion.
Re:From home? (Score:5, Insightful)
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.
Parent
Re:From home? (Score:5, Insightful)
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.
Parent
Colo versus Managed or Shared hosting (Score:4, Insightful)
I'd say that any instance where you don't fully own/control the hardware (managed servers or shared hosting), that the contract can SAY whatever it wants, but if they want to see your data, they can.
Now, I'm sure most tech support folks have better things to do than to nose through your data or read your email. There is a certain level of trust that you have to give your hosting service, or else it's just not going to work.
It's been my experience that if you want more change / access control in place, you can get it, but it's not going to be cheap. The hosting facility my previous employer used had tech support folks who always asked permission and told us what they were going to do and/or what they did, but that was a $50,000/month hosting contract.
Anyhow, You're going to have to choose... is your privacy more important than having to buy/handle your hardware? if so, then go back to a colo and be prepared for those occasional 4:00am calls. If the support is what's more important, then find a hosting provider where you have some faith in the folks involved. I maintain a very good working relationship with the main support guy where my own server is hosted. I have a lot of faith in him, and I never get redirected to the "Bangalore Bargain Bin" cuz they're not doing that outsourced support thing. To me, this is a comfortable arrangement.
In the end, security versus convenience is always going to be a give-and-take arrangement.
Shifting Laws in Troubled Times (Score:4, Insightful)
Your question should be taken up with a good lawyer. These days things are quite unclear as to what snooping is reasonable.
I am not a lawyer and my opinion is that anyone looking at your files acquires certain legal liability if anything at all is going on through your servers that breaks civil or criminal law. Not looking at files by you or anyone else leaves you with a great deal of legal protection.
Recently I learned that a vague acquaintance was arrested for possession of child pornography as a popular music- file sharing site runs search
programs looking for copyrighted materials and they happened to key in on certain words or images within those porn files.
He may have had some expectation of privacy. I really don't know. But what I do know is that famous site now has a problem if other porn passes through their site and they fail to catch it. Not doing a good enough job carries legal penalties whereas not doing any job at all relieves them of responsibility. Color that spying can be foolish, expensive and dangerous.
Even for dedicated servers, it's hard (Score:4, Insightful)
It's a difficult issue. I have a dedicated server at APlus in Phoenix, and for the first six months, they didn't have any of the passwords for the box. Then they had a big outage and had to move the servers to another data center, and asked the users to tell them the root password so the could shut down the server, move it, and reconfigure the networking. So now they have the root password, and they did use it once without asking me first when I called in with a later problem.
It's not a big issue for this particular application, because it doesn't have any proprietary or personal data and it doesn't do credit card transactions. But for anyone selling something, it could be a very big deal.
This is to some extent a lack of Linux system administration capability. 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. APlus uses the Plesk control panel, which can do most of those things, but its security isn't designed to give the co-location operator a limited login.
Re:Even for dedicated servers, it's hard (Score:5, Insightful)
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.
Parent
sudo can help, but be careful (Score:4, Informative)
Sudo in combination with a script that would modify your network config might work in your case. You'd also want to allow shutdown and reboot.
Parent
Some Customers. . . (Score:3, Insightful)
Some customers will get upset with you if you wait to fix the problem, others will get mad if you don't wait and ask them first. It is a no-win situation.
It's all in the style (Score:4, Insightful)
This strikes me as one of those situations where what actually happened is less important than the company's reaction to your questions. The initial silence, followed by a response from a company official that is not in harmony with their published policy, screams "guilty conscience". They got caught with their hand in the cookie jar (yours, in this case), and they're just hoping you'll shut up and go away. I find myself wondering whether they routinely snoop databases hoping to find information that might be of use to them.
Three recommendations: Encrypt everything that matters if you decide to stay with this company; publish their name, along with a factual account of their actions and links to your documentation; if there is a relevant regulatory body or professional association, send your story to them and ask whether the company's actions and response are reasonable under the circumstances.
Use a smaller hosting company, get better service (Score:4, Insightful)
So, a while back - 2001 according to whois, I registered my personal domain at a small webhost. It was my personal domain, and, as such, not something I was to concerned, where reliability was concerned. Anyway, I picked this place off an ad on kuro5hin (heh, remember them?) and did so based *only* on price. It turned out it was running by one guy. Over the years we exchanged a number of emails and got to know each other by name. Now, I address my support emails directly to him, and I know they're not going to screw with my stuff.
So my advice is this: If you're going to use a webhost, use somewhere small, and take the time to get to know the admins. They'll value you a lot more than some huge conglomerate.
As for legality, look to the terms of use. If they offered you virtual private hosting, well, there's an assumption of privacy. Otherwise, look at that "terms of service" document you most likely clicked right though.
And to give the a quick plug (I neither work there, nor have a financial relationship outside of paying) http://ion-web.com/ [ion-web.com] is pretty good. Feel free to tell them Nick Bernstein recommended them, maybe they give me an even better deal.
Half of you replying are missing the point... (Score:5, Interesting)
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.
Re:bad database (Score:4, Insightful)
I don't buy that 'compromise other users' argument. It might be a shared database SERVER, but every customer should be at least one distinct database user and should get their own database on that server(*)(**). Nobody should be able to see anybody else. If the database server can't handle it, find one that does. If the hosting company doesn't bother giving everyone their own database user accounts, find one that does.
The only reason the hosting company should ever look at the contents of a customer's database is 1) court order or 2) to do transparent optimization to eliminate real performance hits on other users, as permitted by hosting contract. This would cover the case somebody else mentioned where the hosting company added indexes to his database. The hosting company should have kept him informed, though.
(*) you want multiple users so that the owner of the database tables is different from the web app. You might still get hit by SQL injection if you aren't careful, but you won't have some bozo altering your tables.
(**) the exception is if the host provides certain tools to all users, e.g., an interface to a credit card processing engine. In this case the app might have a common backend database, but should still be designed so that one user can't see any other user's data.
So are you under the mistaken impression that because each user has a separate and distinct database and/or database user that that separate and distinct user can't bring down the entire server with crazy tables or poor SQL statements?
I've seen exactly that many times, and often times you have to dig into the separate and distinct database and find out which table if fucking it up for everyone. On a shared server, such as the one in question, with neophytes creating applications, tables and queries, you are going to run into crazy stuff all the time.
Before you say "Just disable that users account/application." Yes, that's all well and good, but then you have other problems to deal with. Either way you are going to be dealing with problems. Some people choose to fix the problem, some people choose to disable the problem. Whatever you personally would choose doesn't matter - this particular company and many like it choose to potentially fix the problem (or think they are fixing the problem), and as such they find it acceptable to access user data. Since it's a legitimate way to go about solving the problem, complaining about it is ridiculous.
If he doesn't like the policy, get a co-lo server and secure the data. Then when something fucks up, you know it's your own fault.
Parent
Expectation of privacy? (Score:3, Informative)
You're hosting on their servers. I don't think you have much expectation of privacy, frankly. I'm all for privacy, and if you own the box, then nobody should be allowed to look at it, but if you're renting the box, just like a landlord, they should have a right to inspect it for whatever reasons. They are, to some degree, responsible for what that box contains.
On a slightly different topic, you say they're pretty good except for... And then you have a list of issues with them. I don't know who your host is, but I'd recommend CrystalTech [crystaltech.com]. I have no affiliation with them other than having hosted some sites with them over the past decade or so. Other than the occasional technical problem, for example an upgrade several years ago that broke one of my apps, or one of the two times in the past 10 years when my e-mail went down, they've been solid as rock. Additionally, when I've needed help, both their online tech support as well as their phone tech support were amazing and responsive. I'll never host with anyone else as long as they continue the way they are.
Re: (Score:3, Informative)
"...just like a landlord, they should have a right to inspect it for whatever reasons."
As someone who's lived in rental properties a good bit, in Philly, Austin and Chicago, let me tell you, this is *BULLSHIT*. Every city ->mandates- that a landlord can *not* come in whenever they want, that they are *required* to give you at least a day's notice.
This prevents large abuses (like walking into your apt when you're female and taking a shower), and small (like the freakin' little old lady, when I was a lot y
first lesson of outsourcing (Score:3, Interesting)
While you can discuss the ethics or morality of having strangers accessing (or worse, changing or "accidentally" destroying it - ooops, there goes another database), the fact is that once it's off your site, it's out of your control.
Wasn't there a case recently of some politician who got their records "snooped" by an outsourced operation - consider yourself lucky that all they're doing is looking. It's not impossible to think that they could take any code you written, or sell off credit card details from your database.
Second law of outsourcing: you're tacitly admitting that someone else can run your operation better/cheaper than you can.
It is irrelevant, and you are overreacting (Score:5, Insightful)
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.)
Shared hosting is for the birds (Score:3, Interesting)
I assume you're using shared hosting. It's a cheap and easy option, but you give up all control of who is on your server, and what they are doing.
I primarily use VPSes for many reasons including this one. It's a great middle ground between colo and shared hosting, where the host is in charge of giving me hardware and network support, and that is all.
There are many good VPS providers out there. I personally prefer XEN based hosts to OS level virt like OpenVZ that powers most of the market.
http://vpslink.com/xen-vps/ [vpslink.com] and http://slicehost.com/ [slicehost.com] are some of the better services I've used, but there's plenty more out there.
How does it look from their end? (Score:3, Informative)
If you brought your computer in to Best Buy and said you couldn't play videos- and the techs there saw your naughty pictures in "Your Documents" you took with your wife (or husband), you'd be feeling similarly embaressed.
You could probably expect that the Geek Squad would not upload your pictures to 4chan. You should also be able to count on your hosting provider to show a similar level of discretion.
However you can't say the Best Buy was violating your privacy- not intentionally, not clearly. It seems what happened with your mysql was likely an accident- I see no reason to believe otherwise, and you don't seem to either- you're just grasping around their privacy policy like it somehow matters.
Re:You're a dumbshit. (Score:5, Funny)
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.
Parent
Re: (Score:3, Funny)
Try to understand: 4chan is down.
Re:You're a dumbshit. (Score:5, Insightful)
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.
Parent
Another way to look at it (Score:4, Insightful)
The agreement with hosting provider would not specifically prohibit them from accessing your data. On the contrary, you should expect them to access your data for the purposes of backups and troubleshooting. In the question above, the support staff accessed the dude's MySQL database in response to his support query. Unless the contract specifically bars them from accessing customer data (which is highly unlikely), they are perfectly within their rights. The situation is the same when you own your own servers and hire a sysadmin to support them. You know he will have full access to your unencrypted data, which means you trust him.
Parent
Re: (Score:3, Insightful)