So, earlier today, DrakNet’s illustrious Brit staff member, Thomas, let me know that mod-security 2 doesn’t support overriding mod-security via .htaccess.

Of course it does, I argued - we’ve been passing out the code for it since we upgraded to Apache 2 and Mod-Security 2 and its been working since last summer. No, it doesn’t, he argued back- and I, of course, argued back that it does. So, we had to get a tie-breaker at Liquid Web, our data center, and 4 system administrators debating the issues later, it appears that in mod-security 2.5, you all no longer have the ability to turn off mod-security protection on your sites yourselves.

There was much wailing and gnashing of teeth.

While from a security perspective on a server, this is a pretty good thing, the fact is on a shared server requiring these changes to be made in server configuration files is a gigantic pain in the keister for your web hosting company. In addition, this flies in the face of the security policies we’ve had and that we advise you to use, which is protect your site 100% and only turn mod-security off when using the administrative area (which is 99% of where ya’ll tend to get caught - this means you, Wordpress widgits).

We hereby dedicate Hot N Cold by Katy Perry to ModSecurity for this change.

This does change how we handle requests regarding Mod-Security problems. Much to our chagrin.

If you are writing in for a mod-security issue, you have a few options and we’ll need a bit more information from you to resolve the issue for you. So, first, what should you send us when you have a mod-security error?

1. What time, approximately, the issue happened.
2. What you were doing at the time. What the link is, the file, and so on.
3. Your IP address.

Hopefully, this will be something simple, like you used a URL as a call and should have used a system path or some simple thing we can advise you to change. If you’re using an out of the box software installation from Fantastico, this issue’s resolution is likely not going to be simple.

If you have an out of the box installation that’s getting tripped up by mod-security, we’ll still need the above information. While its possible we’ll be able to change the rule or exempt the file universally, most often we won’t be able to do that and if that’s the case, you’ll have a few choices.

1. You can request us to exempt your site from the specific rule that’s catching you up.
2. You can request that we exempt a directory from the specific rule that’s catching you up.
3. We can turn off mod-security per directory.
4. We can turn off mod-security for your entire site.

Every time you lower security, you raise your chance of being compromised. The “easy” solution is to just turn it off - and its easy right up until the time you lose your site due to a hack. So, you’ll have some decisions to make if you need this done.

While ideally, we can turn things off and on for you like before, it’s just not practical. We may do it once for you but if this is something that will come up repeatedly, we’ll need to find a permanent solution.

So, this year, DrakNet had a pretty impressive year as far as growth - we added the alakazam server in June of 2008, and it filled up and record time. In December, we changed our prices to get out of the “dirt cheap” market and concentrate on our core market of quality vs. quantity, and so far we’re extremely happy with that decision.

This year also marked the start of our official Kiva lending program. Kiva is the world’s first person-to-person micro-lending website, empowering individuals to lend directly to unique entrepreneurs in the developing world. Though we started in April of 2008, we set a goal of lending to at least one entrepreneur per month. As we look at 2008, we can count 13 entrepreneurs in the third world that we made a direct difference to, one more than our goal.

http://www.kiva.org/lender/draknet

We also managed to garner 915,345 in our World Grid Team project and contributed our unused computer power to projects like AfricanClimate@Home, Discovering Dengue Drugs - Together, FightAIDS@Home, Help Conquer Cancer, Human Proteome Folding 2,  and Nutritious Rice for the World, which made our computers feel quite useful and philanthropic.

As the year comes to a close, we’re hopeful that despite the horrific economic reality that so many are faced with, a new year and a new administration will bring great changes to come that will benefit not just all of us, but the world. Tonight, we at DrakNet celebrate both an end, and a new beginning.

We want to thank you for choosing us for your hosting needs (some of you for over 11 years now), thank you for enabling us to do such cool stuff as a company, host such cool sites as a company, and we look forward to serving your needs for many years to come.

Happy, joyous, peaceful, and prosperous new year to all of you.

