Tinsology

I noticed an article today on CNN called  How to create a ‘super password’. For those of you who don’t feel like reading the article, it is basically about how researchers at Georgia Tech are able to brute force 8-character passwords in less than a couple of hours, using “clusters of graphics cards”. This is nothing new; graphics cards are being used for all sorts of applications other than graphics. What I think is more interesting is the conclusion the writer draws from the fact that cracking an 8-character password is a simple enough task, provided you have the hardware and the ability to program it. That conclusion being we should “Say goodbye to those wimpy, eight-letter passwords”.

Before I comment on the article I’d like to talk about what goes into cracking a password. The article refers to the brute force method, but fails to mention that in order to carry out such an attack you must already have one piece of information: the password hash. While it is technically possible to carry out a brute force attack without this piece of information, it would mean every time you generate a password you would have to test it using the target platform itself. For example, if you were trying to obtain a users password to their personal computer, your password generating program would have to attempt to login with every password it generated. Even if it weren’t the case that most applications are smart enough to lock a user out after a certain number of attempts, using this method would greatly diminish the number of passwords you could generate in a reasonable amount of time. If you consider attempting to obtain a user’s password to a website it becomes entirely impossible to use this method.

So what is a password hash and how do you obtain it? Most applications do not store passwords in their raw state. Instead they use the password to generate a hash and store that instead. Rather than explain what a hash is myself I’ll let Wikipedia do the work. Obtaining a hash might be as simple as knowing where to look when it comes to desktop applications. For web applications however, there is a bit more to it. When you register on a website the server generates a hash and stores it. It never even touches the users computer. This means that in order for an attacker to have the hash corresponding to your password they must have already compromised that site. This of course does happen; if it didn’t I wouldn’t be writing this.

Once an attacker has the hash they can begin their brute force attack. Now every time a password is generated it is hashed using the same method as the hash obtained from the server. As the article mentions, if your password is 8 characters long (even if you use non-alphanumeric  characters) it will take only a matter of hours with the right hardware to find a match. Simple right? Maybe not. There are a couple of assumptions here that may be the key to whether or not it is necessary to have longer passwords: Does the attacker know the method used to generate the hash and how quickly can a hash be generated using this method.

An attacker cannot necessarily determine the method used to generate a hash from the hash string alone. Seeing some example hashes might help understand why. This is a (very non-comprehensive) list of some hash functions and example outputs (all of them were given the input ‘tinsology’):

It is important to note that not all of the above algorithms are meant for or should be used for password hashing. I’m looking at you md5.

As you can see from the list length alone is not a distinguishing factor. However, knowledge that a particular hash function is more commonly used than others, combined with the length of the hash, might be enough to determine which algorithm was used. For example, if I saw a 40 digit long hash, I would assume it was generated using sha1. This will not be a problem for a well secured application however; there are some simple tricks to making it impossible to determine how a hash was generated simply from looking at the output.

One such method, called salting, involves appending a predetermined string of characters, called a salt, to the hash and rehashing the resulting string. Here is an example using the sha1 has of the string ‘tinsology’ with the salt ‘a$f’:

An attacker would be correct to assume that the final hash was generated using sha1, but if he were unaware that a salt was used that information would be useless. If he attempted to find a string with a matching hash using brute force it would be equivalent to trying to crack a 43 character password. This would be true regardless of how long the password used as input was.

If an attacker is able to obtain the database containing the hash however, it may be reasonable to assume that they have also obtained the source code revealing how the hash was generated. Even if this is the case you still gain something by salting and rehashing. Increasing the number of operations needed to generate a hash means you reduce the number of passwords that can be tested per second. If an attacker can generate and test X passwords per second, doubling the number of operations needed to generate a hash would reduce that number to somewhere around one half of X.

