Quite a few of our customers are still using FrontPage to design and upload their Web sites, though. We’re starting to see more and more problems from customers who have upgraded to a new computer running Windows Vista or Windows 7 but can no longer run FrontPage. (Sometimes their old computer just suddenly crashes and can’t be recovered.) Their old computer probably had a copy of FrontPage installed by the manufacturer, but their new computer doesn’t.

It can be difficult or impossible to get FrontPage running on a new PC if you can’t find the original installation CDs, or you aren’t licensed to use FrontPage on the new PC. In some cases, the old FrontPage software doesn’t install or work well on the latest versions of Windows. In these situations, you can’t even open the old FrontPage files on the new computer.

If you are still using FrontPage, you should start planning for when you are going to move to a different program. You might want to move to Microsoft’s newer program, Expression Web. Or you might want to join the large number of people using Dreamweaver. If you’re looking for a free program, you might want to try Nvu. The popular (and free!) WordPress can be a good choice, too — it’s commonly known as a “blog program”, but you can also use it to create a Web site with normal pages.

We strongly encourage existing FrontPage users to start planning their move to a different program. If you don’t plan the move yourself on your own schedule, you may find yourself stuck in a situation where you’re no longer able to edit your site using the old FrontPage software.

We thought the recent 2-hour movies were OK if a little, um, “uneven.” But we have high hopes (“higher than sugar cane growing on Mount Everest”) that the Futurama team will hit their stride and churn out some great episodes.

The fun starts with two back-to-back episodes tomorrow night (Thursday) at 10pm on Comedy Central. Set your TiVo’s!

By default, each WordPress blog is configured to send the login username and password as plain (unencrypted) text. If a hacker can see what you are sending during your login, they can easily steal your username and password. This can happen if you have a virus installed on your computer. It can also happen if your computer is virus-free but connects via WiFi. If your main computer uses a wireless connection, or if you or other users of your blog ever login with their laptops — blogging from a coffee shop, anyone? — remember that these connections can be insecure, and could be susceptible to revealing your password.

You can protect your blog by installing an “SSL certificate” and configuring WordPress to require secure logins. Your browser will then encrypt your username and password so that no one can intercept them.

Traditionally, only online stores used SSL certificates because they were very expensive. But SSL certificate prices have dropped quite a bit recently, and they’re now low enough that we think SSL certificates should be widely used to protect all logins and other sensitive data.

If you are a Tiger Technologies customer, you can get an SSL certificate for a great price. (One type of certificate, a “self-signed certificate”, is even free if you’re already on our Gold or Platinum hosting plans.) If you’re not a Tiger Technologies customer, you can search for companies selling SSL certificates or search for free self-signed certificates.

Configuring WordPress

Once you have an SSL certificate installed on your site, it’s easy to configure WordPress to use secure logins. Simply add this line anywhere to your wp-config.php file (after the opening “<?php” line):

define('FORCE_SSL_ADMIN', true);

This will ensure that your username and password are submitted to WordPress securely; all of your subsequent work (creating posts, etc) will be secure as well. You’ll see your Web browser’s “padlock” icon when you are using a secure connection. The WordPress “Administration Over SSL” page has more details.

Worse, some companies don’t even offer phone support at all. Have you ever tried to call Google for GMail tech support? Or find a way to send them an e-mail for assistance?

Tiger Technologies offers support via Web pages, e-mail and telephone. While most of our customers find what they need on our Web site or by e-mail, we’re also proud to offer high-quality, free phone support from our own employees (not an outsourced call center) Monday–Friday, 9am–5pm (Pacific time), at (510) 527-3131. You’ll almost always be quickly connected to someone who can help you.

By the way, our support pages are the quickest way to answer most questions. We have over 500 topics covering all aspects of our service, from common “how do I get started” questions to tips on fixing obscure problems. Just type a word or phrase into the “Search” box at the top of any page on our Web site, then click the Search button. With our support pages, you’ll get an immediate answer to your question and you can read the page at your own pace, or come back to it later for future reference.

If you can’t find the answer on our support pages, you’ll find our e-mail support to be among the best in the business. Our support contact page has our support e-mail address and an online form you can use if preferred.

But sometimes you need phone support, of course — and when you do, we’ve got you covered.

Several shared hosting companies apparently allow customers to view the text of other customer’s files by default, and that allows malicious customers to discover the database password of another site (from the “wp-config.php” file) and alter the site.