Gays, lesbians, and straight allies plan to call in “gay” to volunteer within their local LGBT communities on December 10, 2008 to protest passage of anti-gay constitutional amendments in Arizona, Florida, and California. Wherever possible, gay Americans and allies plan to volunteer for local gay and civil rights organizations across the country through a brand new national database at www.daywithoutagay.wetpaint.com. In addition, a national one day boycott of anti-gay companies will be in effect throughout December 10, 2008.

Every day since Election Day, thousands have protested up and down streets in cities across California, including in Los Angeles, San Diego, San Francisco and Sacramento. A national, grassroots coalition of LGBT activists have followed in their footsteps. Now gay citizens and their allies are teaming up to show America and the world the compassion, the love, and the positive spirit of the gay community through service.

On December 10, 2008 the gay community along with forward-thinking companies will take a historic stance against hatred by donating their time to a variety of different causes in order to raise public awareness of the need for LGBT equality in marriage and in other civil rights.

Starting at midnight Central Standard Time, DrakNet be one of those “forward thinking companies”, and will turn off the phones, chat, and not answer non-emergency tickets for 24 hours in solidarity with our gay friends, family, and clients, nor will any new accounts be installed during that day. We will be monitoring the servers and if there is an emergency, we will have our usual on-the-ball response in place to address any serious issues but all non-emergency questions and issues will be answered the following day.

The past week or so we’ve seen a rash of compromised accounts, more so than we’ve seen at any time in the past. It’s certainly not epidemic, but its more than we really want to see. We wanted to go over best practices (yes, again), and give you an overview of how we tend to handle compromises.

Best Practices

Upgrade. Please upgrade. Please, please, please, please, please upgrade.

No, really. We so, so, so want you to upgrade.

Those software versioning numbers? They actually, honestly mean something - so much so that there is a Wikipedia article written just to explain it it you.  Much of the time, compromises are not found until software has been widely released, and all software on your site is public, open to anyone that feels like trying to get a digital molotov cocktail in there through a window left cracked open.

There seems to be a common misconception that you will know when your site is hacked - that a hacked site will sport a “Ha ha, got you!” page telling you that you’ve been compromised, your stuff will stop functioning. While that does happen, it’s not the most common hack out there in the wild.  Frankly, the hackers that do that are practically doing you a favor, because they’re telling you so you can take steps to fix it. Many hackers feel that this is a noble calling for them, though if you get owned you may find yourself feeling differently.

The hackers you want to guard against are the ones you don’t see - these guys don’t announce it as its not a skills “thing”. They don’t want you to know what they’re doing, and they don’t want us to know, either. They want your site to stay up and running for as long as possible, so they can send spam through your site, or have people fill out a phishing form, or they can poke around trying to get everyone else’s information on the server. Stealth is key to carrying out these kinds of hacks, and many times you can be totally compromised with nefarious baddies using your site as a playground and you won’t know.

So, how do you keep them from targeting you in the first place?

Well, you can’t. You’re on the Net. That’s the reality - you’re a target. If there is a hole in your site, they will look for it. Everything you decide to do with your site should have that in mind.

So, how to you keep from cracking that window?

1. Be Selective with the Scripts you install - half the time, you let them in yourself. Just like someone handing you a bag at the airport isn’t a good idea to take, there are scripts floating around out there saying they do one thing, and doing another. If it’s a Wordpress Theme or plugin and not on the Wordpress site where the listing is free, stop and wonder why its not. Is the software active? Is it being updated? Does the site look like software developers that take things seriously, or does it have that spammy feel? Was the last release in 2006?
2. Keep your software updated! - If your software is actively maintained by decent developers, the developers will address security issues. Google the software name and “vulnerability” - chances are you’ll find something. You can use that info to see how quickly an update was released and an issue addressed so that you know as far as you can tell whether something is well maintained - but an update being released is meaningless to you if you don’t upgrade your software. This is a serious issue here at DrakNet, and can be a terminable offense.
3. If you disable security, realize you’re asking for it - Mod-security and our PHP settings are instrumental in our ability to protect you against your own worst instincts to use bad code, not update your scripts, and transform a site’s original code into something you want when you aren’t a developer and aren’t wholly sure what the heck you are doing. Yes, we let you override - we expect that when you override you know the potential consequences, and that you accept them and are prepared for them, which brings us to…
4. Backup Your Stuff - A backup is the only fool proof method to be completely secure against recovery from compromises, far enough back that the site is secure. If your site is compromised and allowed to run with it, they potentially will be useless, but most of the time they save your site and save you hours of work. You can utilize the Backup feature in cPanel to take complete website backups of your account settings, files, emails, databases, etc. Keep them. We maintain only a weekly, and a monthly. If you’re compromised a month or two ago, you’re looking at a site nuke.

