<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tiger Technologies Blog &#187; Industry Observations</title>
	<atom:link href="http://blog.tigertech.net/category/industry-observations/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.tigertech.net</link>
	<description>Behind the scenes at tigertech.net</description>
	<lastBuildDate>Tue, 21 May 2013 06:08:41 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
		<item>
		<title>Protect your WordPress login</title>
		<link>http://blog.tigertech.net/posts/protect-your-wordpress-login/</link>
		<comments>http://blog.tigertech.net/posts/protect-your-wordpress-login/#comments</comments>
		<pubDate>Thu, 27 May 2010 22:39:58 +0000</pubDate>
		<dc:creator>Ken</dc:creator>
				<category><![CDATA[Industry Observations]]></category>
		<category><![CDATA[Tales From the Support Team]]></category>
		<category><![CDATA[Tech Corner]]></category>
		<category><![CDATA[Useful Tips]]></category>
		<category><![CDATA[security]]></category>
		<category><![CDATA[ssl]]></category>
		<category><![CDATA[wordpress]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/?p=1190</guid>
		<description><![CDATA[Do you login to your WordPress blog securely? Are your username and password encrypted so that &#8220;hackers&#8221; can&#8217;t steal them and then break into your blog? (Probably not!) 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 [...]]]></description>
				<content:encoded><![CDATA[<p>Do you login to your <a href="http://support.tigertech.net/wordpress">WordPress</a> blog securely? Are your username and password encrypted so that &#8220;hackers&#8221; can&#8217;t steal them and then break into your blog? (Probably not!)</p>
<p>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 &#8212; blogging from a coffee shop, anyone? &#8212; remember that these connections can be insecure, and could be susceptible to revealing your password.</p>
<p>You can protect your blog by installing an &#8220;SSL certificate&#8221; and configuring WordPress to require secure logins. Your browser will then encrypt your username and password so that no one can intercept them.</p>
<p><span id="more-1190"></span></p>
<p>Traditionally, only online stores used SSL certificates because they were very expensive. But SSL certificate prices have dropped quite a bit recently, and they&#8217;re now low enough that we think SSL certificates should be widely used to protect all logins and other sensitive data.</p>
<p>If you are a Tiger Technologies customer, you can <a href="http://support.tigertech.net/ssl">get an SSL certificate</a> for a great price. (One type of certificate, a &#8220;self-signed certificate&#8221;, is even free if you&#8217;re already on our Gold or Platinum hosting plans.) If you&#8217;re not a Tiger Technologies customer, you can <a href="http://www.google.com/search?q=SSL+certificate">search for companies selling SSL certificates</a> or <a href="http://www.google.com/search?q=free+self-signed+certificate">search for free self-signed certificates</a>.</p>
<h3>Configuring WordPress</h3>
<p>Once you have an SSL certificate installed on your site, it&#8217;s easy to configure WordPress to use secure logins. Simply add this line anywhere to your wp-config.php file (after the opening “&lt;&#63;php” line):</p>
<p><code>define(&#39;FORCE_SSL_ADMIN&#39;, true);</code></p>
<p>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&#8217;ll see your Web browser&#8217;s &#8220;padlock&#8221; icon when you are using a secure connection. The WordPress &#8220;<a href="http://codex.wordpress.org/Administration_Over_SSL">Administration Over SSL</a>&#8221; page has more details.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/protect-your-wordpress-login/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>&#8220;Domain Registry Of America&#8221; scams continuing</title>
		<link>http://blog.tigertech.net/posts/droa-scams-continuing/</link>
		<comments>http://blog.tigertech.net/posts/droa-scams-continuing/#comments</comments>
		<pubDate>Thu, 25 Mar 2010 18:10:04 +0000</pubDate>
		<dc:creator>Robert Mathews</dc:creator>
				<category><![CDATA[Industry Observations]]></category>
		<category><![CDATA[Tales From the Support Team]]></category>
		<category><![CDATA[scams]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/?p=1103</guid>
		<description><![CDATA[We&#8217;ve recently heard from several customers who have received what appears to be a domain name renewal invoice from a company called &#8220;Domain Registry of America&#8221;. These &#8220;invoices&#8221; are a scam. Domain Registry of America is unrelated to our company, and has been cited by the FTC for &#8220;deceptive conduct&#8221;. If you look closely at [...]]]></description>
				<content:encoded><![CDATA[<p>We&#8217;ve recently heard from several customers who have received what appears to be a domain name renewal invoice from a company called &#8220;Domain Registry of America&#8221;.</p>
<p>These &#8220;invoices&#8221; are a scam. Domain Registry of America is unrelated to our company, and has been <a href="http://www.ftc.gov/opa/2003/12/domainreg.shtm">cited by the FTC</a> for &#8220;deceptive conduct&#8221;.</p>
<p>If you look closely at the &#8220;invoices&#8221;, they actually say something like &#8220;This notice is not a bill, rather an easy means of payment should you decide to renew your domain with us.&#8221; However, that small print is easy to miss.</p>
<p>We have <a href="http://support.tigertech.net/droa">a page about Domain Registry of America scams</a> with much more information. We encourage you to make sure that whoever pays your invoices is aware of it.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/droa-scams-continuing/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Statistics of registrars violating the ICANN domain name transfer policy</title>
		<link>http://blog.tigertech.net/posts/transfer-policy-stats/</link>
		<comments>http://blog.tigertech.net/posts/transfer-policy-stats/#comments</comments>
		<pubDate>Fri, 02 Oct 2009 17:12:19 +0000</pubDate>
		<dc:creator>Robert Mathews</dc:creator>
				<category><![CDATA[Industry Observations]]></category>
		<category><![CDATA[domains]]></category>
		<category><![CDATA[icann]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[registrars]]></category>
		<category><![CDATA[transfers]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/?p=742</guid>
		<description><![CDATA[In a previous post, I talked about how some domain name registrars have been violating the ICANN transfer policy for years, preventing domain name holders from easily transferring domain names. I lamented the lack of detailed statistics about how many transfers each registrar rejected. However, it turns out that some of those numbers are actually [...]]]></description>
				<content:encoded><![CDATA[<p>In a <a href="/posts/transfer-policy-violations/">previous post</a>, I talked about how some domain name registrars have been violating the <a href="http://www.icann.org/en/transfers/policy-en.htm">ICANN transfer policy</a> for years, preventing domain name holders from easily transferring domain names.</p>
<p>I lamented the lack of detailed statistics about how many transfers each registrar rejected. However, it turns out that some of those numbers are actually available right on the <a href="http://www.icann.org/en/tlds/monthly-reports/">ICANN Web site</a>.</p>
<p><span id="more-742"></span></p>
<p>Those statistics show exactly how many &#8220;outbound&#8221; transfers each registrar rejected. Let&#8217;s take a look at the May 2009 &#8220;.com&#8221; statistics for the 5 biggest registrars in the world, keeping in mind that the transfer policy suggests that a transfer should be rejected only in very limited circumstances:</p>
<ul>
<li>GoDaddy: 7,855 of 26,475 (29.7% rejected)</li>
<li>eNom: 262 of 22,724 (1.2% rejected)</li>
<li>Tucows: 143 of 22,257 (0.6% rejected)</li>
<li>Network Solutions: 889 of 17,242 (5.2% rejected)</li>
<li>Melbourne IT: 35 of 37,746 (0.1% rejected)</li>
</ul>
<p>(Our company didn&#8217;t reject any, but we&#8217;re much smaller and our numbers aren&#8217;t statistically significant.)</p>
<p>You can see that GoDaddy and Network Solutions reject far more transfers than the other three. In fact, GoDaddy rejects transfers at a rate that&#8217;s about 300 times higher than Melbourne IT and 50 times higher than Tucows. Network Solutions rejects about 50 times as many as Melbourne IT and 9 times as many as Tucows.</p>
<p>In other words, GoDaddy and Network Solutions are far more likely to say &#8220;we&#8217;re not going to let you move your domain name&#8221; than their large competitors. Remember, the transfer policy says that rejections are reserved for exceptional circumstances &#8212; but GoDaddy is rejecting almost 30% of them!</p>
<p>GoDaddy and Network Solutions claim they’re rejecting transfers for security reasons (although they both freely admit that &#8220;security reasons&#8221; include simple contact updates, even though the ICANN policy expressly forbids this). The actual rate of attempted domain name hijacking is almost certainly just a tiny fraction of one percent. Blocking 30%, or even 5%, is absurd.</p>
<p>The obvious conclusion is that GoDaddy and Network Solutions are intentionally inconveniencing domain name holders to make it difficult to switch to another company, and ICANN is letting them get away with it. (After my last post, I got a couple of &#8220;please send us the details&#8221; messages from people at ICANN, but nothing has happened since. Anyway, I&#8217;ve been sending them examples for years, and they could have done something about it a long time ago if they were interested.)</p>
<p>The fundamental problem is that ICANN doesn&#8217;t see itself as a regulatory agency. Some registrars routinely violate this and other policies that they&#8217;re contractually required to follow (trust me, you don&#8217;t want to hear my rant about the <a href="http://www.icann.org/en/registrars/eddp.htm">EDDP</a>), but nothing happens to them. Is it any wonder that they continue to take advantage of it?</p>
<p>Most of the Internet does fine without any regulation because users have choice &#8212; they aren&#8217;t locked in to any particular company. But registrars are different. They need oversight because they&#8217;re in a position to prevent their domain name customers from easily exercising that choice.</p>
<p>I don&#8217;t have much faith that ICANN will fix this &#8212; in fact, <a href="http://gnso.icann.org/issues/transfers/irtp-b-pdp-wg-charter-19aug09-en.htm">part c of the new transfer working group charter</a> suggests that some of the existing rules might be removed instead of being enforced. The very premise of that charter, that a &#8220;change of registrant [...] often figures in hijacking cases&#8221;, is utter nonsense, no more accurate than &#8220;e-mail addresses containing vowels often figure in hijacking cases&#8221;. Both statements are literally true but completely irrelevant. A change of registrant can never reliably suggest hijacking, simply because changes of registrant contact information happen all the time and hijackings don&#8217;t.</p>
<p>There&#8217;s nothing wrong with the existing transfer rules. Companies like Tucows, Melbourne IT and Tiger Technologies honor them every day. What&#8217;s needed is for all registrars to play fair.</p>
<p>In the meantime, if you want to have control of your domain name, you might want to avoid GoDaddy and Network Solutions and pick another registrar instead. We&#8217;re a fine choice if you don&#8217;t mind paying a little more for quality customer service, but there are plenty of other good choices, too.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/transfer-policy-stats/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Registrars continue to violate the ICANN transfer policy</title>
		<link>http://blog.tigertech.net/posts/transfer-policy-violations/</link>
		<comments>http://blog.tigertech.net/posts/transfer-policy-violations/#comments</comments>
		<pubDate>Wed, 22 Jul 2009 17:15:04 +0000</pubDate>
		<dc:creator>Robert Mathews</dc:creator>
				<category><![CDATA[Industry Observations]]></category>
		<category><![CDATA[Tales From the Support Team]]></category>
		<category><![CDATA[domains]]></category>
		<category><![CDATA[icann]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[registrars]]></category>
		<category><![CDATA[transfers]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/?p=545</guid>
		<description><![CDATA[One of the most frustrating things we deal with is helping customers transfer domain names from other &#8220;registrars&#8221; (domain name companies) to us. To do this, we ask the old company to release the domain name, and they then have five business days to either release it or reject the transfer. There&#8217;s an obvious potential [...]]]></description>
				<content:encoded><![CDATA[<p>One of the most frustrating things we deal with is helping customers transfer domain names from other &#8220;registrars&#8221; (domain name companies) to us. To do this, we ask the old company to release the domain name, and they then have five business days to either release it or reject the transfer.</p>
<p>There&#8217;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.</p>
<p><span id="more-545"></span></p>
<p>Fortunately, this shouldn&#8217;t be a problem. ICANN, the organization that controls domain name policy, requires registrars to follow some very specific rules about transfers (<a href="http://www.icann.org/en/transfers/policy-12jul04.htm">here</a>, with an update <a href="http://www.icann.org/en/announcements/advisory-03apr08.htm">here</a>). They list nine specific situations in which a transfer can be rejected, explicitly banning other reasons.</p>
<p>For the most part, this prevents arbitrary rejections. However, there are a few registrars that continue to violate the rules. We&#8217;ve complained (again and again) to ICANN about this, but they don&#8217;t seem interested, so I&#8217;ll mention a few problems here.</p>
<p>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 &#8212; unless he pays them to renew it first. That isn&#8217;t the first time we&#8217;ve heard this, either.</p>
<p>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 <a href="http://www.icann.org/en/announcements/advisory-03apr08.htm">specifically prohibited doing so</a>. They freely admit it, too. GoDaddy&#8217;s Disputes Manager recently told us that blocking transfers for this reason is okay because &#8220;It is not necessary to update registrant information in order to transfer a domain name&#8221;. That&#8217;s irrelevant, of course; domain name owners are legally required to update registrant information whenever it becomes inaccurate, as ICANN&#8217;s update makes clear. GoDaddy can&#8217;t legitimately block transfers just because someone followed the legal requirement to update their contact information.</p>
<p>We see a similar problem with many transfers from Network Solutions. They often tell their customers that they&#8217;ve rejected the transfer &#8220;due to potentially suspicious activity in your account&#8221;. When customers ask for details, they&#8217;re told that the only &#8220;suspicious activity&#8221; was a recent contact update. Again, this is exactly what the policy prohibits.</p>
<p>GoDaddy and Network Solutions claim they&#8217;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&#8217;t think about until then. It&#8217;s perfectly normal.</p>
<p>In addition, the &#8220;security measures&#8221; probably don&#8217;t work anyway. Surely by now any competent domain name thief knows not to update the registrant contact until after they&#8217;ve  transferred the domain name to another registrar, thus bypassing the &#8220;security&#8221; completely.</p>
<p>While the GoDaddy and NSI efforts almost certainly <strong>have</strong> blocked some fraudulent transfers, so would a rule saying &#8220;you can&#8217;t transfer domain names during months that contain an R&#8221;. What really matters is how many <strong>legitimate</strong> transfers are also blocked. We&#8217;ve been on the receiving end of many blocked transfers, and we always try to push the other registrar to provide details about the &#8220;security problem&#8221; &#8212; I&#8217;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.</p>
<p>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&#8217;re pretty sure the former vastly outweighs the latter.</p>
<p>Of course, they won&#8217;t share those statistics, because that would reveal how many domain name owners they&#8217;re inconveniencing. Instead, they&#8217;ll just continue to flout the ICANN transfer rules, and ICANN will continue to do nothing.</p>
<p><em>(Update: we later obtained these statistics, <a href="/posts/transfer-policy-stats/" title="Statistics of registrars violating the ICANN domain name transfer policy">as detailed in a subsequent post</a>.)</em></p>
<p>Here&#8217;s our pledge to our customers: We&#8217;ll <strong>always</strong> abide by the letter and spirit of the ICANN transfer policies. If you want to transfer your Tiger Technologies domain name elsewhere, we&#8217;ll help you, not hinder you. In fact, we&#8217;re one of the few companies that <a href="http://support.tigertech.net/domain-transfer-away">publicly explains how to do it</a>. We value your business, but we&#8217;ll never force you to stay with us against your will.</p>
<p>(And by the way, we&#8217;re not ignoring security, either. Every domain name transfer gets reviewed by a real person here, and if we see anything unusual, we&#8217;ll send you an e-mail message and/or give you a call to find out what&#8217;s really going on.)</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/transfer-policy-violations/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>Need support? Count on us.</title>
		<link>http://blog.tigertech.net/posts/count-on-us/</link>
		<comments>http://blog.tigertech.net/posts/count-on-us/#comments</comments>
		<pubDate>Tue, 08 Jul 2008 17:43:17 +0000</pubDate>
		<dc:creator>Robert Mathews</dc:creator>
				<category><![CDATA[Industry Observations]]></category>
		<category><![CDATA[e-mail]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/?p=122</guid>
		<description><![CDATA[Recently, the Web hosting industry has been abuzz with talk of companies trying to outsource their mail service. One of our largest competitors recently announced that because half of their customer requests for help were about e-mail, and because e-mail is difficult to get right, their customers should just use GMail instead. The problem is [...]]]></description>
				<content:encoded><![CDATA[<p>Recently, the Web hosting industry has been abuzz with talk of companies trying to outsource their mail service. One of our largest competitors recently announced that because half of their customer requests for help were about e-mail, and because e-mail is difficult to get right, their customers should just use GMail instead.</p>
<p>The problem is that GMail, Yahoo mail, Hotmail and other free mail services have no real support. If you have trouble, there&#8217;s no way to talk to the people running the mail system and ask them about individual messages.</p>
<p><span id="more-122"></span></p>
<p>If you send a message from a free mail service and it never appears to arrive at the destination, or if it <a href="http://arstechnica.com/news.ars/post/20080406-gmail-being-throttled-blocked-by-some-anti-spam-vendors.html">takes hours or days to arrive</a>, there&#8217;s no reasonable way to find out what happened to that message. And if someone&#8217;s messages to you are being incorrectly blocked by a spam filter in such a way that they never even make it to a spam folder, you can&#8217;t complain and expect a prompt, useful response.</p>
<p>In contrast, if you have a problem with our mail service, we&#8217;ll spend the time to find out exactly what happened to a particular message. If there&#8217;s a problem, we&#8217;ll fix it. If the message was delivered properly but lost on the other end (which is common), we&#8217;ll find out exactly where the message went to and give you all the info the recipient needs to get it permanently fixed on their end.</p>
<p>These other companies are seeing a problem (&#8220;People take up lots of our time with questions about e-mail&#8221;) and choosing the wrong solution (&#8220;Let&#8217;s figure out a way to stop people complaining to us&#8221;). That may be a good solution for them, but it&#8217;s not a good solution for you, the customer.</p>
<p>We understand that part of what you&#8217;re paying us for is to help you solve problems, with e-mail or any other service we provide. As much as we strive to make things trouble-free, you&#8217;ll sometimes have questions. When that happens, our goal is to help you, not to come up with a way to stop you from asking us about it.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/count-on-us/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>&#8220;We&#8217;ll Pay the Ransom&#8221; to Network Solutions for domain names</title>
		<link>http://blog.tigertech.net/posts/well-pay-the-ransom-to-network-solutions-for-domain-names/</link>
		<comments>http://blog.tigertech.net/posts/well-pay-the-ransom-to-network-solutions-for-domain-names/#comments</comments>
		<pubDate>Thu, 06 Mar 2008 09:37:23 +0000</pubDate>
		<dc:creator>Ken</dc:creator>
				<category><![CDATA[Blog Highlights]]></category>
		<category><![CDATA[Business Announcements]]></category>
		<category><![CDATA[Industry Observations]]></category>

		<guid isPermaLink="false">http://blog.tigertech.net/posts/well-pay-the-ransom-to-network-solutions-for-domain-names/</guid>
		<description><![CDATA[Let&#8217;s say that you want to register a domain name, so you go to the Network Solutions Web site to see if the name is available. If the domain name has not yet been taken, Network Solutions will register it for themselves behind your back, forcing you either to buy the name from them immediately [...]]]></description>
				<content:encoded><![CDATA[<p>Let&#8217;s say that you want to register a domain name, so you go to the Network Solutions Web site to see if the name is available. If the domain name has not yet been taken, Network Solutions will register it <em>for themselves</em> behind your back, forcing you either to buy the name from them immediately (at their high price of $34.99), or wait four days until they release it again (at which point someone else may be able to get it before you).</p>
<p>If this happens to you, we imagine that you might feel something like this:</p>
<p><img src="http://support.tigertech.net/faq.cgi?action=image_display&#038;name=rescue-1" alt="Fictional 'ransom note'" /></p>
<p>We&#8217;re introducing a new &#8220;We&#8217;ll Pay the Ransom&#8221; promotion, wherein we will pay Network Solutions the $34.99 necessary to register the domain name for you. Or, if you&#8217;ve already paid it, we&#8217;ll credit your account $34.99. Either way, just sign up to transfer the domain name to us and a year of our <a href="http://www.tigertech.net/plans.shtml">Web hosting</a>.</p>
<p><span id="more-105"></span></p>
<p>Or, if you just want to transfer the domain name but not sign up for Web hosting, then you can sign up to transfer the domain name to us and we&#8217;ll put it on our watch list. We&#8217;ll register the domain on your behalf when Network Solutions releases it, then transfer it over to us.</p>
<p>We have full details available <a href="http://support.tigertech.net/domain-rescue">on this page</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.tigertech.net/posts/well-pay-the-ransom-to-network-solutions-for-domain-names/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic page generated in 0.230 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2013-05-21 04:54:41 -->
