It was horrible.

It wasn’t just sort of bad either.  The category of “abysmal” comes to mind, but only if there were actually enough public web sites to actually form categories back then.  There weren’t.  Actually, all the sites back then were as horrible as only the early-90’s era web could be.  They were meant to run on NCSA’s Mosaic and share basic information (usually a photo, my university e-mail and research links).  Of course it didn’t really matter as they were being rendered on ancient university computers the processing power of which we marvelled at because they could also run MATLAB, do word processing and possibly draw some black and white images (not at the same time of course).   

It wasn’t just the computers, it was the network.  The pages were being sent over fairly slow university networks, possibly via my SLIP connection or, *GASP*, AOL or Prodigy, and a speedy 28.8 or 36.6 modem… maybe faster if money was no object and you got lucky.  Animated gifs (remember those?) loaded slowly… but once they did we could all get a good chuckle about the animated dog running back and forth at the bottom of the page or the dance of numerous small fuzzy rodents filling the screen.

The bad news is that there were limits, the good news is that there were limits.  That isn’t a typo.  Limitations and constraints make us think about what we’re doing.  It forces trade-offs and, possibly, leads us to a more rigorous thought process where we are forced to make choices.  Fast forward 15 years and the world of the web has less limits.  We now face a gap that is forming between what designers and developers can do and the systems users use to access those web systems.

For a (hopefully) brief moment in our history, we are being thrown backwards as the mobile web becomes more important and the capability gap of mobile devices vs. their desktop/laptop brethren are painfully obvious.  Once again economy of design and speed are important.  The first mobile phone call was made by Martin Cooper at Motorola in 1973.  He first called a competitor at Bell Labs, presumably to gloat, much like associates who acquired first generation iPhones in 2007. Now we have mobile web browsers on devices such as Blackberries and iPhones and a growing dependence on mobile technology.  Mobile subscriptions worldwide have far exceeded those of fixed lines.  Some estimates put those mobile subscriptions at 4x more than landlines, while also growing at a faster rate than landlines.

Unfortunately, many designers and developers are simply trying to make web sites that have the most flash, features, buttons and advertisements in an attempt to monetize their content, create traffic to their web site, generate leads or meet some other business goal.  Many of the aspects of these sites can not be utilized by mobile web browsers. 

Sure, maybe the iPhone users can view your “awesome” flash-based web site, with some work, but everyone in the world doesn’t use iPhones.  Designing just for the iPhone is the equivalent of designing for a particular browser, instead of testing for cross-browser compatibility.  Notably, in the United States, iPhone users are stuck on AT&T’s 3G network which is abysmal and unpredictable… faster than dial-up in 1994, yes, but only when it works.  Apparently this is helped by praying for forgiveness to Steve Jobs nightly for that old PC you still use from time to time. 

Also, many phones don’t have the horsepower or compatibility to look at your flash-based web site.  As a matter of fact, maybe you didn’t know, Mr. and Mrs. Designer, your site actually crashes some browsers on regular desktop computers.  The fact that it locks up many of our mobile web browsers should be obvious. 

It is time once again to reconsider what good web design is and consider anew how to best approach building or repurposing web sites for mobile.  Some of the lessons of the “old days” of the web can still be instructive as we wait for mobile devices to catch up to the modern web.  Content is still king (well, services too) and economy of design, AKA “less is more”, is still the best philosophy.  If the web is about content and applications to utilize that content then the central system to your mobile strategy should be a Content Management System (CMS).  I am continually amazed at how many international companies do not have a CMS.  They have plenty of content, but they horde it, serve it up in a single language, don’t repurpose it for the web and generally have poor work flows for updating the content. 

These are well known problems a CMS can help solve, along with a group of people in the organization committed to change.  Multi-platform content distribution applies to mobile devices as well, no surprise.  Mobile devices are almost a language unto themselves, they require that we translate our sites so that they can understand, often with WAP or WML, but most importantly with the way we produce and distribute content and services.  This would be tedious to do by hand, but with a CMS it becomes much easier and will help bridge the gap between mobile devices and the latest web content and applications.

Almost all of us have personally identifiable information stored in a database somewhere on the Internet.  Quite commonly this information is stored in the public view in the form of social networking sites like Facebook or Twitter.  However, the real litmus test of data sensitivity for consumers is whether or not the information may be used to compromise the user’s identity.  There are certain security standards in place to help with this such as HIPAA or PCI.

Your web host is PCI compliant.  You’re using Zen Cart, osCommerce, or a COTS e-commerce solution.  Your database is mySQL and you have SSL running to protect the transport.  By all practical measures your e-commerce environment is secure. 

However, if a compromise should occur no one can steal your customer’s identity by simply finding out their name and address.  Anyone can find that easily via the white pages, Google or any number of other mechanisms.  To steal my identity, the attacker would also have to also know something unique about me.  In fact, they may need multiple unique pieces of information to effectively steal my identity (my billing history, my SSN, mother’s maiden name, etc.).  Anyone can get names and addresses from any list provider.
 Credit reports with billing information can be had.  The brokering, and compromise, of SSNs has been around for a while… maybe you’ve heard of the ChoicePoint debacle?

The latter is the worst, because if a database is compromised, and SSNs get out in the open, they are very difficult to change.  If a piece of data, like a credit card, is compromised then the problem can be contained.  Simply change the number, reverse the charges and open a criminal investigation.  If an SSN is compromised, it cannot be changed easily and may be utilized until the criminal is caught.  The criminal may also sell this data to others. 

The risk to any company collecting data is enormous, but even more so when collecting SSN data.  The question of how to shift this risk is answered by the process used for collection and whether or not the data is stored.  There are ways to protect the SSN using well known techniques like AES encryption.  These are built into some databases or can be coded fairly easily. 

Unfortunately to decrypt the data, to view the clear text after initial encryption, requires a developer to use encryption methods which allow for the data to be decrypted.  This mechanism can also be attacked by compromising a password for the administrative interface where the SSN is viewed.  If an authorized human can view it, a hacker could view it also.

For something with a well known pattern, like an SSN, it is also possible to do a brute force or dictionary attack to compromise the SSN if the encryption algorithm is known or can be guessed. 

Let’s say a hacker, we’ll call him Bob, compromises your database and gains access.  However, you have encrypted the data using a built-in algorithm.  Good for you, the clear text identifying data is not in the open… yet.  However, Bob knows there are a few limited mechanisms used for encryption (AES for example).  Bob also knows there are a limited number of numeric combinations for SSNs.  So, Bob can write a program to run through all possibilities, encrypt them with various algorithms, and then match the encrypted string in your database.  By matching these, Bob knows what the SSN is because he knows the starting clear text.  Because the information is stored in the same DB Bob also has matching names and address data.  Obviously, if it is stored in clear text, Bob has a much easier time.

So, how do we defeat Bob the hacker?  Here are some suggestions and more are welcome:

•  Use an API from a credit reporting agency.  This shifts the risks to the credit reporting agency because the SSNs are never stored.  You can still do a credit check based on information entered by the user.
• Add “salt” to the original SSN string if you are storing an encrypted version.  This can be done at time of encryption and means the dictionary attack won’t work in a feasible amount of time with a strong salt value.
•  Set up a separate encrypted database for SSNs.  This keeps the data separate from your main e-commerce system and allows additional security measures to be put in place.

The good news is that hackers don’t often waste their time on small and medium sized companies, unless they are small to medium sized hackers.  The prize is simply not big enough.  Unfortunately, automated scripts can help hackers find vulnerabilities to exploit, which includes your web site.  Follow some of the suggestions above and you can feel more comfortable conducting business online where SSNs are required as part of the transaction.