OK, you’re hacked. Now what?

If we find it, you’ll be suspended, instantly. We will not call you to discuss the situation, we will not conference to debate what to do, we will not send you an email asking if its ok to take you off line. We will lock down the script and/or the entire site if there is any suspicion that the hack went farther, immediately. We cannot continue to allow sites that are:

1. spamming
2. phishing
3. hacking
4. serving viruses
5. serving malicious software
6. out of the direct control of the authorized admin

to continue to blissfully function on a server we control. If you put our machine at risk in any way, shape, or form from malicious activity, we will shut you down. Yes, even if its “not your fault” because, folks, just because you didn’t choose to do it doesn’t mean that the real world consequences of what’s going on are simply suspended due to your non-active role in the malicious activity. The rest of the clients who share the box with you are still at risk, and your site simply will not be allowed to put their services at risk.

Once your script is locked or your site is suspended, we’ll send you an email, letting you know about it. From there, you have a few choices:

1. We can completely delete your install, install you fresh, and you can start over. Before anyone screams that this is grossly unfair, I’d like to remind you that this is what we do if a server is compromised, and its no fun for us, either. If our server is hacked, the only foolproof way we have to secure it is to rebuild it from the ground up, and so that’s what we do. So, we’re not giving you an option without being aware of (a) what an unmitigated pain in the keister it is or (b) without being willing to do this ourselves on a much grander scale.
2. If you know enough to secure it, and we are reasonably sure it is related to a script only (and you’re reasonably sure you can track it down and remove all of the offending code and fix all underlying security vulnerabilities before putting your site back online), we can unlock most of the domain while keeping the site offline for everyone but you based on your IP so that you can upgrade and patch what needs to be upgraded and patched or reinstall things so they are secure. You can also hire an admin company to do the same type of thing.
3. You can pay us to secure the site, and rebuild what we can, with no guarantees regarding what we will be able to salvage, for $75 an hour.

Shared hosting is managed around your site. We control the building and the utilities - however, if you set the office we rented you on fire after pouring gasoline on the floor and lighting a candle, the cleanup is not included as part of your hosting fees, especially when your security practices go outside of the recommended security practices.

Taking your site offline is not meant as punishment - it is done not only to protect our other clients, but also in order to keep from putting your site’s visitors and your customers at risk.

If you find that you’re hacked first, finding and removing a specific block of bad code that a hacker has inserted can clean your site for a time, but keeping your site from being infected in the future will require fixing the security vulnerabilities that allowed the hacker to insert the code in the first place.

So, months ago a client told us that we really needed to be on Twitter. Since I can’t text on my phone to save my life, I didn’t really see the point but I thought I’d give it a whirl as apparently all the cool web hosts were doing it. Despite initially having set it up as a business tool, I soon found myself addicted to the constant stream of nonsense and profound-ness. You really haven’t watched a Presidential Debate until you’ve done so while bombarding Twitter with observations while seeing others reactions in real time.

It wasn’t, though, what I had intended it to be, and so I changed my Twitter name (you can follow me personally @jendraknet - I’ll let the other staff post their Twitter names in the comments if they feel like being followed), gave the @draknet name back to the company itself, and have programmed both this blog and the network status blog to post a tweet with a link when we update with news. This will not be a chatty Twitter account (though we will follow back), but will get you alerts to news, policy changes, and issues without your having to check the blog (or for those of you that don’t have a feed reader).

Which brings us to the next topic… we found ourselves on the phone the other day with someone who was adament that it was our responsibility to ensure that folks knew about policy and server changes by email as well, because checking the blogs and/or the forums was just not something this person was interested in.