Some security researchers think this is a WordPress flaw, but we agree with the WordPress folks that that’s nonsense. The real problem is that these hosting companies are allowing customers to view each other’s files, which shows a reckless disregard for security.

For the record, this kind of attack is impossible on our servers. We prevent customers from viewing each other’s files. In particular, we use suEXEC to run each user’s scripts under a separate Unix user ID, and we ensure that your files are protected from other users at the file system level.

In fact, we go a step further than even most reasonably secure companies: we protect your files even if you change every possible file and directory to be world-writable (mode 777), using an additional layer of Linux “access control list” rules on your top-level directories. We also automatically reset the bad directory permissions for you, just to be sure there are always two levels of protection.

So you don’t need to worry about this kind of attack; “we’ve got your back”.

A different attack on wp-config.php

Separately and coincidentally, our security systems detected a different type of attack on a “wp-config.php” file today. Some “hackers” on the Internet are trying to load files named “wp-config.php~” with a tilde character at the end. In most cases, that file won’t exist, but if you’ve edited your “wp-config.php” file with some text editors, it creates a “wp-config.php~” version as a backup copy.

This is an interesting attack. Of course, it’s not possible to load this file in a Web browser and see the source:

http://example.com/wp-config.php

However, it is possible to see the source of this file if it exists:

http://example.com/wp-config.php~

That’s because the server doesn’t recognize that the “.php~” file contains PHP code, so it shows the visitor the contents (source) of the file, with disastrous results.

We’ve fixed this potential attack by blocking all requests for filenames ending in “.php~” on our servers, since it appears that nobody is using this legitimately.

If you run your own Web servers, this simple mod_security rule will do the trick:

SecRule REQUEST_FILENAME "\.php~$" "msg:'PHP file backup exploit',deny,status:412,auditlog"

(Just so it’s clear, we’ve already done this for our customers; that rule is mentioned in the hope that it might be useful to someone else. We also mentioned this issue on the WordPress support forums.)

These “invoices” are a scam. Domain Registry of America is unrelated to our company, and has been cited by the FTC for “deceptive conduct”.

If you look closely at the “invoices”, they actually say something like “This notice is not a bill, rather an easy means of payment should you decide to renew your domain with us.” However, that small print is easy to miss.

We have a page about Domain Registry of America scams with much more information. We encourage you to make sure that whoever pays your invoices is aware of it.

If you care about the performance of your site, please stick with WP Super Cache unless you have a very good reason to switch. It works, and it works well.

Some people tell us that W3 Total Cache works just as well if it’s properly configured, and they may well be right — but it seems like it’s difficult to configure properly. Our experience is showing that it’s easy to get wrong, and performance ends up suffering. WP Super Cache makes it easy to get great performance.

But recently we’ve seen a number of our customers getting hammered by a ton of requests from FeedBurner. Usually the request is of this form:

/somepost?utm_source=feedburner&utm_medium=feed&utm_campaign=SomeCampaignString

We’ve also seen FeedBurner going crazy and making thousands of duplicate requests. One of the sites we host has gotten 45,000 simple status requests (HTTP “HEAD” requests) from FeedBurner today, for no good reason that we can see.

Unfortunately, the default rules of WP Super Cache prevent it from caching any request with a query that contains an equal sign. So all of these requests are being unnecessarily run freshly each time, rather than being served from the cache.

There’s an easy fix to this. Open your Web site’s .htaccess file. Look for the section of lines for WP Super Cache, and find the line which tests %{QUERY_STRING}. Insert this new line of text immediately above the existing line:

RewriteCond %{QUERY_STRING} ^utm_source=(feedburner|twitterfeed) [OR]

The new line (ending with [OR]) must come before the existing %{QUERY_STRING} line. After inserting, the two lines should look exactly like this:

RewriteCond %{QUERY_STRING} ^utm_source=(feedburner|twitterfeed) [OR]
RewriteCond %{QUERY_STRING} !.*=.*

There are two very similar blocks right next to each other in the .htaccess file. Be sure to add the new line to the same place in each block.

That’s the only change you’ll have to make! WP Super Cache will now be able to cache requests for normal pages that come from FeedBurner or Twitterfeed. If your Web site was being abused by FeedBurner (or Twitterfeed), you should see a definite improvement.

