Lanoie.com Blogs

I started teaching HTML in the ’90s. At that time, I would tell students that valid code was important for several reasons, but the one that seems to stick was that it might help them troubleshoot why pages (p-p-p-pages) looked so different between browsers at the time.

You see, at that stage, there were many different browsers, but Netscape was the current champion with Internet Explorer the up and coming underdog. While there were standards for coding your Web pages, neither browser really followed them, which is why some pages could look wildly different between IE and Netscape.

I rejoiced when the World Wide Web Consortium put their online Markup Validation Service up. Now students had an easy way to confirm that their code was leaner, cleaner, and truer to the standards.

At that time, the student might not know if the problem was with their code or with the browser. By validating the code, they could start to eliminate potential problems.

Fast-forward to 2006. IE is the current champion, and FireFox (a relative of Netscape) is an up and coming underdog. While the new roles certainly signifies ch-ch-changes, the need for valid code remains the same.

XHTML (the evolution of HTML) is all about logically defining how content relates and not about how it looks. CSS is supposed to take care of that.

CSS1, the first level of the standard, took care of the basic visual chores of the horrid font tag and a few other simple visual feats. CSS2 (and 3) took on a much larger role. There are logic flow capabilities now, so that you can specify “if a heading level 3 is a direct child of a heading level 2, make it green, otherwise, make it red”. This is a powerful, but very hard to troubleshoot if your code is not logically marked up.

Some companies just don’t get it. I am helping a friend purchase something on the Web, and the site is asking for personal, confidential information (name, password, email, credit card information, etc) on a non-secure page.

Are you kidding me? We read the privacy page, and they go on about how secure their system is, yet they are asking for personal credit card information over a non-secure connection.

I wonder how many people even notice these things.

As a consumer, never give away personal information from companies you do not know or trust, unless you are ready to take the risk of this information getting used or ‘misplaced’ without your knowing.

Also, never give this kind of information away unless you have a secure connection. How do you know you are running a secure connection? The first thing to look at is the address of the Web page. Normal (non-secure) Web pages start with http (HyperText Transfer Protocol). Secure connections start with https. The https means you are running over a Secure Socket Layer (SSL).

Also, your Web browser should display a ‘closed lock’ or a solid key (as opposed to no lock, an open lock, no key, a broken key, or whatever).

Now, technically, you could be on a secure page and not see these clues that you are reasonably safe. This is because some Web sites use ‘frames’ for their pages, which might prevent you from seeing these important security clues. This is their loss. As more and more people learn about safe online practices, Webmasters will have to become aware that just saying a site is safe is not going to convince everyone. They have to prove it.

Brand spoofing, phishing, keystroke loggers, and malware are taking their toll on consumer confidence. Real companies need to be aware of this, and take every effort to inform their users that they are legit.

I have little doubt that the major company I was trying to help my friend make a purchase from was legitimate, but I do think they doubt how savvy consumers are becoming. Otherwise, they would have taken the time to ensure their site looked, acted, and was secure.

This is not a complete list by any means, but here are a couple tips to keep consumer confidence off the top of my head:

I was a system administrator in a previous life, and one thing that a sys admin does is creating user accounts and passwords. My boss was joking that I was taking my duties a little too seriously, so I suggested we guess the CFO’s password.

Four guesses to get in. It was his wife’s first name.

Another job before that I found myself in a similar situation, showing the problem with their password guidelines. The password of a high-ranking officer was also guessed within minutes: golf. An avid golfer, it certainly gave us a starting point. It should have been my first guess, but I started with his kids. Priorities, I guess

First of all, I’ll mention that I had permission to test the password strength in both cases. I would not recommend trying to hack any account unless you have proper authorization.

These are both examples of simply guessing a password based on some basic knowledge of the person. A research (a.k.a. personal) attack can be as simple as guessing passwords based on something you know about someone. If the person is a hockey fan, you try favourite teams, players, or sport brand names. There are entire dictionaries that can automate these kinds of attacks. A text file with several million hockey related passwords could take minutes/hours/days to crack a password. Of course, there are many counter measures to these types of dictionary attacks, but those are for another time.

Imagine someone makes an application that has a bunch of fields like this:

• First name, last name, date of birth, place of birth
• Mother’s first name, last name, date of birth, place of birth, maiden name
• Father’s first name, last name, date of birth, place of birth
• Child’s first name, last name, date of birth, place of birth
• Pet’s first name, last name, date of birth, place of birth
• Home phone, address, fax, email, pager, cell
• Work phone, address, fax, email, pager, cell
• Auto details like license, make, model, colour
• Hobbies, social clubs, pastimes
• And so on.

They could rummage through your garbage (dumpster diving), take pictures of your house and car, look up information about you on the Web (don’t get me started!) or public records like the phone book, and plug in as much as they find. (If they are up on their social engineering and/or phishing, they have even more ammunition.)

Once they have harvested some basic data they could let the software generate different combinations, word/letter substitutions, etc. to create a list of potential passwords to try. The software could do a lot of work with very little research required.

Or, you can simply make some educated guesses. You would be sadly surprised at how often this works.

Matt Cutts, master Google guy, brings up a good point. Although he is talking about general spell checking of your Web page content, it really goes beyond that.

The example that he shows has two mistakes (although he only noticed one initially). The word guarantee has a typo, and also don’t is missing the apostrophe before the t.

The point is simple: content counts. The example given is trying to sell you something. You can do all the SEO (Search Engine Optimization) you like, and bring in hundreds of thousands of eyeballs to your site, but if your content is filled with spelling, grammar, and punctuation mistakes, you will not be able to convert them to sales (or whatever your goal of the site is).