This fact yields an alternative to using longer passwords. While hashing is a fairly common operation on a webserver, every time a user logs in a hash is generated, it does not compare to the trillions of hashes that need to be generated to crack a password using brute force. If you maximize the amount of time that can reasonably be spent generating hashes on a webserver, you minimize the effectiveness of brute force attacks.

What does all of this say about the question at hand? Do we need to use 12 or more characters passwords in order to be safe from having our passwords cracked? Perhaps, but if we do it isn’t because passwords cannot be secured against brute force attacks. The underlying point in the article is that as technology improves, these types of attacks become more and more feasible. I think that this is a two way street however. If malicious users can throw more hardware at the problem, then so can server administrators. The advantage in this case does not go to the attacker. An attacker must generate trillions of hashes per minute in order to find a match in a reasonable amount of time. Even the largest websites out there don’t even come close to that. Using a slower hashing algorithm is going to slow down a brute force attack a whole lot more than a server.

The catch is how much trust you should put into the websites you are giving your password to. I trust that if I give my password Google I’m not going to find out that someone came along, downloaded their database, and found that my password was being stored unencrypted. This definitely isn’t the case for every website asking for my password. The trick is to have multiple passwords and make sure that you don’t use the same one for your bank account as you do for the website your neighbor made dedicated to his cat.

Every now and then I discover something that makes me feel like I’ve been doing things the hard way. The feeling is an interesting combination of excitement and embarrassment. I experienced this today while browsing PHP documentation. I discovered two function that will make my life a lot easier in the future: debug_backtrace and debug_print_backtrace. As someone who has written his fair share of Java, I’m very accustomed to stack traces. The fact I’ve made it as far as I have with PHP without them leaves me feeling amazed. The fact that I’ve had access to them all along leaves me feeling ashamed.

I guess you learn something new everyday.

Creating Threads

Searching

When a rational person has a question or a topic to discuss on a forum that person might think “Maybe I should use the search feature to see if a thread regarding my topic already exists!”. This is generally a waste of time, however. The probability of two people on a forum consisting of thousands of members over the span of several years having the same question, idea, or thought turns out to be very low. In addition to this, using the search feature can be incredibly confusing to use and takes far too long (sometimes 2 whole page loads).

Here’s a tip: If you happen to find a thread that is slightly related to your topic, feel free to hijack borrow it.

Finding the Appropriate Forum

It is common for a board to have a separate forum for each distinct topic. However, you probably don’t have time to read the title and description of each one. The best way to choose a forum to post in is to chuck a piece of chewing gum, spit wad, or dart at your screen. Which ever forum it sticks to is the one you should post in. It is safe to do this because forums have these things called moderators. They are responsible for placing threads in the appropriate forum and can generally be thought of as your slaves.

Here’s a tip: If you can’t decide between several forums, either because your topic is related to both, or you can’t tell which your dart landed closer to, post in all of them. This will ensure your post gets maximum exposure.

Titling your Thread

Thinking of a clear, relevant title for your thread can be a difficult task. So don’t bother! The best way to create a thread that will draw the attention of others is to use lots of capital letters and lots of exclamation marks (!!!).

Here’s a tip: It is best to keep things simple. The title: “Need help validating form data in PHP” can be reduced to “OMG HeLP!!1!”. Not only is it shorter, but it also conveys a sense of urgency.

Punctuation and Grammar

The great thing about forums is that they are informal. This means that punctuation and grammar are completely optional. In fact, including punctuation in your post is a waste of precious bytes in the forum’s database. In addition to this, readers will have to read through your post multiple times and think very hard in order determine what you are trying to say. In other words, leaving out punctuation is the easiest way to create a thought provoking post. If you do decide to use punctuation, you should use it in new and unique ways as a form of artistic expression.

Here’s a tip: the most efficient way to write your post is to pretend you’re in the 19th century sending a telegram. Leave out any words that aren’t absolutely necessary.

Spelling