While we’re a bunch of civil liberty fans here and are all for people making their own choices about what they’re interested in and not, we want to take this time to remind everyone very gently that we provide copious amounts of pointers to where you can find the news. It is entirely up to you whether you pay attention to it, whether you care, and whether you keep up. We fully support your right to totally ignore us other than when things break. That’s your right.

Please keep in mind that if you choose to do that, you’re not going to find a plethora of comforting sympathy when you call us up screaming that your default catch-all email account doesn’t work when we stopped allowing them nearly two years ago. I was an English Major in college, folks, and the only time I get to use that collegiate knowledge is writing copious amounts of documentation, news updates, and explanations to you all. I like to do it, it makes me feel all that money for my education wasn’t wasted since I wound up in IT - so, I tend to be rather long-winded, and I like to write up every little thing.

I can promise almost anyone that chooses to become crossways with us that we did announce this change somewhere, whether it was on the old DrakChat list, in an email newsletter (when we did them), in the blog, or in cPanel itself. We do ask that you make an effort to keep up.

If you don’t, again, that’s ok - but we do ask that you not state we didn’t tell you when we actually did tell everyone, and you just decided that you didn’t want to keep up with the info.

We’ve tried to make it easy for you by porting it into the blog - if you just want to follow catastrophes, you can follow the Network Status Page. If you want to know what changes we’re making and what we’re doing, you can follow this one. If you only want the actual news that affects your site and changes we make, you can follow just the news. If you don’t want to come to the site, you can get the info in a feedreader or now on Twitter. If you want the News in email, you can subscribe to a service like http://www.rssfwd.com/ and they will email you the feed just the way the old newsletters came.

In short, like Burger King, you can really have the news your way, so we ask that you keep up with it if you feel that changes in your service are potentially a big deal. If it’s not, that’s ok - but if changes are something that you feel you should know about, you need to take the steps to set it up so that you make sure that you do.

As much as we’d love to call all 2,000 of you on the phone… um, we can’t.

We first want to wish everyone a Happy Thanksgiving, we hope that you enjoyed your holiday, and for those of you that did not get Rickrolled along with the rest of the U.S. this morning, allow us to welcome you to the fold by giving you this link.

So, consider yourself Rickrolled by DrakNet, via Cartoon Network and the epic Rickroll they pulled today on an unsuspecting America. Nicely done, folks.

You’ll notice some changes on the DrakNet site - we have decided to retire the Intro Account, the Junior Account, the Drake Account, and the Whistles account on the shared hosting side, and have pared the Reseller Account levels down to 3 (now named the Designer, the Developer, and the Pro). Those who currently have and utilize the retired accounts can continue to keep them as legacy accounts for as long as they wish, and there will be no current client or current package price raise or allotment change at all.

All new installs and new accounts will be limited to the current offerings that are available on the order forms and that are outlined on the site, as will upgrades and downgrades.

DrakNet has been growing at a fairly fearsome rate for us:

And while we’ve been happy to see it, the fact is that the reason people choose us vs. the WalMart-style web hosting companies is due to our expertise and offerings, things that seem to make people feel we’re fairly unique. In addition, we have had huge growth with the Soholaunch segment of our hosting service, especially in the area of developers and resellers. As far as we are aware, we are the only web hosting company anywhere offering both free Soholaunch Licenses for Reseller clients as well as direct support of the Soholaunch product itself in all aspects other than design.

We’ve often been told that we’re far too cheap for what we provide - and, well, we’re starting to agree with everyone who tells us that. That’s why we’ve chosen to pare down the offerings to only three accounts as well as do away with the two cheapest accounts that essentially became revenue-neutral due to the higher levels of support we provide for Soholaunch.

We also, frankly, don’t want to outgrow our ability to provide the service people expect from us, and I can see that potentially happening as growth continues to accelerate. This is the decision we have made to pull the reigns up on that runaway growth, as well as ensure there is adequate revenue to pay for higher quality solutions that we are seeking to implement but which just aren’t justified when you look at the margins on the cheaper accounts.

We don’t offer a run of the mill hosting experience, and we do work very hard to ensure that the servers are not crowded, slow, slammed, and so on. We simply feel this pricing scheme better reflects the quality of an experience with us vs. the quality of an experience at a McHosting Company.

