Browser Support

Choosing your Browser Support Level

Choosing which browsers and which versions to support for your Web Application is a serious consideration.

For every browser you need to support you will need to do testing to ensure that your application works properly and if there are issues you will need to spend time debugging and fixing the issues.

In addition to each browser there is the issue of Operating Systems. Do you support browsers on all Operating Systems? Have you considered how you plan to test this?

Finally the most important question is: "Does it make smart & financial business sense for me to support browser X?"

So how do you determine what browsers to support?

Step 1: Operating Systems

Are there any Operating Systems that you can not justify supporting? e.g. If you are making an application for the Enterprise market do you need to support Apple or Linux? I'm not saying to drop support, but rather to consider what percentage of your users will be using these Operating Systems.

Step 2: Browsers

• Firefox
• Internet Explorer
• Safari
• Chrome
• Opera
• Camino
• Konqueror

The good news is that Netscape is no longer a browser you need to support - the bad news is that you will need to support several if not all of the above browsers. If you don't need to support Linux you can remove Konqueror from your support list. If you don't need to support Mac's you can drop support for Camino...... but the top 5: Firefox, Internet Explorer, Safari, Chrome & Opera... are likely going to be on your support list.

The even better news is that Firefox, Chrome, Safari and Opera all do an excellent job of supporting web standards... which means if you make your application work in one of them it will likely work just fine in the other 3.

Step 3: Internet Explorer

The bad news is Internet Explorer. With a staggering dominance of the browser market, especially in the corporate enterprise world you will almost guarantee-ably have to support IE.

So in my opinion which browsers should you support?

• Internet Explorer 7, 8 (if you have to support IE6 I really pity you, but the good news is that even Microsoft isn't supporting it after 2014)
• Firefox 3, 3.5
• Safari 3, 4
• Chrome 1, 2
• Opera 9+
• Camino 1.6
• Konqueror 3.5

Feel free to support other browsers like Pogo, Maxthon, Arora, LunaScape as well if you like ;-) they are growing in popularity every day esp. as IE6's market share slides.

Once you've got all of these covered you'll need to consider mobile browsers... but we'll leave that for another post.

Step 4: Money talks

At the end of the day it will be your customers that determine which browsers you will support. I just hope for your stress levels that IE6 isn't in your supported browser list. ;-)

Forgot Password

The Forgot Password feature is something you will definitely need. Your users will have umpteen dozen username/password combos to remember (from other applications) and most users will forget their password at least once, if not many times.

However this feature needs to be implemented very well or you run the very real risk of opening up a security hole that begs hackers to walk on in.

Step 1.) Send the user a password reset email

Since the user has forgotten their password, you will need to set up a new one (securely).

• Why? - Because you hashed the password - right? So you can't just tell them their password

You will want to ask for the email address of the user. This does 2 things for you.

1. It lets you verify that there actually is a user in your system with this email address.
2. It ensures that the password reset email you send is opened up by the "true" owner of the account. e.g. it isn't just the next user in line at the Internet Cafe that is trying to mess with a user's account.

The email should clearly indicate:

• What site the request came from (e.g. Example.com)
• What action is being requested (e.g. password reset vs. address change)
• What the user should do if they believe they received this email in error (e.g. a bogus request)
  
• What will happen if the email is ignored (e.g. Nothing will change)
  

If the email is ignored, nothing happens to the account. This step is also important to make sure that a hacker isn't just sending in reset requests to "disable" existing accounts.

Within the email you will need to include a "key" typically a short hash, that the user needs to enter to "confirm" the password reset request... and/or a link in the email (that includes the key) so the user can return to the site confirming the reset request. Make sure you provide both - there are some users out there with old email clients that won't auto create the hyperlink and there are also users out there that for security reasons want to type in the site address them selves (e.g. for banking sites - to avoid phishing emails)

Step 2.) User confirmation of password reset action

By arriving at your site on the password reset page (with the key in the url) or at a page where they can manually enter it the user can thereby confirm they requested this action.


Step 3.) Enter new password (and verify)

Once confirmed, the user must supply a new password (optionally meeting your password strength requirements) and enter it twice to ensure they haven't done a silly typo.

Depending on the security level of your site, you might have another step. (e.g. what if the email account itself was compromised? For financial applications typically you want the user to also enter in some key piece of information to ensure they really are the person they claim to be. If this is the case, this step should come before setting the new password.

e.g. Security Question/Response:

Q.) "What was your first pet's name?"

A.) "Sticky Paws"

Step 4.) Inform the user

Once the new password is set, inform the user that it has been set and remind them they'll need to remember this... but not write it down for security reasons.

Step 5.) What next?

Again, depending on the security level of your site... once the password has been reset you can either "automatically" log the user in, or explicitly log them out. Forcing the user to be logged out is actually considered a good thing in some cases since a.) The user could be "done" all they planned to do at that point or b.) Making the user log in with the new credentials ensures that they at least remember the password for 2 minutes ;-) and re-type it in will help enforce the new password to memory.