If you’re writing your PhD dissertation in comparative literature then spelling is probably important. On a forum, however, don’t waste your time distinguishing between there, their, and they’re. Most modern browsers come with a spell check feature, but it is common knowledge that these features were created by grammar Nazis determined to hurt your feelings by pointing out your mistakes; Don’t give them the satisfaction!. Ideally it is best to use a browser that won’t bother you with little red lines such as IE6.

Here’s a tip: If your spelling is so bad that people think you’re not from an English speaking country just go with it.

Posting Code

Most forum software comes with built in features for displaying formatted code with syntax highlighting. However, unless you’re the one that designed these features figuring out how to use them is a lost cause. It is best to just copy and paste your code directly into your post. It is also important to post any and all code that could possibly be slightly related to your problem, even if it is hundreds of lines.

Don’t bother including any error messages with your code. They are almost always too cryptic to be useful. Also, most programmers enjoy the challenge of trying to determine what is wrong with your code based only on vague description. If you really want to give them a challenge, don’t even include the vague description. A post containing only the words “wuts wrong with this:” followed by a massive blob of code is a programmers dream.

Here’s a tip: Not mentioning the particular line that’s giving you a problem will force your readers to dig through your code to find it. This ensures you have their full attention.

Getting a Response

Response time varies from forum to forum, but any thing longer than thirty seconds should be considered unacceptable. If you find yourself waiting longer than this you should reply to your own thread demanding an immediate response. Remember: Just because the person helping you is not being paid doesn’t mean you can’t demand he devote himself completely to your problem.

Here’s a tip: The best way to get a response is to make sure your thread is always on the top of the page. If it ever falls below number one just reply “Bump” until it gets a response.

Replying to Threads

Your 2 cents

It is generally considered rude NOT to reply to a thread that you read, even if you have nothing of use to say. At the same time it is important to convey to everyone that you’re an expert… at something. If you don’t have any clue what you’re talking about, just say something vague. You can also try just stating your opinion as fact and backing it up with nothing (no one will notice).

Here’s a tip: Make sure never to come back to see replies to anything you’ve posted. This way people will learn not to question you because they know you won’t dignify them with a response. This is the forum equivalent of sticking your fingers in your ears and singing the Oscar Myer Weiner song, which as we all know is a very effective debate strategy.

Volume

Making lots of short, mindless posts is the same as making a few well thought out, well written posts. Only without all that headache-inducing thinking. Having a high post count will indicate to others that you’re an expert… at something.

Here’s a tip: Posting “I agree” or “Great topic” is a good way to increase your post count. You don’t even have to read the thread!

Reading

Reading the title of a thread is usually good enough to devise a perfectly good response. Reading the topic itself should be considered a courtesy. Reading each post in the thread is usually very time consuming and yields very little benefit.

Here’s a tip: If you recognize one of the words in the thread title, just regurgitate everything you know about that word.

Miscellaneous

Being an Expert

Some people think being an expert is about learning as much as possible about a given topic and being able to use that knowledge effectively. Clearly they’re not experts on being an expert. Being an expert is 50% claiming to be an expert, 50% pretending you know what you’re talking about it, and 1% actually knowing something. If you read the first paragraph of the Wikipedia page on a topic, then you’re ready to start telling people you’re an expert on that topic.

Here’s a tip: Learn as many buzz words regarding your topic as possible. If you can combine these words into a coherent sentence everyone will think you’re an expert.

Signature Links

I read somewhere on the Internet that signature links are one of the best ways to promote your website. Naturally I now tell everyone this is true.

Here’s a tip: Some forums, for no particular reason, have rules that prevent members from having signature links until they have a certain number of posts. You can get around this by just adding the link to the bottom of your post. No one will notice.

Rules and Reprimands

Believe it or not, some forums have rules. Usually, however, they are difficult to find and too time consuming to read. This being the case it is perfectly acceptable to just ignore the rules and trust your judgment. If a moderator happens to reprimand you, you should remember one thing: Moderators are generally rude people and tend to overreact. Anything they say can usually be taken as a suggestion.