We have upgraded all servers to cPanel 11.24, or “cPanel Accelerated“, which should be a souped up yet slimmer version of cPanel. Likely, you personally won’t see much of a difference though you resellers will see some added branding options.

The good news is Accelerated has implemented many security fixes that are default on current out of the box software installations that cPanel gathers into one package, as well as addressed cPanel’s woefully late but finally here response to PCI Certification, something many of you merchants are clamoring to get before the deadline passes and you start to be fined.

(We know how you feel, we put it off as long as we could, too.)

The good news is that all servers should now pass a PCI Compliance scan, with some caveats. You’ll need to let us know your PCI Compliance company’s IP range so that we can exempt them from the firewall on the Apache port only. PCI Scans throw so many holes and exploits at the server that we inevitably wind up firewalling them, which is good for the security of your site - but not so good when they want to fully see how your web site responds to those attacks and where the holes are.

Please try and let us know when they’re coming beforehand so we can make sure that they can do and see what they need to do for you to pass. You’ll only need to do this the first time, as we’ll keep the range in there. If you want a company that we work with, we can guarantee that you’ll pass Security Metrics scan, as we did on the same servers and we already have their IPs.

The bad news? Well, it’s not bad, really, and this won’t affect the vast majority of you, but we have turned off the ability to include executables in SSI. The exec command executes a given shell command or CGI script, and as you can imagine, this is an incredibly exploitable aspect of your web site and we watch people hammer the server all day trying to shove them in there. We swat most of them away with mod-security.

After years of running with no sites ever being exploited on these servers, though, we have seen a recent rash of exploits from poorly coded CGI scripts, and we’re not going to allow it anymore by default. If you see:

[Mon Nov 10 19:11:03 2008] [error] [client XX.XX.XX.XX] unable to include potential exec “/script/here.cgi” in parsed file “/another/file.html”

You are trying to include an executable, and that’s no longer allowed just out of the box on everybody. You also need to turn on cgi scripts if you use them just to be safe.

In geekspeak IncludesNOEXEC is now the default, or more specifically, mod_include allows execution of CGIs and external commands using Server Side Includes and they are now disabled by default by the Options -IncludesNoExec directive.

Before you begin hyperventilating and wonder where you’ll get the time to recode your site, we do allow overrides, so you can take our security and turn it on its ear by creating an .htaccess file with the options you wish to have and blow your site wide open if that’s what you feel like doing.

If you wish to use a .htaccess file to permit the execution of CGI programs in a particular directory, you will need to create an .htaccess file that adds the executable option to that directory.

Options +ExecCGI

AddHandler cgi-script .cgi .pl

If you wish to use a .htaccess file to permit the execution of and including of CGI programs in a particular directory, you will need to create an .htaccess file that adds “Includes” to the Options (overriding the IncludesNoExec that exists by default).

Options +Includes +ExecCGI

AddHandler cgi-script .cgi .pl

Our current settings are:

-ExecCGI -FollowSymLinks Includes IncludesNOEXEC -Indexes -MultiViews SymLinksIfOwnerMatch

any of which you may override.

Just please remember that if you are deliberately turning off our security, if you are not keeping your scripts updated, if you disable the things meant to protect you and you wind up getting hacked, we’re going to suspend you outright should you get exploited. We can’t afford to do security consulting for $5 or $10 a month and the most we’ll do is install an older backup and tell you to fix your stuff. You’ll need to convince us that if we turn you back on, you’ll be able to secure your scripts and if you can’t, we will terminate the account, so please realize your responsibility in trying your hardest to keep your site secured is considered sacrosanct here.

We take our job to secure your sites very seriously - we expect you to do the same for our servers and out of respect for your neighbors.

We usually get only a small bit of information on the results of the Kiva loans that we make. In September, an essay was published on the Huffington Post outlining what a microloan did for Yenku Sesay, a Kiva loan recipient in Sierra Leona. A snippet of the essay “From Machete To Microfinance: A Double Amputee’s Recovery” by Nicholas Sabin is below, with a link to the rest of the article.