There’s an obvious potential conflict-of-interest here. An unscrupulous company could easily make more money by rejecting the transfer and forcing the domain name owner to renew it there instead.

Fortunately, this shouldn’t be a problem. ICANN, the organization that controls domain name policy, requires registrars to follow some very specific rules about transfers (here, with an update here). They list nine specific situations in which a transfer can be rejected, explicitly banning other reasons.

For the most part, this prevents arbitrary rejections. However, there are a few registrars that continue to violate the rules. We’ve complained (again and again) to ICANN about this, but they don’t seem interested, so I’ll mention a few problems here.

Register.com is one frustrating company. The ICANN policy clearly prohibits blocking a transfer of a domain name that has expired but not yet been deleted. Despite that, a customer trying to transfer a three-day-expired Register.com domain name told us last week that they flat out refused to give him the necessary code to allow him to transfer — unless he pays them to renew it first. That isn’t the first time we’ve heard this, either.

GoDaddy (and their reseller arm, Wild West Domains) have a different problem. They still block transfers for 60 days after a registrant contact update, even after the ICANN update specifically prohibited doing so. They freely admit it, too. GoDaddy’s Disputes Manager recently told us that blocking transfers for this reason is okay because “It is not necessary to update registrant information in order to transfer a domain name”. That’s irrelevant, of course; domain name owners are legally required to update registrant information whenever it becomes inaccurate, as ICANN’s update makes clear. GoDaddy can’t legitimately block transfers just because someone followed the legal requirement to update their contact information.

We see a similar problem with many transfers from Network Solutions. They often tell their customers that they’ve rejected the transfer “due to potentially suspicious activity in your account”. When customers ask for details, they’re told that the only “suspicious activity” was a recent contact update. Again, this is exactly what the policy prohibits.

GoDaddy and Network Solutions claim they’re protecting registrants by implementing these security measures, as if a recent contact update is a reliable sign of malicious activity. But many registrants update all their contact information just before they transfer their domain name to make sure the transfer approval notices reach their current address. They just don’t think about until then. It’s perfectly normal.

In addition, the “security measures” probably don’t work anyway. Surely by now any competent domain name thief knows not to update the registrant contact until after they’ve transferred the domain name to another registrar, thus bypassing the “security” completely.

While the GoDaddy and NSI efforts almost certainly have blocked some fraudulent transfers, so would a rule saying “you can’t transfer domain names during months that contain an R”. What really matters is how many legitimate transfers are also blocked. We’ve been on the receiving end of many blocked transfers, and we always try to push the other registrar to provide details about the “security problem” — I’ve spent literally days of my time doing this over the last two years. In every single case, the attempted transfer has turned out to be legitimate.

If GoDaddy and NSI wanted to prove they were protecting registrants, they could share some statistics about how many of the blocked transfers eventually get completed later anyway, vs. how many of the blocked transfers result in complaints or actions by registrants to block future transfers (such as authorization code changes) . We’re pretty sure the former vastly outweighs the latter.

Of course, they won’t share those statistics, because that would reveal how many domain name owners they’re inconveniencing. Instead, they’ll just continue to flout the ICANN transfer rules, and ICANN will continue to do nothing.

Here’s our pledge to our customers: We’ll always abide by the letter and spirit of the ICANN transfer policies. If you want to transfer your Tiger Technologies domain name elsewhere, we’ll help you, not hinder you. In fact, we’re one of the few companies that publicly explains how to do it. We value your business, but we’ll never force you to stay with us against your will.

(And by the way, we’re not ignoring security, either. Every domain name transfer gets reviewed by a real person here, and if we see anything unusual, we’ll send you an e-mail message and/or give you a call to find out what’s really going on.)

We are now seeing newer versions (commonly called “Gumblar”) which spread by inserting “script” tags with encoded JavaScript code. Because there are several variations of this approach, and because some legitimate commercial scripts use the same technique to hide their source code, we cannot perfectly identify and strip out these infections. Therefore, we will not automatically strip out the “script” tags from any upload file that looks suspicious.

If your Web site is infected, your best solution is to:

1. Scan your computer for malware. See our prior blog post for links to suggested scanning software.
2. Change your account password in our control panel (since your account password is also your FTP password).
3. Change the passwords for any additional FTP accounts you may have defined.
4. Re-upload (or “re-publish”) your Web site to our servers.

Of course, we always recommend that users run anti-virus software on their systems, and keep backups of their Web site files and data.