Island Web Works

Microsoft have steadily been losing browser market shares ever since Mozilla introduced its Firefox browser, dropping from an impressive 91% in 2004 to a humbling 56% in January 2011. Microsoft’s release of IE7 in 2006 and IE8 in 2009 didn’t do much to stop this decline, especially with Google Chrome entering the arena in 2008, but with their latest browser Internet Explorer 9 they hope to turn the trend. So what can we expect from this new browser?

Pin a web site to the taskbar to access a jump list of links to key areas of the site.

Well, with version 9 IE is much more compliant with web standards (95/100 in Acid3, up from 21/100 for IE8), which means web designers hopefully won’t need to implement IE specific code to get their web sites to display correctly in IE9. It also supports the latest versions of style sheet and markup languages (CSS3 and HTML5), so it should be fairly future proof. In addition, IE9 is much quicker to render web pages and it sports a new font rendering engine which makes text appear nice and smooth. The user interface has also been overhauled, with a slimmer and more streamlined appearance and some nice new features like pinning sites to your taskbar for additional functionality (Windows 7 only).

This all sound good, and most IE users will probably upgrade, especially as it will be part of Windows Updates later this month. However, a problem arises for users of IE6. Since IE9 is only available for Windows Vista/7, and all IE6 users are on Windows XP or older, they are stuck and can’t upgrade. This is particularly annoying since Microsoft have launched their ‘The Internet Explorer 6 Countdown’-campaign urging people to move away from IE6 and upgrade, but the only version on offer is the already 3 year old IE8.

Education - not dictation

We at Island Web Works are all for putting an end to the usage of IE6, but we won’t be putting Microsoft’s ‘Upgrade your browser now’-banners on any of the sites we produce. Getting IE6 users to upgrade to IE8 is not a solution, as they would still be stuck with an obsolete browser. Instead, we would rather educate people about the benefits of upgrading from Windows XP to Windows 7, something that is already happening in the private sector as people replace old PCs with new ones.

In the corporate sector however the situation is slightly different. Apart from the cost of upgrading multiple workstations, there might be legacy applications in use that only work in Windows XP/IE6. Luckily there is a solution available. Windows 7’s XP-mode allows you to run legacy software in a pre-installed virtual PC application, which comes complete with a licensed version of Windows XP. This makes running legacy applications a doddle, and should allow businesses to take the plunge and upgrade to Windows 7/IE9.

XP mode - old and new in perfect harmony

So, the signs for the IE9 are encouraging, and with more than 40 million downloads so far it has stopped the downwards trend of IE. It is still early days, but Microsoft seem to have created a modern and solid browser, which hopefully will replace the older IE versions as soon as possible and allow the web to become standardised.

Andreas Web Site Development Internet Explorer 6, Internet Explorer 9

In the beginning of the World Wide Web, developers discovered that in order to get web shops to work properly they needed to store little pieces of user information. To solve this problem, they invented the HTTP cookie – small text files sent from the web site to the browser, stored on the users local machine, and available to be retrieved by the web site.

This soon caused controversy with users panicking about their personal information being accessible to malicious web sites to track their browsing activities. In response, browsers had settings added to them allowing users to not store any cookies, or only cookies they trusted. The dust settled, the web matured and today many sites (including Google, Facebook and YouTube to mention just a few) use cookies to allow users to login to their personal web site accounts, or to enhance the user experience.

However, this is soon to change: the EU’s European e-Privacy directive that comes into effect on 25 May this year states that the use of cookies and similar technologies will need explicit permission from the web site visitor. This means that web site owners can no longer rely on the user’s browser settings to see if they will accept cookies.

What consequences will this legislation have? Well, firstly, owners of web sites operating within the European Union will have to make sure that their web sites provide clear and comprehensive information regarding the use of cookies. This includes stating why cookies are used and how the information is processed. The web site also need to give the user the option of opting out, and making sure no cookies are then dropped on the users machine.