Here’s a tip: The only practical way to learn the rules is through trial and error. Have lots of extra email accounts on hand, that way you are free to “test the waters”. If you get banned just register a new account.

I have been using various shared hosting providers for several years now. In that time I have never renewed a hosting plan with any single provider; instead moving from one to another for various reasons. Before I go any further let me describe my needs with regard to hosting:

1. Obviously one of my needs is to host this blog. I don’t get a huge amount of visitors (150 on an average day) so this isn’t much to ask for.
2. I have a few other sites that are in development, most of them will never see the light of day. Their impact on server load is pretty much negligible.
3. I develop PHP scripts on my local windows machine, but I often upload and run them on my host to make sure they’ll work in a linux production server.
4. If I develop something for a client I usually demo it on my host.

That’s it. Nothing is mission critical and I don’t get a lot of traffic. This being the case you may be wondering why I move from host to host. After all, my needs aren’t very demanding. To be honest one of the reasons is that a renewal is almost always more expensive than switching to a new provider. You don’t have to look hard to find a discount, the catch is you have to pay full price when it is time to renew.  I wouldn’t mind paying a bit more though, if it weren’t for one thing: there is almost always something that I find dissatisfying: poor customer service, lack of features, lack of freedom, etc.

One thing that up until my last host was never an issue was server performance. As I mentioned my needs are fairly small, and I don’t mind a little downtime. The fact that I can pay a company money and not have them meet my relatively small amount of demand has scared me away from shared hosting forever. This is where the horror story portion of this article begins:

Up until my recent host switch I had been hosting with a company called MochaHost. The reason I chose them in the first place was related to one of my complaints about a previous host: lack of features. On paper MochaHost had everything I needed, and like virtually every shared hosting provider they had an uptime guarantee. In general these guarantees have a ton of loopholes and are not to be trusted, but in this particular case the guarantee was an outright lie. The quality of server I experienced was beyond terrible. I experienced frequent downtime usually lasting only for a short period (but long enough to be extremely annoying when you are trying to get something done). Half the time when my service wasn’t down it was very slow, often to the point where you might as well consider it to be downtime. This graph illustrates my point:

The graph is from Google Webmaster Tools and shows the amount of time spent download a page. It should be fairly easy to tell at which point I switched hosts. The site performance tool in Webmaster Tools also consistently rated this site as being slower than 90+ percent of other sites prior to the switch.

When I reported this downtime usually the response completely ignored the underlying issue. Generally some person would reply that it seems to be working now, without addressing the problem that IT WAS down and that this wasn’t the first time. The only thing good I can say about MochaHost was that their customer service was very responsive and helpful, provided they weren’t dodging questions about uptime and performance.

MochaHost was only the worst part of what was ultimately a bad trip through shared hosting land. In spite of not needing much in terms of performance, I was constantly disappointed with the features and level of flexibility of shared hosting. This led me to switch to VPS (Virtual Private Server). In case you are unaware, a VPS is somewhere between a shared host and a dedicated server. A server is divided between multiple user, but this is transparent to the user; the environment is effectively the same as that of a dedicated server.

This comes at a cost however, I’m paying twice as much as I did for shared hosting. What I get in exchange, however, is well worth it. In addition to getting better performance than you could hope for in a shared host, I have absolute freedom: I have root access and I can configure my server anyway I please, and I can install which ever software I choose. I was even given the choice of server location (I chose one in California). Of course the downside to absolute freedom is absolute freedom: I’m free to screw up anything I can and when I do there is no one to hold my hand. Having had plenty of experience screwing up my own machine I think I’m up to the challenge.

