In an attempt to clear the air over all the Google Hijacking stuff, I am creating one more (final) post about it. Since being contacted by the author of edelina.com, Eduard Tabara, I have come to the conclusion that the Google Hijacking (though real) was a result of an error and was not intentional on his part. Eduard, you are vindicated. I'm burying the hatchet - this issue is now declared dead. Lessons learned: 1) Don't use or associate yourself with questionable SEO practices, it makes people inherently mistrust you. 2) Sometimes it's worthwhile to give someone the benefit of the doubt even when every instinct in your body is telling you otherwise.

This post is in reply to being contacted by the owner of edelina.com from the post Macromedia and/or FullAsAGoog RSS Feeds Being Used By Spammers. Eduard's reply to me can be found in the comments section of that post. ---
Eduard, Thanks for posting the comment (and sending me the email). Good to see you are also reading the blogs you are hijacking! To answer your questions: 1) edelina.com's whois contains fake domain registration info, usually a sign someone is trying to hide something, and a good indicator that something shady is going on. 2) Hijacked URLs made to be SES URLS - While the edelina.com homepage does currently appear to replicate much of the functionality as fullasagoog.com - I notice that a few things have been changed, including the removal of several self referencing links and a link through URL format that was clearly re-writing the titles of blog postings into URLs that appeared to be legitimate pages. This modification of URLs is often called "search engine safe URLS" and is used to make the links/pages appear to be a real HTML page on the site and not a generated page. For most sites this is a legitimate thing to do. The problem is that you were making search engine safe URLs for MY content (and other bloggers). Effectively attempting to make the search engines index it as if it were on your content on your site. This is the very definition of Google Hijacking. If all you were doing was tracking clickthroughs as you say, why go to the trouble to attempt fooling the search engines into thinking the content was a page on your site? Also, oddly, fullasagoog.com seems to be counting clickthroughs without hijacking - so it's not so hard to accomplish. 3) Searching "Abadon Studio" in Google reveals a ton of sites which are google bomb factories with tons of sometimes unrelated keywords including "Abadon Studio". This is typically the calling card of a less then legitimate SEO operation, and not that of a design shop (which abadonstudio.com claims to be) 4) Spam on edelina.com - Taking a look at edelina.com's history, it's easy to see that it's previously been used for a page called "Receive A FREE Personalized Quote By A Local Licensed Agent!". That's pretty spammy and shows a willingness to transform this site into a huge junk magnet in the past, and a willingness to do it again in the future. 5) As to why I didn't email you at all, well... I don't normally negotiate with spammers, I just block them out. Given the overwhelming quantity of evidence above, I didn't really see any reason to have contacted you. In the end though, I am glad that you did contact me. It shows a willingness (perhaps) to change, and recognize the fault of what you did whether it be intentional or unintentional (which I hope it was). I also applaud the changes you made to the links on your site, thought I note that you've left the Google hijacking links active so that they won't fall out of the search engines. That's not so honest.

I'm not kidding.

So I just returned from the First Annual Software Security Summit and have security on the brain. I thought I'd post about a little something that's always bothered me - weak protection of passwords in web applications. Many web applications don't handle much sensitive data. If someone breaks into the (fictional) web application for my mother's quilting guild, quilt-o-rama.com, no-one's going to care that all their quilting patterns have been stolen. They might even care if someone gets a list of all the guild members. However, there is one bit of data stored in this web application that's of value - their passwords. Let's face it, people don't use different passwords. They should, but they don't. That means passwords become: A globally shared key that opens all doors. Now you may be saying to yourself, "But Cameron, that's the user's fault that they use the same password for everything.". Sure, some responsibility does fall on the user. But we all know perfectly well that most people aren't going to choose a unique password if they can get away with it. Therefore we have to be willing to accept some responsibility when protecting our user's passwords. Since we know people are going to do everything in their power to choose an easy to remember (weak) password, we should protect it. This responsibility falls on us - the application developers. We have become custodians of a huge library of personal keys. Keys that might unlock data at banks, home computers, offices, government records, and quilt-o-rama.com - for most users the key is the same (or very similar) for all of these. Attackers are always looking for the weakest point to attack. Do you have a site that stores passwords in plaintext? Do you keep up with security bulletins? Do you think no-one cares about breaking into your little boring site? Congratulations, you are the weakest link (goodbye)! In security circles, this is commonly referred to as "key management". Your bank may encrypt your account data six ways from Sunday, but if the encryption key is easy for an attacker to discover, the encryption becomes meaningless. The data might as well have been in plain text all along. People go to all sorts of lengths when it comes to key management to make sure that the same encryption key isn't used in too many places, that it's not easy to discover, and that it's routinely rotated in case an old key is discovered at some point. The concept of password management is no different. It's a key, not an encryption key - but a key still. It unlocks information, but unlike encryption keys the same password is often used everywhere, very rarely rotated, and often not very well protected. And your web application's users have shared their keys with you. They have trusted you to keep it safe for them. You are holding valuable keys. Are you doing your part to protect your user's bank accounts, businesses, and other personal information?

This week I will be attending the First Annual Software Security Summit, a conference focused on writing secure software and understanding secure software architectures. If anyone else in the Macromedia/ColdFusion community is attending, shoot me an email and I'll keep an eye out for you.