Secondly, the web browsing experience for the user will become more complicated and cumbersome, where the user will have to actively approve the use of cookies whenever he/she arrive at a site. Expect to see a dramatic increase in popups and mandatory checkboxes all over the web. Also, if users make the “wrong” decision and block cookies by mistake, they can expect only a subset of the features on the web site to be available due to technical and/or financial limitations.

And thirdly, the only sites not affected by this are the ones who deliberately ignore regulations anyway in order to spread 3rd party tracking cookies to collect as much data as possible. Ironically, they will be the sites that are the simplest to use, potentially tricking users to believe that they are browsing on a safe site, which I don’t believe was the original purpose of the directive.

Additionally, any extended development requirements could result in extended development time, which in turn would increase project costs. A way to avoid this would be to use technologies such as ASP.NET in cookie-less operation mode. Luckily, this is the default language in use by us in Island Web Works.

Sites hosted outside the European Union are not affected by these regulations, but similar proposals are being supported by the US Federal Trade Commission, so it might only be a matter of time before this applies to most web sites. This could well be the beginning of the end for the humble HTTP cookie.

Andreas Web Site Development Cookies, e-Privacy directive, EU

We’ve blogged before about how you know whether to trust a web-form. We highlighted that sites capture personal information and often ask you for a username, email address and/or a password. The odds are that you will use the same password on the site as you have on many other sites. Everyone does it, right?

Once you have registered with the site, after convincing yourself of a certain level of trust in the site owner, you might not think that even if the infrastructure of the site is sufficiently secure that no-one could ever hack in to your personal data, that the site would then broadcast – in plain text – your username and password. That would be crazy!

This is what recently happened to me. While using a leading retailer’s online presence, I was sent a “courtesy” email containing my username and password.

But if they emailed you the details, that’s private, surely? Not at all. If someone knows enough about you they may have a good attempt to hack your email password and they then know an awful lot more than a few passwords. Equally, I often have to explain to people that email is not like a telephone conversation. Your emails get passed, bounced, redirected and filtered through any number of servers before it gets to the recipient’s inbox and it is all in plain text. Every one of those servers (and there is no policing of what servers may be allowed to route across the internet) can take a copy of your email. The recipient’s machine may already be compromised by malicious code such as viruses, harvesting personal data and transmitting it “back to base”.

So what’s the answer?

The User’s responsibility

It’s easy to say you should have different passwords for different web-sites. I’m betting you wouldn’t be able to name all the web-sites you registered with in the last month, let alone remember the unique passwords you applied to each of them!

There are options available, though. You could create a tiered list of passwords. High-security passwords for your email (distinct from your banking), moving down to weaker and easier to remember/relate for less important/trusted sites such as forums, etc. It would certainly be a good idea to keep separate passwords for your email, banking and any sites that store your credit card information. Maybe another password for your social media life (Facebook, Twitter, etc.) and “throwaway” passwords for other sites which you may not even return to.

Another option is to use a tool such as KeePass or LastPass. These securely store your password either locally on your machine in a heavily encrypted file or on the cloud, so you can access your passwords anywhere. KeePass is particularly useful when working with particularly secure passwords such as server login details as you can add multi-factor authentication (eg. a USB key). LastPass is more orientated around the web-user, providing browser extensions that help retain form information including passwords. This allows you to generate unique passwords as you need, or at least manage a larger number of passwords that you use infrequently.

The Web-site’s responsibility

The web-site’s responsibility is two-fold. First, it must store your password securely, second it must not compromise that password.

Storing your password securely ideally means generating a one-way hash from it. Your password is taken (over a secure HTTPS connection, of course) and put through a mathematical algorithm which produces a seemingly random sequence of bytes. So a password “LetMeIn” becomes “bc9d9cb353c87531f61d6f21d5cc072e”. What’s important is that this method is different from encryption because it is not feasibly possibly to reverse the output sequence of bytes back to the original password. Your imaginative password remains secure! However, depending on the algorithm used, this is not without its problems. The possibility of collisions (multiple passwords generating the same hash) and ability to authenticate using a hash (meaning you only need the hash, not the original password) can pose problems for site owners. It’s up to them how they work with these risks, if they are deemed sufficiently important. Some sites may use encryption, but encryption is reversible and all you need are the keys. There should be no reason why a site would need to know the original password.

