The average user has no idea of the risks associated with public WiFi hotspots. Here are some very simple tips for them to keep their network access s

My friend Philip is an expert at community activism and is a cracker-jack financial advisor as well. One thing he is not, however - and he would be the first to admit this - is a knowledgeable computer user. Oh sure, he can send emails and cruise the Web, and use Word and Excel, but he doesn't really grok his computer. And one thing he especially doesn't know much about is security. He knows there are bad guys out there, and he knows that he should try to practice safe computing, but he just doesn't know how.

Recently we were talking during a financial meeting, and he remarked that he always felt nervous using his laptop at one of the many coffee shops here in St. Louis that provide free wireless access. After I assured him that he should in fact be very nervous, I reassured him by saying that there were things he could do to protect himself in the local Panera or Kayak's. When he asked me what those things were, I told him I would write a SecurityFocus column that would answer that question. This column, therefore, is written for Philip and all the other average computer users out there who use WiFi without understanding its inherent risks.

WEP and WPA

Most people know by now that they should connect to a wireless connection using one of two encryption technologies: either WEPor WPA. Sure, WPA is a heck of a lot better than WEP, but even WEP is better than nothing. However, that's what most coffee shops use: nothing. Free wireless is an add-on, so they want to keep costs low. WEP or WPA would add additional complications and expense, and additional customer support where none would be available, so most coffee shops just run their wireless wide open.

That means that unless you're specifically given a WEP or WPA key to enter, assume that everything your computer is sending or receiving is sent in the clear. Meaning, anyone who knows what they're doing can see many of your passwords once you type them in. To use that wireless connection securely, then, you need to worry about the programs you're using to access the Net. By and large, people do three things online: use the web, send and receive email, and IM friends and associates. Sure, lots of programs use the Net in some way, but the three I just mentioned are the biggies, so let's focus on those.

Web