Yenku Sesay looks down where his hands used to be. He answers my question with a sickening quickness: “1998. May 6. 10am.” That was when the rebel army, led by the Revolutionary United Front (RUF), invaded Yenku’s village of Kondembaya in northern Sierra Leone and took him prisoner. The rebels burned the village and gathered the civilians under the central cotton tree.

This was one of the places where the RUF began its practice of amputation on civilians during the 11-year civil war in Sierra Leone. The RUF reasoning behind the amputations was that civilians had used their hands to vote for a corrupt president and they did not deserve to keep these appendages. Yenku pleaded with the rebels not to cut off his hands. But the rebels took a certain enjoyment from the process. Each prisoner was pushed forward for his or her punishment and had to choose slips of paper in a gruesome lottery. The paper either said “short sleeve” or “long sleeve.” Yenku pulled two long sleeves. His hands were severed with a machete, first the left, then the right.

Many of the victims did not survive. Yenku would likely have soon died if his father had not taken decisive action. Yenku’s father used the family savings to hire a motorbike to take Yenku for treatment in a hospital hours away in the country’s capital city, Freetown. Though Yenku eventually recovered from the physical wounds, his life was destroyed. He was incapable of taking care of himself and eventually resorted to begging in the streets of Sierra Leone. At about 21 years old, Yenku’s daily life had been reduced to asking for handouts, with little hope of change, little chance for something better.

Were it not for a microloan, Yenku is sure that he would still be begging today. In 2006, Salone Microfinance Trust (SMT) approached Yenku about taking out a group loan with four other local borrowers. No other institutions were even willing to consider Yenku for credit because of his amputee status. However, through lengthy discussions with Yenku, SMT saw in Yenku natural business skills and a drive to be self-reliant. He was approved for 300,000 Leones from SMT, the equivalent of approximately $100 USD. Yenku used this money to develop a modest retail business. At first the business was no more than Yenku selling small items in the street, such as packaged biscuits, soaps, and other sundries. Over the past two years, by reinvesting the profits and building his credit with SMT, Yenku’s business has grown to become a small shop selling an assortment of clothing, shoes, drinks, and other packaged food products. Though his shop may be considered small by US standards, the difference it has made in Yenku’s life is dramatic.

Read the rest of the article here: http://www.huffingtonpost.com/nicholas-sabin/from-machete-to-microfina_b_124727.html

Today, we made a group loan to a banking group in Cambodia:

Mrs. Chhorn Chhoeurn’s Village Bank consists of seventeen members living in Peareach Village in Kampong Chhnang Province. Each member will use their loan for different purposes. Mrs. Chhorn Chhoeurn is the president of the bank and leader of this loan group.  She is 24 years old and the mother of two children who both attend the local school.  Mrs. Chhorn Chhoeurn owns a small plot land where she can cultivate rice for a living. Her husband, Mr. Chor Vy, has a small kiln in which he can produce coal to sell. In this business, he now faces a small obstacle because he cannot transport wood in order to make coal. Thus, his wife, Mrs. Chhorn Chhoeurn, decided to ask for a loan to buy a cow cart to help with transport.

This is a village bank loan consisting of mainly end-of-term loans. Nine members have end-of-term loans and the rest have monthly payment loans. Group members are not required to pay any principal on the loan until the very end of the loan term. End-of-term (EoT) loans are AMK’s main product because it is the most beneficial to Cambodia’s poor. It allows them to repay portions of the principal whenever they are financially able to do so. Most clients start to make payments many months before the end of the loan term. Almost all of AMK’s clients make their payments on time. AMK has a delinquency rate of only 0.09% and AMK has a default rate of 0% on Kiva.

You can always view all our microloans on our Kiva Lending Page.

Since we’ve done this with every natural disaster, we wanted to just post this new unofficial/official policy for everyone’s information - especially since we’ve had a few people contact us who were worried about their web site during a time that we feel people shouldn’t be worrying about their web site.

Any shared hosting/non-reseller clients directly affected by Hurricane Ike who have concerns that, monetarily, they will not have payments to spare whether due to job loss, home loss, displacement, and so on to pay for their hosting can submit a ticket to the Billing department and request the “Hurricane Ike” credit.