Another benefit of VPS is the dramatic decline in bullshit. Some shared hosts give you unlimited everything, which is bullshit for ‘we’ll decide when you’ve used too much bandwidth or storage’. Still others promise you more than they would ever let you use. The caps on my bandwidth and storage are both real and reasonable. In case you’re interested (Warning: Imminent blatant affiliate link drop) I’m using Linode. I paid about $220 for a year of service and so far I couldn’t be happier. A word of caution though: If you don’t know how to configure and manage a server, or don’t want to take the time and effort to learn, it may not be for you.

Update: A perfect example of what I mean by being free to screw up anything I can: When I was configuring this site in apache I forgot to set the server alias www.tinsology.net for the domain tinsology.net. For whatever reason all of the traffic from www.tinsology.net was getting redirected to a completely different domain: errordatabase.info, which is another site of mine hosted on the same server.

The lack of function overloading is one of my biggest complaints about PHP. If you’re not familiar with overloading, its a feature of some languages that allows you to defined multiple methods (or functions) with the same name, but taking different paramenters. In Java, for instance, methods are not identified solely by their name. Instead, functions are distinguished by their signature: their name, return type, number of parameters and their types. This allows you to do things like define multiple constructors for a class.

PHP not being a typed language, using parameter types and return types as part of a method or function signature is out of the question. You could, however, use the number of parameters. In my opinion, you should be able to do something like this:

class Foo {

	function __construct()
	{
		//constructor that takes no parameters
	}

	function __construct($param1)
	{
		//constructor that takes 1 parameter
	}

	function __construct($param1, $param2)
	{
		//constructor that takes 2 parameters
	}
}

If you did this, however, you would get an error message reading something like this: Fatal error: Cannot redeclare Foo::__construct. As unfortunate as this is, it is possible to devise a simple workaround, due to the fact that a method can be written to take an arbitrary number of parameters. The solution is to create a method that can take any number of parameters and have that method delegate to ‘helper’ methods:

class Foo {

	public function __construct()
	{
		$args = func_get_args(); //any function that calls this method can take an arbitrary number of parameters
		switch(func_num_args())
		{
			//delegate to helper methods
		case 0:
			$this->construct0();
		break;
		case 1:
			$this->construct1($args[0]);
		break;
		case 2:
			$this->construct2($args[0], $args[1]);
		break;
		default:
			trigger_error('Incorrect number of arguments for Foo::__construct', E_USER_WARNING);
		}
	}

	private function construct0()
	{
		//constructor that takes no parameters
	}

	private function construct1($param1)
	{
		//constructor that takes 1 parameter
	}

	private function construct2($param1, $param2)
	{
		//constructor that takes 2 parameters
	}

}

It might not be pretty, but using this method you will be able to call the constructor of Foo as if it were actually overloaded:

$x = new Foo();
$y = new Foo(1);
$z = new Foo(1, 2);

An alternative to this would be to use default parameters to determine what action to perform, but this method gets increasingly clumsy as the number of arguments grows.

I have an old single core laptop that doesn’t get a whole lot of use anymore, partially because it is dated (purchased in 2006) and partially I’ve never really adapted to using a laptop as a general purpose computer. Increasingly, however, I find myself in need of a laptop either when I want to get some work done when I’m away from home, or when I need to take my work with me. This being the case I decided to re-purpose my old laptop as a dedicated development machine.

I could have just put a fresh copy of Windows XP on it and gone from there, but given the circumstances that might not have been the best route. All I needed to run was apache, MySQL, PHP, subversion, and something to write code in. Clearly something more lightweight than Windows could accomplish this. In addition to this I wanted something that would mirror my production server, which is running ubuntu. I ended up installing lubuntu, a lightweight distribution based on ubuntu (if you plan on trying lubuntu bear in mind that it is still in beta). Other than some very minor bugs, lubuntu seems to be perfect for my needs: I could configure it to be almost identical to my production server, it is easy on resources (even on my ancient laptop), and I immediately noticed a big improvement with regard to battery life.