While a web-site may be hosted in secure data-centres, with ISO certification, behind firewalls, PCI policies and the like, these measures are rendered useless if your password is compromised. Unfortunately, this happens a lot in sites, as we have seen above. Many sites send your details out in an email, which may be hacked into or “wire-tapped” by an intermediate server or process. (Paradoxically, it is actually more secure to display your password back to you on the screen over an SSL connection than to send it in an email. The downside for the site owner is that this often requires a lot more effort.)

As the site owner doesn’t “know” your original password, actions such as emailing you your forgotten password become impossible. This is why sites send you “activation links”, which have time limits. You request your password using known information (essentially publicly available) such as your email address, which is used to send a unique code that may be clicked on for you to enter a new password. This is protected by your email password (you need access to your email to click the link), is often time-sensitive (the link will only work for an hour or so) and when using SSL is encrypted. This is always the method Island Web Works recommends our clients to use.

Remember, it only takes one compromise in security to trash a brand.

admin Articles, Web Site Development

You’ve all seen them. As you’re browsing a web site you want to register/submit feedback/post a comment, so you start to fill in the form. Then, just as you’re completing the final required fields you are presented with a string of obscure characters that you need to decipher in order to continue. It’s called a CAPTCHA and it doesn’t believe you’re real.

Come on! That's too easy!

CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart, and it is used to prevent web bots from using the form. If you own/manage a web site with a web form you are probably aware of the problem of spam - non-valid posts that range from annoying to damaging. Since spam posts are generated automatically by web bots it can easily outnumber the valid posts and drown out any useful information. In extreme cases over 90% of all the posts from a web form can consist of spam. This makes managing the responses from your web form very demanding, so different methods have been used to filter out non-human responses.

A study in spam

Recently, we hit that particular problem with our own web site. We have a ‘call to action’-form where the visitors can request further information about the services we offer. As expected, without any kind of filtering mechanism we got a huge number of spam posts, so we decided on adding a CAPTCHA to the web form.

First, we wanted to try a more transparent version, with no obvious CAPTCHA visible to the user. Method one consisted of a invisible input field which – if filled in – would invalidate the form post. The logic behind this was that web bots would see the invisible field as just another form field, and since they usually fill in all fields in a form to make sure they covered the required ones they would inadvertently expose themselves as bots. This worked to a degree, but we still got too many spam posts through.

The next solution was based on a time delay filter. Even the fastest human being would not be able to fill in and submit our web form in less than 5 seconds. By contrast, a web bot would typically complete this task in a fraction of that time, so by filtering out posts generated in less than 3 seconds we should get rid of most spam. Again, this did reduce the amount of spam, but not enough to bring it down to acceptable levels. We’re guessing that web bots might be using a delay of their own before submitting the form in order to mimic a human response.

Final CAPTCHA

In the end, we resorted to implementing a classic text-based CAPTCHA. However, in order to avoid frustrating our users we’ve made it as simple as possible, with only a few characters and very little background noise. Interestingly, even such a basic CAPTCHA has stopped 100% of all spam so far!

How long is a piece of string?

Even if the results of our little test speak for themselves, we are not suggesting that the only good CAPTCHA is a text-based CAPTCHA. It is more a matter of what works for each particular site. What’s more, there are compliance issues with text-based CAPTCHAS where screen readers could potentially struggle to help the user submit the form. Adding an audio code function which reads out the CAPTHCA code would help, but it’s not an ideal solution.

Another method which we want to test in the future is image-based CAPTCHAs: the user would be presented with a collection of images, and then asked to click on a particular image. This could prove to be the least frustrating CAPTCHA for the user, but it requires a huge database of pre-vetted pictures which might make it unsuitable for smaller projects.

In the end, any type of CAPTCHA will make the submission of your web form more difficult, so it is important to strike a balance between acceptable levels of spam and sufficient levels of human form submissions. We’ll keep testing different approaches and post the results, so watch this space!

Andreas Web Site Development CAPTCHA, spam, Turing