We are giving those affected who have financial difficulties brought about by this natural disaster a 6 month credit on their services which, hopefully, will be enough time to get back on their feet.

Please note that your address has to be registered in the affected area. We’re not going to drive down there and make sure your house is really decimated, but we do expect that people who need it will utilize it and people that don’t need it will make sure its there for the people that do.

Since this likely won’t be the last natural disaster to befall our clients, please just assume this is an open ended policy regardless of the particular disaster or location, and always contact us if you’re concerned that a natural sudden disaster puts you in a position where immediate need trumps net geekdom.

If you have any questions, please let us know.

We got a call an hour or so ago regarding the blog of one of our long term clients and decided to turn this into a “teachable moment” for everyone.

Seems that Trae was unnerved by a spell farm advertising on his site, and wrote up this post and this post sharing with his readers what he had found on the site (which certainly seemed like a fairly expensive scam, especially with the directive to send a blank money order not made out to anyone) and exposing the identity of the owner and other past associated possible scams based on the PayPal email address and using patient google-fu.

The person stated she was the person in question that had been exposed on the blog and wanted us, as the host, to remove her personal information from Trae’s web site as she didn’t give him permission to publish it. She stated that she had been told by an attorney to call us to have the information removed. We politely refused.

It does bring up some misconceptions regarding what web hosting companies can do, are required to do, what we can’t do and what we have discretion to do.

When it is non-negotiable.

One thing we all have to do is uphold the DMCA. The Digital Millennium Copyright Act of 1998, in simple English, requires us to remove access to material when someone else asserts a copyright infringement complaint. It has to be signed, it has to say certain things, but if it complies with the law we have to take the material down, lock it, or otherwise make it unavailable.

While this seems like an easy way for people to harass people on web sites that they don’t like, the fact is that the owner of the site that’s been edited can simply file a counter-notification and as long as it is signed and says certain things, the material goes back up. From there, it’s up to the person filing the original notice to go get a court order from a Judge.

The DMCA doesn’t expect web hosting companies or information publishers to be lawyers - or Judges. That’s part of why they make it so easy - do a, b, and c, and the information will be taken down. Most people don’t file a counter-notification, and usually the complaint and withdrawing of the information tends to be the end of it.

There are only a few situations where we are going to take action almost immediately to nuke a site or remove information based on an outside complaint.

• A DMCA complaint. We have to, or we become liable ourselves. Realize, though, we share DMCA complaints with the people complained about, so if you think about using a web hosting company to mess with someone you don’t like and making an untrue complaint is a good idea, think again. If you misuse the DMCA you can be sued and held liable for damages and attorney fees.
• Complaints from software providers for people using unlicensed software - someone sold you that VBulletin license for $5 and you thought it was legit? Tough.
• Reported violations of our TOS (your site spammed, your site has a phishing page, and so on)
• sites that are clearly criminal in nature - child porn, murder for hire, a shopping cart selling pot. That sort of thing.

The situation with Trae’s site isn’t so clear cut because it deals with possible defamation, and possible invasion of privacy.

Defamation, Invasion of Privacy and Liability - who’s got it?

There are laws covering the publication of private facts - the Citizen Media Law Project has a fantastic write up on things to consider before publishing private facts about anyone, when it is acceptable, and when it’s not. Since Trae has a blog and the exposing of someone who has been written up as a rip off artist on Rip Off Report could be considered newsworthy, publishing information identifying Ms. Reynolds could be considered justifiable in this instance since those scammed would have no recourse, as the identity of those running the site were hidden.

Notice there are a lot of “coulds” in what I wrote up - the reason that there are a lot of “could be” is that we are not lawyers, and we are not Judges.

First, he didn’t post the home information of his subject, one of his commentators did. The same thing that protects us for what he publishes also protects him from what his commentators publishes - he has no way to Judge the veracity of what was published, or whether it came from public records. The Communications Decency Act leaves Trae, and DrakNet, not liable for what the anonymous commentator posted even if it was defamatory.

While some of the CDA has been struck down over the course of legal challenge after legal challenge, Section 230 has remained, and it states:

No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.