Traditionally, when someone is introduced to programming, the first block of code they write is the infamous “Hello World” program. Unless you’re dealing with some esoteric language this program usually consists of just a few or even a single line. There is one popular language out there where, in comparison, Hello World is a monster: Java. If you’re a Java coder you may not see it, especially if Java wasn’t your first language. Try to look at it from the perspective of a first timer:

public class HelloWorld {

	public static void main(String[] args)
	{
		System.out.println("Hello World");
	}
}

In addition to a huge dose of OOP some of the concepts bundled into this small block of code are: visibility and scope, arrays, return types, and data types. How do you explain static to someone who has no concept of an object? I explicitly recall, when taking my first Java course, my professor referring to static as “Voodoo Magic”. Compare this to something like C++:

int main()
{
	cout << "Hello World";
	return 0;
}

Granted the whole << thing might seem a bit strange, but overall this is much easier to explain. Don't even get me started on PHP:

echo ‘Hello World’;

Don't get me wrong. I think Java is a great language for beginners. It's balance between ease of use and structure keeps new comers from punching their monitors while at the same time adhering to a fairly strict set of rules.

Anyone who has ever had an email account is probably very familiar with the “Do not reply” email. They can take the form of notifications from your bank, reminders to pay a bill, a newsletter, or just plain spam. Generally the read a little something like:

Please do not reply to this email. This mailbox is not monitored and you will not
receive a response.

Usually this is followed by some instructions to follow if you have a question or concern. I imagine at some point in the history of automated emailers someone decided that they did not want to receive any reply from their users via email, or at least from email directed to the address in question, and everyone blindly proceeded to follow this example. That is what contact forms and support email addresses are for correct? To a certain degree this is true. Having to monitor another email account (or more) for support questions would only exacerbate things in the nightmare that is customer support. So the solution is to toss out any incoming email to these accounts and direct users to ask their questions via support form or an alternate email address.
In my mind this is a cop-out. Consider what you lose by doing this. In most cases if I suddenly have a question after receiving an email from my bank, this question is with regard to the message I just received. If I were able to just hit the reply button the original message would be right there on the bottom of my message. If I am to use some other means to ask my question I might forget to include it or decided that it is of no importance.

In addition to this there is the hassle of the alternative process. I have to go to my bank’s website, find the support form, fill out all the necessary information which in my case means first and last name, date of birth, account number, social, and email address (twice). Believe it or not this is the case even if I’m logged into my account. This is a minor inconvenience, but the process introduces the chance for user error. If I put the wrong account number or some other typo occurs my question might never get answered or I might be asked to do it all over again. If I were able to just hit reply all of this information could be derived (automatically) from my email address.

The problems don’t stop there. Often it is the case that support forms ask you to choose the department or type that your question falls under (i.e. is it a billing question, a technical question, etc.). Sometimes the lines between question categories can easily be blurred and submitting a question to the wrong department could potentially increase the response time. It takes x time for person A to get to your question, if A is not the right person to answer the question then it is redirected to person B. Your wait time is now x + y. If you were able to just reply to the email the type of question would be determined automatically and directed to person B. Your wait time is now just y.

Obviously the ubiquitous “do not reply” emails are no the result of someone failing to realize that it may be convenient for the user. The problem is that it complicates things for the support team. Or it least it appears this way at first glance.

Wouldn’t this mean monitor additional email accounts? There is no reason why any person working in support should have to monitor an email account; there are better ways. A properly implemented support system would make the source of the message, whether it be an email or a form, transparent.

It is important the users be directed to the website so that they can find answers in our FAQ or knowledge base before inundating the support system. The solution here is to replace your “do not reply” messages with links to places where the user can find answers. Additionally this gives you the opportunity to serve specialized questions and answers based on the content of the message. Ultimately, users asking obvious questions or questions that have been answered many times in the past is unavoidable.