When it comes to web browsers at the coffee shop, there's one big piece of advice you should follow: don't use Internet Explorer! Yes, Microsoft has released a preview of the beta of the forthcoming IE7, and it does look better in a lot of ways (although holes were found almost immediately upon its release, but hey, it's a preview of a beta), but that final release is still a long ways off. For now, use IE 6 only if you are absolutely forced to.

So what should you use instead? Firefox, Opera - or Safari if you're a Mac user. All three are free, powerful yet easy to use, and all are safer than Internet Explorer. I'm partial to Firefox (heck, I wrote a book about it), but you should be interested in Firefox for its excellent security record (especially when compared to Internet Explorer's truly abysmal security problems) and the extensions that help you secure the browser and your Internet usage even more.

Once you have your browser open, use your head. Avoid web sites in which you're viewing or entering user names, passwords, account numbers, credit card numbers, social security numbers, and other sensitive data ... unless those sites use https instead of http. If you have to log in somewhere, but the web page's URL begins with https, then it's using a technology called SSL, and it's OK; if the URL begins with http, be careful. If you're just reading the news or sports scores, don't worry about it, but if you're working with sensitive data, do not view or enter information on those types of pages.

If your company provides you with VPN access on your laptop, use it. That's a sure fire way to ensure that everything you send and receive is encrypted, and it makes your surfing much safer.

Email

You can check your email in two ways: using a web browser, or using an email program running on your computer (like Outlook, Outlook Express, Apple Mail, Thunderbird, Eudora, and others). Let's talk about each of those in turn.

Email via Web Browser

There are companies that provide email primarily through web browsers, like Hotmail, Gmail, and Yahoo! Mail, but most ISPs who allow people to download their email using programs also provide access to that same email using web browsers. Most every web mail out there provides a secure (https) page for logging in to check your email, but that's it. Your password will be safe, but none of your emails. Reading and writing emails is done using plain ol' http, which means that everything is sent in the clear. Not good.

I like Gmail a lot, but Gmail doesn't use https for reading emails (it does use it for logging in, though). To get around that, I installed the Customize Google extension for Firefox (and it only works in Firefox). Once the extension is installed, go to Tools > CustomizeGoogle Options. Go to the GMail tab and make sure that "Secure (switch to https)" is checked. Press OK to close the window, and you're done. Now you'll log in to Gmail on an https page, and you'll read and send mail on https pages as well. I like this solution because you don't have to think about it again.

All that said, you can switch to https once you're in Gmail by simply clicking in your address bar, changing the http to https, and then loading the page. Now everything is secure ... as long as you don't close your browser. If you do, you need to manually change to https again, and again. The Customize Google extension does this automatically, so it's a better solution.

Hotmail offers a "secure mode" that uses SSL, but by default you login at an insecure http page, just like you do with Yahoo! - which isn't good. For either service you can click on the tiny "Sign in using enhanced security" or "Submit over SSL" link that most people will never see, but why should anyone have to? C'mon, that should be the default, and http shouldn't even be an option! Worse than that, all other email actions - reading and writing - are strictly http only, with no possibility for https. That's pretty terrible.

If you access mail through a web interface provided by your ISP, you need to look and see if it supports SSL. If you're not sure, call and ask them. If they support it, use it; if not, use something else. Personally, I'm very happy with Gmail. And hey, it's free!

Email via a program

Basically, you're vulnerable during two processes: when you're checking email (using something called POP3 or IMAP), and when you're sending it (using something called SMTP). If those connections aren't protected, then a bad guy can see your actual emails, which may contain sensitive or even just personal information, and he can also view the usernames and passwords you're using to log in to check or send email as well. You want to wrap both those processes in a secure wrapper like SSL (the same technology that protects your credit cards on https web sites) so that someone listening in gets gibberish and nothing else.

For instance, my email is through Pair, and they allow me to check it using SSL to encrypt both my username and password, and any email I download (one of the many reasons I recommend Pair to folks looking for a mail host). That means you need to call the company that manages your email - AOL, SBC, Earthlink, your cable company, etc. - and ask them if they support secure POP3 (or secure IMAP). You can also try a Google search for "[your email company] secure pop3 email". Doing that, I found several differentpages of instructions for AOL, for instance.

If your email provider doesn't offer secure POP3 or IMAP, well ... that's pretty close to unacceptable nowadays. I'd seriously consider moving to someone else. Or only use a web mail service like Gmail that does work with SSL when you're at the coffee shop.

When it comes to sending email from a coffee shop, things get a bit more complicated. Many coffee shops, due to the way they've set up their networks, only allow you to send email using their ISP. Some of those ISPs might offer secure SMTP, but it's a sure bet that the guys and gals behind the counter making your coffee won't have the slightest clue what settings you should use. So what to do?

If you're really lucky, your ISP allows for secure SMTP and you can use that from the coffee shop. This probably won't work, though. In my case, Gmail to the rescue again. Yes, Gmail is a web-based email service, but you can configure your email program to send email securely using Gmail, which is fantastic. The Gmail Help Center has several pages devoted to showing you how to set up a wide variety of email programs so that they can send email securely using Gmail. In my experience, I have yet to be stymied when using this service. Give it a try.

IM

AOL Instant Messenger (AIM) is the most popular IM program in the world. Unfortunately, all messages are sent completely wide open, so that anyone can read them. Not good at all. But MSN Messenger is the same. And so is Yahoo! Messenger.

You could use Skype, which encrypts all IM messages, although that program - and its parent company - has its share ofunanswered security questions. Not to mention, Skype is a totally closed system, so anyone you wish to IM with must also use Skype. The Gizmo Project is another contender (like Skype, it features its ability to make phone calls over the Net, but it will also IM), and the company claims that it offers secure IM, but its answers to questions about security are completely unacceptable, bordering on ignorant.

If you want to encrypt your IM conversations, there are many solutions out there. Most cost money, though some are free. Search Google for "im encryption" and you'll find plenty of things to check out.

A solution that I can recommend, however, is to use free IM software that supports encryption such as GAIM, an open source software project. GAIM runs on all the major operating systems, it's free, it's powerful, and, even better, it supports all the big IM networks. This means that you can use GAIM to talk to AIM users, MSN Messenger users, Yahoo! Messenger users, Google Talk users, and even more. Best of all, it supports protected messaging through the Gaim-Encryption plugin. Install that, and you can chat with other encrypted IM users, through whatever network you like, and the conversation will be secure. Other uses don't need to be using GAIM either, just a similar IM application that supports the same encryption. In a similar vein, Off-the-Record Messaging is another plugin for GAIM that will also encrypt IMs, no matter what network you're using. Either way, you're safe.

Conclusion

It's possible to use your laptop safely in a coffee shop, but you have to take a bit of responsibility for that security. You'll need to use your common sense, change a few habits, and perhaps install and use some new software. I know that this is a lot for most people, but aren't your private data and conversations worth it? And if you have any questions, you know who you can call. If you're a security professional reading this column, why not show it to the Philips in your life and offer your help; if you're a Philip, try the advice in this column, and feel free to ask the computer person in your life for aid. I know they'll be glad to help.

See you at the coffee house!

10 Things to Learn Next Year

It's almost the end of the year, which means that the usual flood of "Top 10", "Year in review" and other backward-looking articles are here. Retrospectives can be a lot of fun and even occaisionally insightful, but in my opinion they are looking in the wrong direction. So, in the spirit of looking forward to a new year, here's my top 10 list. Not things that happened in 2010, but things I want to learn in 2011. Some of these I have already started using but want to master, others are mysterious new toys that have grabbed my attention if not my time.

10. HTML5. The importance of HTML5 cannot be overstated, IMHO. With support for the Canvas object, video, geolocation, etc, etc, HTML5 is already changing the web in surprising and innovative ways. The best part? It's not a new language. All the tags I know and love are still there. There is still a lot to learn, but I don't have to start from scratch. In some ways (like the doctype), HTML5 is even simpler than earlier versions, a refreshing reversal of the usual cruft of complexity that builds up on a language over time.

9. Groovy. Groovy is one of a slew of new(ish) languages that run on the venerable and performant Java Virtual Machine. Groovy borrows heavily from Java's own syntax, flattening out the learning curve for developers that already know Java. So, it runs on the JVM, and it looks a lot like Java. What's the big deal with Groovy? Well, proper closures, for one. A great console, for another. One of the things I LOVE about coding in Python is that if I want to play around with some code I can just start up a Python console and go to work. Java's edit -> compile -> debug cycle seems positively crippling by comparison. Add in the fact that apps written in Groovy can leverage Java's gigantic library of existing components and you have a language that I have to add to my toolbox this year. Oh, and don't forgetGrails. I've built a couple simple apps with it and I think I'm in love.

8. The ins and outs of cross-platform mobile development. Compared to the whole of computing, mobile applications are still in their infancy. Without getting into the growing pains this market is going through (Apple's walled garden, Verizon Android crapware, etc), there is one big challenge as a developer. What platforms do you support? What language(s) do you develop in? Is it worth it to build both Android and iOS apps? Do you even have the resources to do so? Companies like Appcelerator aim to make this easier by creating cross-platform dev tools for popular mobile device platforms. I want to make my apps available to as broad an audience as possible without the headache of maintaining several codebases. This is a space to watch.

7. A NoSQL database. Most of the platforms I work with rely on relational databases. They work. MySQL / Oracle ( the two I work with most frequently) are mature, stable and perform well enough when properly tuned. But, like any tool, RDBMSs aren't the right solution for every problem. They can be expensive to scale quickly, and frankly I don't always need a well defined schema. Sometimes I just need a persistent store for some simple objects. Now that CouchDB is available as a client-side DB for Android, I can see quite a few interesting applications for this technology. If iOS support comes through then we have another choice for cross-platform data stores.

6. Arduino. What the heck is an embedded processor doing on a top 10 list for a web / mobile developer? Well, the Arduino is simply one of the coolest things I have ever seen. It's open source. It's cheap. It's easy to program. It's capable of surprising feats. I have an Arduino Mega sitting on my desk just begging for the right project. I had originally intended to use it as the brains behind an automated bottling line for my homebrew, but decided that kegging was much more practical :-). Right now it is hooked up to a 2 line LCD display and a couple of blinkenlights, just waiting for inspiration to strike.

5. GIMP. This is one of those tools that I already use constantly but wish I had a better handle on. The GIMP is a great image editor for the price (free), and I use it all the time for creating iPhone buttons, logos, splash screens, etc. If you just need to slice and dice some PNGs for the web it is a great option. In the next year I want to hone my design skills and GIMP-fu.

4. Tropo. Tropo is a telephony platform that runs in the cloud. If you want to add SMS or voice functionality to a web application, Tropo takes all the guesswork out. They build the infrastructure and provide the APIs, you build the cool stuff on top of it in your choice of Ruby, Python, JavaScript, PHP or Groovy or your language of choice by calling their REST API. Oh, and did I mention that it is free for developers?

3. Django. This is another one of those tools that I have worked with occasionally but haven't ever really mastered. In particular I want to use Django running on the Google App Engine to build some simple scalable web services. I haven't ever implemented a REST API in Django, but need to learn.

2. Alfresco. I use Alfresco constantly. It's a big part of my day job and I have even written /contributed to a few open-source components that exist in the Alfresco ecosystem. However, it's a huge product. It provides so much functionality that I feel like I only know / use 10% of what it is capable of. Maybe with another year of hard work I can bump that to 20%.

1. Time Management. As evidenced by the list above, I have more ambitions than time. To get all of this done I will need to focus on what is, in my opinion, the single most important tool that any developer or engineer can learn. This is one of those critical life skills that almost everybody has room to improve. If I only get one thing done next year, this should be it.

Smartphone Browser Landscape

Users expect websites to work on their mobile phones. In two to three years, mobile support will become standard for any site. Web developers must add mobile web development to their skill set or risk losing clients.

How do you make websites mobile compatible? The answer is obvious: By testing them on all mobile phones, and by solving the problems you encounter. But, that’s a useless answer. It’s impossible to test your designs on every mobile phone out there. Within the mobile phone landscape, there are at least ten operating systems (OSs) and fifteen browsers that require consideration. Mobile devices are expensive, and not every web developer can afford to buy five to ten of them. Testing “on all mobile phones” is impossible for most web developers.

In this article, I’ll give you an overview of the mobile web market, as well as phone platforms and their browsers, so that you can decide which mobile devices to test on. Then, we’ll look at how to set up a mobile test bed.

The smartphone market

Web developers should concentrate their testing efforts on smartphones. All good mobile browsers run on one smartphone platform or another. (Few non-smartphones have good browsers. That will change, but for now it’s true.) This begs the question: What is a smartphone? Here’s how I paraphrase the mobile industry’s more-or-less official definition:

A smartphone is a phone that runs a recognizable OS on which the user can install applications.

The smartphone market is divided into several submarkets, each of which has a distinct audience. For more information, read Tomi Ahonen’s articles on smartphone consumers andsmartphone market share.

Smartphone market overview

MARKET	SHARE	OSS	CONSUMERS
High-end	20%	iOS Android webOS MeeGo Windows Phone 7 BlackBerry OS6	Within the high-end group, users care about web surfing and applications above anything else, and they’re willing to pay for these features.
Business	35%	BlackBerry Symbian Windows Mobile Windows Phone 7	The business group includes phones that companies buy for their employees. The IT department decides which OS can access the company network so that users can retrieve e-mail and browse secure intranets.
Mid-range	45%	Android Symbian BlackBerry bada Windows Mobile	Within the mid-range category, users are interested in music, a good camera, and/or easy texting (which requires a hardware keyboard)—all in an affordable device.

Notes:

• In 2009, about 175 million smartphones were sold worldwide. The market is expected to grow by 90% this year.
• Android is moving into the mid-range market with devices such as the Vodafone 845that have cheaper, less powerful hardware.
• Now that Microsoft has released Windows Phone 7, Windows Mobile will disappear.
• MeeGo was not available at the time of this writing. It is likely to hit the market in the first quarter of 2011.

A game of platforms

The current fight in the mobile world is about platforms. While the operating system is the most important ingredient of a platform, app stores and browsers are also important.

A platform competes with other platforms in its market, and that’s where it gets interesting for web developers. Every platform has its own default browser, and if a certain platform should win the war, its browser would gain a large market share and force web developers to pay attention to it.

In the high-end market, iOS and Android are the current front-running platforms. However, in 2011, they may get competition from Windows Phone 7 (Microsoft) and MeeGo (Nokia). BlackBerry OS6 (RIM) may try to enter this market, too.

ATTENTION MUST BE PAID

The problem is that most web designers and developers (not to mention the entire blogosphere) fall squarely in the high-end market. A cultural bias exists against OSs aimed at any other market. As a result, most people focus on the struggle between iOS and Android, and ignore the rest. This has to change.

In the mid-range market, Symbian (Nokia) is dominant right now, but bada (Samsung), BlackBerry (RIM), and the new mid-range Androids (Google) are strong competitors.

The business market is conservative. Although iOS tries to penetrate this market, and Android presumably wants to do the same, they haven’t yet succeeded. BlackBerry and Symbian continue to rule, with a smattering of Windows Mobile on the side.

The situation is complex, especially for someone who’s just starting out with the mobile web. I’ve created a mobile market overview table to help you make sense of it all.

The mobile browser market

Although the platform wars will, in large measure, shape the future mobile browser landscape, web developers are likely more interested in the present environment. Let’s take a look at the current mobile browser market.

There’s only one source of mobile browser market share information: StatCounter. It does have its limitations: Their browser classification is sometimes strange, and the sites on which they measure traffic select themselves by subscribing to the service. Still, there is no other source of data. So what does StatCounter say for November 2010?

Global browser stats for November, 2010

SHARE	BROWSER	NOTES
22%	Opera	StatCounter lumps Opera Mini and Opera Mobile together. My personal estimate, based on discussion with Opera, is that about 90% of this number is Mini.
22%	Safari	StatCounter splits up iOS into iPhone, iPod Touch, and iPad. It includes iPad stats with the Safari desktop—not in the mobile statistics. Therefore, this figure excludes the iPad.
19%	BlackBerry	This encompasses mostly the OS5 and older models, which run a browser with a homegrown rendering engine. From OS6 on, BlackBerry uses a WebKit-based browser, and that will make our job a lot easier.
17%	Nokia	Nokia’s WebKit-based browser comes in various flavors, some of which are better than others. Unfortunately StatCounter does not differentiate between each flavor.
11%	Android	The Android market is pretty fragmented when it comes to browsers. There are some subtle differences between browsers on HTC and Sony Ericsson devices. Expect problems to arise from these inconsistencies.
4%	NetFront	NetFront runs mostly on older phones from Asian vendors, notably Sony Ericsson. This figure includes the Sony PlayStation Portable as well as other gaming devices.
1%	UCWeb	The most popular browser in China. It offers little functionality.
1%	Samsung	StatCounter lumps all Samsung browsers together, from old NetFront-based phones to the new WebKit-based bada.

These are global stats; traffic shares differ quite a bit from country to country. Find your own country’s stats before deciding which browsers to support. You may want to study your client’s log files to learn which devices people are using to visit the site.

If you’re interested, compare these traffic share stats to sales share stats reported by Gartner; you’ll discover many differences.

IPHONE DOMINANCE

If you compare the traffic and sales share stats, you’ll notice that Safari for iOS’s traffic market share is out of proportion to its sales market share. Keep this fact in mind while building mobile websites, but don’t use it as an excuse to test only on the iPhone.

There are two reasons why the iPhone dominates: First, iOS is the first platform created specifically for mobile web surfing. As a result, people who want to surf on their phone choose the iPhone (or, sometimes, Android). Second, Apple made sure that those who bought the iPhone would get a flat-fee data plan which encourages web surfing.

The flat-fee data plan will disappear with time because it is economically untenable. Consumers revile T-Mobile in Europe and especially AT&T in the US because these carriers cannot always maintain good data connections (or even voice connections) for iPhone users. They have no economic incentive to improve their service because more iPhone data traffic doesn’t generate more income for them. So why bother upgrading the network?

For this reason, as well as the increasing popularity of other OSs, I feel that the days of iPhone dominance are numbered, although I cannot predict how quickly that will happen.

The best mobile browsers

So what are Safari’s main competitors for Best Mobile Browser?

Currently I rate four mobile browsers as “Excellent,” my highest rating:

1. Safari for iOS—the best mobile browser overall,
2. Android WebKit,
3. Dolfin for Samsung bada—by far the fastest mobile browser, and
4. BlackBerry WebKit, the new default browser for OS6 and higher. (Currently only available on the BlackBerry Torch.)

All four browsers support touch events, which are absolutely crucial to any seamless touchscreen-based interface. Also, they are all based on the WebKit rendering engine. Apple created it, and Google, Samsung, and RIM made it the starting point for their own browsers. (As did Nokia, Palm, and most recently LG.)

THERE IS NO UNIFIED WEBKIT ON MOBILE

However, WebKit and touch events do not necessarily make an excellent browser. Recently, LG released Phantom, a browser for low-end phones. Despite the fact that it’s WebKit-based and supports touch events, it is not very good.

This underscores a general rule of the utmost importance to web developers: There is no WebKit on mobile. I tested nine mobile WebKit-based browsers and they all behave differently. Not wildly so: Baseline CSS support is good, and JavaScript is definitely workable. Still, each one has its problems and strong points.

Because of this variability, it’s important to test your websites in as many WebKit-based browsers as you can. Don’t assume your website will work on the Android or BlackBerry WebKit-based browsers just because it works in Safari.

The good browsers

The Apple, Google, Samsung, and RIM default browsers form what I call the Excellent class. Below them is what I call the Good class: this includes Opera Mobile, Palm WebKit for webOS, and MicroB, the Gecko-based default browser for Nokia’s Maemo OS, which will soon be replaced by MeeGo.

These browsers do not support touch events, and zooming varies in each implementation. From a pure CSS and JavaScript point of view however, you’ll encounter few problems.

Of the three, Opera Mobile is the most important, because it serves as a default browser for many Windows Mobile devices where the vendor decided IE wasn’t good enough. Currently, it’s an alternative for Nokia WebKit on Symbian, the largest mobile OS.

OPERA MINI

Opera Mini is an extremely important browser and you should definitely test your sites with it, because of the unique way it handles web surfing. It’s available for iOS and Android, as well as a host of other OSs.

Opera Mini is different from all other browsers we’ve discussed so far, including Opera Mobile. Where the other browsers just download the HTML, CSS, and JavaScript, interpret it, and render it, Opera Mini does something quite different. When you request a page in Opera Mini, that request goes to a special Opera Mini server. The server downloads the assets, interprets them, and renders the page. Then it sends back an image of the resulting page to your phone. You view the image via the Opera Mini client.

The advantage is that the Opera Mini client needs very little memory, which makes it especially suited to low-end, inexpensive devices. In addition, the actual data download consists only of a highly compressed image.

Opera Mini’s disadvantage is that it offers no client-side interactivity: If clicking on a link fires a JavaScript event handler for some Ajaxy goodness, Opera Mini goes back to the server to ask for instructions. The server handles the script and sends back an image of the updated page. However, it is important to note that this is a feature, and not a failure. For many people around the world, giving up client-side interactivity saves a lot of money, both in device and data plan costs.

Opera Mini is not the only mini browser. The most popular Chinese browser is UCWeb, which works on similar principles. I believe its homegrown rendering engine is lousy—in some situations it can’t even handle a simple link. Their switch to WebKit is only a matter of time.

NOKIA WEBKIT

In the first year of sales, Microsoft sold 240 million copies of Windows 7. Many of them shipped with IE8, of course. In 2009, Nokia sold 432 million devices. Over half of them had a Nokia WebKit browser as a default.

In other words, last year more copies of Nokia WebKit were pushed into the market than IE. Nokia WebKit is staggeringly huge. Still, its traffic market share is modest; the average Nokia user doesn’t surf the web nearly as often as the average iPhone user. That could change, though, and your websites must be ready.

There’s an older Nokia WebKit browser that runs on the S40 (the low-end OS) as well as older Symbian devices (up to S60v3 feature pack 1). There is also a newer Nokia WebKit browser that runs on newer Symbian devices. The latter is a bit odd, but workable. The former is more difficult. If you’re not sure which browser your Symbian phone has, run the Acid 3 test. The later browser will score around 50, while the earlier one will fail completely. Stephanie Rieger has written a great series of articles about Nokia WebKit that’s full of stuff you need to know.

Sites aimed exclusively at the US/Canadian market can mostly ignore the Nokia WebKit browser. Nokia has negligible market share in North America. Sites aimed at audiences in other regions should be tested on this browser, however.

OLD BLACKBERRY

Before OS6, BlackBerry ran its own homegrown browser, which was not a success. Unfortunately, the vast majority of BlackBerry owners still have this older browser; OS6 has hardly hit the market yet. But that’ll change.

JavaScript performance is the biggest problem with the old BlackBerry browser. (It’s pretty much absent.) On OS4.6 and before, this problem was almost unsolvable. OS4.61 and higher offer at least some script functionality, but it’s very cumbersome up until OS6, so you should just forget about scripting entirely for older BlackBerry browsers.

WHAT ABOUT IE?

I’ve already covered several browsers that I urge you to test your site on—the total test browser count is already higher than for the average desktop site. There’s a ray of hope between all the gloom, however: IE doesn’t matter on mobile.

The default browser in Windows’ Phone 7 is based on IE7 and incorporates some IE8 features. That’s better than Windows Mobile’s default browser, which is based on IE6. Older versions are based on IE4. Although Windows Phone 7 could become a hit, I believe it won’t ever command a 65% market share as it does on the desktop. I estimate that, in time, Microsoft will conquer 10 to 15% of the smartphone market, tops.

So the question becomes: Do we web developers dust off our IE knowledge, and force IE users to download extra style sheets? Do we force all users to download IE code branches over a mobile connection? Or do we ignore IE? I’m in favor of the latter.

Microsoft is aware of this problem, and knows it can make IE Mobile matter by upgrading it to IE9 levels. In fact, this is being done right now. If all our sites suddenly work in a future version of IE Mobile, all the better! And we might even start testing on it. But we’re not required to laboriously work around one IE bug after another, as we do for the desktop.

OTHER BROWSERS

There’s a few other browsers that you can ignore right now but that could conceivably become important in the future:

• NetFront is still used widely on older Samsung and Sony Ericsson devices, but it’s way behind the other browsers and will likely disappear in the not-too-distant future. A word to the wise: Ignore NetFront. It takes a lot of effort to support it.
• Obigo is LG’s browser of choice, and it is serious about keeping up with the other browsers. Where up until version 7.x it had its own rendering engine, it is now switching to WebKit. The first WebKit-based Obigo browsers are expected in early 2011.
• An Android beta of Firefox is available, but it still lacks important mobile features such as touch events. Mozilla’s bigger problem is that mobile users will not download another browser just because they can. So I think you can safely ignore Firefox for now, although that will change if a device or platform vendor starts using Firefox as its default browser.

Your mobile test bed

Now, let’s apply your new knowledge of platforms and browsers to create a test setup you can use.

START TESTING

Start testing right now. Sure, you may only have one or at most two phones to use, but you will learn a lot just by viewing your site on any phone.

The most tricky mobile problem is one you can address right away: The tiny display. Every mobile phone has a tiny display by desktop standards, and your site needs to fit in it. Start experimenting immediately. Don’t worry that your devices are not representative of market share. Any mobile test is better than no mobile test.

GETTING DEVICES

Then it’s time to shell out some money. You probably already have an iPhone or Android. Buy a BlackBerry or a Nokia Symbian—whichever is more popular where you live. Choose a medium-new, popular model. This will represent the smartphone masses that rarely browse the web—yet.

If you don’t have a big budget, buy a Nokia or BlackBerry non-touchscreen device. If you have money, reserve some for a non-touchscreen anyway. Not all users have a touchscreen, and you should definitely get acquainted with other input modes. If you have budget left for a third or even a fourth device, consider any platform I already mentioned, bada, Windows Phone 7, or Windows Mobile. Pick the one or two that have the greatest market share in your part of the world.

INSTALL BROWSERS

Go through my browser list and install absolutely every browser you can download on the devices you already have. Pay special attention to Opera Mini and UCWeb.

TEST SERVICES

By now you have two to four devices with maybe six to ten browsers in total. If you still have a budget left, buy more. Without a budget to buy devices, you have two choices: test services or emulators.

The two main test services are Device Anywhere and Perfecto Mobile. Compare them and decide which one you like best.

These services have rows upon rows of mobile phones lying in their labs with webcams pointed at each of them, and you can access them through your desktop browser to test anything you want. This costs some money, but it’s a lot cheaper than buying the devices.

EMULATORS

While emulators are the cheapest way to conduct mobile testing, I admit I’m not a big fan of emulators, because to be really good, the mobile browser has to be ported to Windows (or Mac), and much can go wrong in that process.

Go through the emulator list and install as many as you can. Unfortunately, most need anSDK to run within, which will bloat your computer.

BROWSER LIST

Once you have a mobile test setup and clients who want their sites to work on mobile, make a generic browser list to insert into your contracts. Your client needs to know which browsers their site is going to work on.

Two browsers are inevitable: Safari and Opera Mini. Clients will likely ask for Android, too, and the mobile-savvy ones will insist on BlackBerry or Symbian. Agree on browser versions; this probably depends on the devices, test services, or emulators you have available. There are a few tricky bits here:

• Remember that BlackBerry OS4.6 or lower cannot run complicated JavaScript. Besides, you should let your client know that you may need to switch off the script in later BlackBerries, too. Only OS6 with the WebKit-based browser is safe to support.
• We already talked about Nokia WebKit’s versions. Try to leave out the older version; it’ll save you a lot of headaches.
• There was a major Android WebKit upgrade between 1.6 and 2.0. Make sure your contract specifies which Android version(s) you’re going to test on.

Even if your client only asks for the iPhone, make sure your site works reasonably well on at least one other mobile browser. Never pass up a chance to practice.

Progressive enhancement is your friend

Progressive enhancement is your mobile development friend. Not everything will work on every mobile browser, but that’s OK. Not everything needs work on all browsers. If somebody uses Opera Mini and doesn’t see your animations, that’s acceptable. And be prepared to switch off your script entirely for older BlackBerries.

Progressive enhancement will become widely used once mobile web development becomes commonplace. On the desktop you are forced to keep your IE users happy, but on mobile the situation is quite different. So don’t hesitate to turn functionalities off for some browsers. As long as the user can read the content and use the navigation you’ve done your duty.

Mobile: the new frontier

I hope this huge amount of information has given you a starting point for your own adventures on the mobile web. It’s going to be difficult; mostly because it’s so different from the desktop web. Besides, the detailed browser knowledge that we take for granted on the desktop is not available for the mobile web just yet.

That shouldn’t stop you from experimenting, though. Just try something that makes sense to you. Sometimes it won’t work, but that’s all part of the game. And if it does work, please write about it. Your fellow mobile web developers need the information.

Good luck, and remember: you’re not alone.

Reading list

Here’s a reading list of mobile authorities. Subscribe so that you can stay informed on where the mobile market is heading:

• Tom Ahonen, a former Nokia executive, writes Communities Dominate Brands. This is the place to go for all kinds of stats. Reading his blog will give you a desperately-needed, non-web-centric general overview.
• Cloud Four Blog by Jason Grigsby. Jason is both a web developer and a mobile developer and pays particular attention to the media queries and native vs. web apps debates.
• Vision Mobile is a mobile market analysis and strategy firm that publishes a very interesting blog featuring provocative op-ed pieces.
• jQuery Mobile is John Resig’s latest project. jQuery is the first JavaScript library with a definite mobile browser strategy. The Sencha library is also an option, but it has started out as an iPhone/Android-only library and is only now adding more platforms.
• Yiibu by Bryan and Stephanie Rieger, publishes excellent articles about mobile web development and the various Nokia browsers. The site as a whole is an example of how we should go about mobile web development.
• Luke Wroblewski is a web designer with a specific interest in mobile. His touch gesture diagrams are especially interesting.
• WAP Review by Dennis Bournique mainly follows the mid-to-low-end market. He is known for exhaustively testing the mini browsers (Opera Mini, UCWeb, and similar ones). Dennis also features new mobile sites found on the web, which you can study for ideas.
• PinchZoom is Brian Fling’s mobile web company. There are many useful articles here.
• The Asymco blog by Horace Dediu follows the mobile market avidly, and has many a good insight to share.
• Mobile Industry Review is another high-level source that covers the entire mobile world.
• @EricssonLabs on Twitter will point you to the most important mobile stories of the moment.
• This Is Mobility is by Mike Rowehl, a mobile developer interested in the web. In addition to following the mobile world, Mike occasionally writes about how the mobile world views the web world, which makes for an interesting change in perspective.
• The Morgan Stanley Mobile Internet Report (PDF; huge) is probably the most complete overview of the mobile web currently available, even though it’s a year old.
• I founded the mobile web mailing list where plenty of thought leaders discuss mobile browsers, the mobile web, the mobile context, and other important topics.
• And finally the mobile section of my own site, QuirksMode. I write about the mobile market as seen by a web developer, including some densely technical topics that will become required knowledge for mobile web developers.