What this means is that what Trae says on his blog (or any of the rest of you, for that matter) is not something that DrakNet can be held liable for because we don’t screen his information before he publishes. What someone who comments on Trae’s blog says is also not something that he can be held liable for. Everyone is responsible for what they say on the Internet, and it doesn’t matter where they say it - someone making a comment on this blog doesn’t make me liable for it anymore than someone writing a nasty email to someone from their gmail account makes Google liable for it.

So, what should you expect when you tattle on a web site operator to their web hosting company? Well, unless you’re filing a DMCA complaint or the issue is legally black and white with no grey area, not a whole heck of a lot.

Electing the host to be a Judge

If we have to make a judgment call, or determine something as interpretive as “newsworthiness” like in the situation above - well, we can’t. That’s not our job. For example, in the above scenario that came up today, I have no ability to determine whether what Trae reported is newsworthy, whether he was right or not to publish the information, or whether the commentator got his information through public records. That’s something that would need to be determined by a Judge, and so seeking relief from the web hosting company in a case like this is relatively futile.

Our job is to host web sites, fulfill the contracts we have with our clients, and comply with the law while doing so. Until a court order says that Trae’s commenter should not have published the information and it should be taken down, or that Trae’s post is defamatory and should be taken down, we have absolutely no ability to help anyone that feels they have been “defamed” - we don’t have the legal ability to judge what defamation is. That’s why there are courts and Judges.

So, how do you deal with this should it happen to you?

Write the web site operator and ask that the information be taken down - in this case, Ms. Reynolds contact us before ever contacting Trae, which we found out when we contacted Trae to inform him of the contact by Ms. Reynolds. You severely undermine your own credibility when you don’t even contact the person that posted first and just go straight to the web hosting company.

Second, get an attorney if the above doesn’t work- if the web site operator refuses, that’s where the situation needs to go, into a court of law. You need to get an attorney who will make contact with the operator and try and get the situation worked out or who will, if it can’t be worked out, know how to file a suit to have the situation put before a Judge in the correct jurisdiction. Once you get an injunction specifically directing that the information needs to be removed, fax it to us.

Third, and this is just my personal pet peeve - don’t call up a hosting company and claim a lawyer told you to call us.

We’re, first of all, not stupid and second of all, it certainly doesn’t scare us. Anyone who’s been in this business has been through these before (DrakNet has had the privilege of having clients in the cross hairs of both the RIAA and the Church of Scientology!), and anyone who’s been around long enough doesn’t jump at the word attorney anymore, if they ever did - these things are handled, even with lawyers involved, in a fairly calm and businesslike manner and they almost always follow a particular pattern, which has never included the alleged defamed calling us on the phone.

If you call up any hosting company swearing you have an attorney and he told you (a) (b) and (c) while threatening that hosting company over the phone over a client of theirs, you will produce no more than vague amusement and, perhaps, some advice. Especially when the legalities you state are wrong.

Just don’t make up non-existent attorneys. Please. It’s overdone already.

What can you do if its your site that’s being complained about?

First, don’t assume you’re in the right - spend $100 or $200 and consult with an attorney regarding what your liability could be and decided to what extent you want to defend your principles in the face of what could happen if you’re wrong. Make an informed decision, and take your responsibilities as an Internet publisher or blogger seriously. Realize the Internet is chock full of lawsuits over information published and simply because you do it in your bathrobe doesn’t make you immune.

Second, let us know if someone’s freaking out over a post you wrote - the cheapo attorney and court bypass is often hacking for punishment, and our concern is the servers. If you know that someone is irate about what you posted, inform us of the situation so that we can watch your site closely for changes as well as log activity in case there is a retaliatory hacking attempt.

Third, keep us in the loop if the site does get legally attacked so that we can help you comply with any court orders and injunctions quickly.

And finally, realize that NONE of this is legal advice which is, basically, the point of the article. If you have legal issues over your site (or a site that wrote about you) that are subjective and interpretive regarding defamation violations, get a real attorney, and don’t contact web hosting companies expecting them to give you a pass and play Judge so you don’t have to do it the right way.

Yes, a hosting company has latitude in how it handles complaints and many may just drop clients so they don’t have to deal with the hassle regardless of fault - this one, however, doesn’t happen to be one of those.