What about emails containing sensitive information? A user may inadvertently expose their private information to the support team by hitting reply. The solution here is to be careful about what information you put in an email. I am not suggesting that Do not reply emails should be done away with entirely. If it is absolutely necessary to put sensitive information into an email (password resetting for example) then it is appropriate to use a Do not reply address.

I’d like to conclude this entry by imaging a support system with Do not reply (almost) eliminated. Image the support system for a web hosting company. There are three support departments: Billing, accounts, and technical, each of which has an email address. There is also a Do not reply address used exclusively for password resetting. There is a support form which asks the user to select the appropriate department. Finally, there is a knowledge base containing common and previously answered questions. The knowledge base also has a feature that allows it, given a question or some other block of text, to attempt to find similar questions that have already been answered.

When a member of the technical support team accesses the support system, they see only questions for their department, both from the support form and from the technical department email account. The same is true for the other departments.

If one of the departments sends out a notification, whether it be automatic (bill is due, a change to your account, etc.) or manual (planned downtime, a new feature, or some other announcement), before the message is sent, its content is passed to the knowledge base which determines common questions and answers relating to the content of the message. It selects a few and appends them to the message. The message is then sent. If the user has a question regarding the message they have the option of hitting reply and having their message (original message and all) sent to the correct department.

After hearing some noise about Google having updated page rank, I got curious and decided to check the PR of this site. I launched this site shortly before the last update, when it was assigned the rank of zero. This time around, to my surprise, I found that the index, as well as one other page was ranked 4. This was surprising because I have not made any deliberate effort to increase the rank of this site. I didn’t submit to directories, I haven’t purchased links, spammed blogs or forums, or consulted with an ‘SEO Expert’.

So, how then, did I accomplish this feat? Did I discover a secret SEO technique? Did I go down the street to my local Google building and hold them up at gun point? If I had a secret I’d tell you. The reality is that I have been focusing almost exclusively on my content. At times, actually, it seems to me that that IS the secret. Whenever I see people asking how to increase their page rank, I see responses like “get more backlinks” and “post your links on forums”. I never see someone respond “improve the quality of your content”.

I don’t claim to all of a sudden be an expert on the topic, nor do I intend to brag up this ‘accomplishment’. My point is that spending time dropping links, submitting to directories, and sending fruit baskets to Google should all be secondary to improving your content. It is important to understand that high page rank is a symptom of high traffic. If  I, for whatever reason, wanted to catch the flu would I focus on giving myself a headache and inducing vomiting? No. I would go to the hospital, get down on my hands and knees, and start licking some floors. The same thing is true of page rank and traffic (not the licking floors part). Artificially increasing PR by spamming links will not lead to increased traffic.

Roughly a month ago I started serving Kontera, in-text, ads. Based on a month of use here are my impressions of the platform:

Ad Relevance

I found that the ads were relevant only to the term selected for the link, meaning that the ad served was based on the word or phrase in the link. This being the case, often times the ads were irrelevant to the overall content. For example, if I wrote a post about login systems, or otherwise mentioned login systems. the word system could be selected as a link to an ad about air conditioning systems.

Revenue Generated

Before I go into detail, let me mention that I do not generate a lot of ad revenue, nor do I expect to. If I break even on the domain costs and hosting fees I’m happy.

I did generate some revenue, and I imagine on a site with more traffic that revenue could easily be significant. What money I did make, however, was far less than was I make on my AdSense ads. I also found that in spite of the fact that the kontera ads are in-text and the Google ads are outside of the main text, the AdSense ads received more clicks. If I had to guess as to why this is, I would say it is because visitors to this site are well aware of what those ads are and for the most part arn’t interested. I imagine the relevance of the ads that I discussed above also plays a factor in this.

Intrusiveness and Conclusion

I personally don’t find in-text ads to be overly intrusive. After some thought, however, I decided that having users mistakenly click what they think to be relevant links and instead be served an ad is not worth the amount of revenue generated. I found that the ‘traditional’ banner ads were more effective and relevant.