Testing a web site is important, and smoke/regression testing would normally be undertaken each time the web site's code is updated or extended. But what about third party code and data on your web site? I was using a shop's store locator and it wrongly identified the two closest store locations to Farringdon Station in Clerkenwell, EC1M. Both Euston Station NW1 and Canary Wharf E14 are further away than the third result, Cheapside.

Intrigued, I zoomed in on the map and the ordering of the first two results swapped. And the data point for Canary Wharf seems to be located in the centre of the City of London, instead of its actual location downriver on the Isle of Dogs. The data point for the first result wasn't even displayed.

So is this a third party problem, or something else? Well, without investigating further you can't really tell, but it's the concept that matters.

This inaccuracy is worrying for a number of reasons:

• Customers may have difficulty locating shops.
• It undermines customer confidence and therefore trust in the brand.
• It indicates a lack of care in the web site's development and may put off online shoppers.
• It could indicate the presence of a security vulnerability which could be exploited to damage the site, its data or its users.
• The same geo-location code may be used for other internal calculations such as marketing data processing that affect business decisions.

If you are including functionality or data from third parties, you need to know when that system or service is updated. This notification requirement should be built into contracts. In this case, the data being returned may be inaccurate, formatted in an unxpected manner or be exposing a fault in your own processing of the data. Undertaking input validation on the data provided by the third party and output validation on what you are about to send back to the web site user need to test for reasonableness as well as more technical checks. Why not cross-check that the first result's postcode is closer than the second and the third?

It may just be a problem with the company's own data, but that's even more worrying.

This weekend I'm going to a fancy dress party with a theme of film actors and characters, and was looking for Toy Story Buzz Lightyear gear.

One price comparison website listed a Buzz Lightyear toy at £999999.00 which seems rather high. It was either made from something very valuable, or an error.

How do you validate pricing information being added and also when displayed? Who/what can alter pricing, discounts, additional charges, tax rates, etc on your e-commerce web site? What approval processes are in place? Who is accountable? All data should be checked for reasonableness, type, format, characters, length, encoding, etc. Reporting/alerting on changes might also help detect this type of issue.

And, make sure your terms state what happens if a price is "incorrect" and exactly when a contract is formed.

"Voucher Codes: assets or liabilities?" was a question asked on Creative Match recently.

Codes providing discounts during the checkout process on e-commerce sites can be an incentive to attract shoppers and increase their spending but also can affect revenues if they are used by people who would have bought anyway.

Misuse by real shoppers is certainly a concern, but voucher codes can sometimes easily be abused if their implementation, operation and lifecycle are not considered carefully. Unlike in the real world where paper coupons may be difficult to forge and can be cancelled by collecting or marking, online voucher codes can be harder to control and expire.

Plan ahead, don't create vouchers code schemes in a rush.

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

One of the most common issues that arise when discussing accessibility and security, is the use of CAPTCHA images on web pages. These are used to differentiate between real human users and automated systems that might want to submit forms to register fake users, create spam or add links to malicious web sites in forum postings, blog comments and the like. CAPTCHAs are also in the news again after Google acquired reCAPTCHA, one of the larger free CAPTCHA providers.

CAPTCHAs also sparked a new topic in the Web Security Mailing List yesterday, Complex CAPTCHA Solutions raised the subject of the benefits and usability issues relating to CAPTCHA and alternative complex methods.

An article in this quarter's issue (Issue 74 Summer 2009) of Ability Magazine discusses the problem and alternative approaches such as audio versions, logic puzzles and image recognition or even having a human operator available to help.

Using CAPTCHAs on web sites where there are particularly sensitive data or as part of authentication mechanisms before providing access to sensitive or high-value information, is almost never justified. The identification and authentication mechanisms should be sufficient in themselves.

The most appropriate use for CAPTCHAs is on high usage web sites where the criticality of information is low, and the benefits to successful abuse greater. But then the owners of these sites have the resources to develop effective CAPTCHA systems and spend time maintaining the robustness of the method against automated systems and other attacks. The larger the user base, the greater the incentive there is to break the method. See also suggestions on an effectiveness test and my discussion on the security implications of Web Content Accessibility Guidelines 2.0 compliance.

So, normally there are simpler ways to prevent spam on most sites that might consider using CAPTCHAs. There is a good summary on the WebAIM blog and discussion list, based on ideas like the Honeypot Captcha. These measures should be used in the first instance for response forms, forum registration and the like. Proceed from there only if a problem occurs, and spend time thinking about other security matters.

Ability Magazine can be obtained by subscription but it is also a free benefit to members of the British Computer Society (BCS) Assistive Technology Group, formerly the BCS Disability Group.

Update 28th September 2009: I just read Using Web Analytics to Assess CAPTCHA Usability on Smiley Cat Web Design which describes an assessment of how many visitors to a web page had difficulty with the CAPTCHA by looking at how often they reloaded it.

A friend forwarded me a wine offer from his bank. But the email from his bank included additional information meant to verify the authenticity of the sender.

The bank included the last part of his postcode in the body of the message as well as his title and family name. If those were meant to be for verification purposes, why did it suggest he forward the email to someone else?

Yes, the forwarded email has all the verification details embedded in it. No, it's not the username and password, but it's everything someone would need to construct a phishing email that would be very hard to distinguish from a real one.

This has the feel of using a security measure as a marketing gimmick. Mixing marketing emails and those necessary for servicing a bank account is a difficult balance, but this is way off the mark.

Input masking on can reduce data entry errors by providing a visual indicator of the data required. This isn't masking as in hiding, but rather format filtering. The Masked Input Plugin on digitalbush.com looks like it has some potential.

You would still want to provide labels and a textual description, but I think the concept here would help many users. Earlier feedback on data mis-matches improves the user experience and reduces the chances that the submitted information will contravene the web site's type, format and length requirements.

Oh, and always perform re-validation once the data hits the web server!

Information leakage is a term we are hearing more about these days. But what is it, and what does it look like?

There's a useful briefing document Information Leakage available from the Information Security Forum (ISF), that describes the what information leakage is, why it's important and ways to reduce the likelihood of information leakage occurring. It describes information leakage as "an incident where the confidentiality of information has been compromised" but I'd also include privacy breaches within that description. An alternative application development view of information leakage is published by the Web Application Security Consortium (WASC).

We've all heard about lost laptops and misplaced USB memory sticks, but in what other more subtle ways can information leakage occur? Well, certainly by malicious hacking, but also by more ordinary actions too. This week, I was looking for a location to host a meeting, and some of the possible venues had web site enquiry forms to collect my requirements. One of these form submissions appeared to work okay, but shortly afterwards I received a message from their mail server informing me that it had been unable to deliver an email from me to two of the company's email addresses:

I've mentioned previously about using email in business processes in Keep The Emails Coming and Application Data Flows by Email. But what else did this fault lead to? Well it gave away (leaked) two email addresses and an internal document that was attached. In fact, I don't think there was any information that I hadn't added myself in the attachment, but it may be that the two email addresses were not intended to be known publicly.

This seemingly small, and hopefully transient fault, has leaked some information. Whilst it is not major in any way—more like a couple of drips than a flood—you can see how information can be divulged in unexpected ways.

In this example, using an external email address as the "from" or "reply-to" fields within internal business processes may be convenient, but in error situations the sender may be notified, so do this with care. A similar situation might also occur if your own mail server rejects the message as spam, or has an out-of-office auto-responder set up for the recipient email account.

I was surprised to see the latest advice Stop Password Masking from Jakob Nielsen.

Jakob Nielsen's has raised many usability topics in his Alertbox but he is not always correct. Although I used to read his column with an open, somewhat sceptical, mind I gave up some time ago*.

No, password masking isn't just some legacy design artefact. Like other design choices relating to user identification and authentication, these have a significant impact on user trust and data privacy, confidentiality and integrity. It is wrong to suggest that masking should be removed by default. By all means inform users of the risks and let them choose to display the characters being typed, but don't have this status set by default. More-and-more web sites are being accessed away from home, and being overseen by other people or surveillance equipment is commonplace almost everywhere.

On e-commerce sites, the need to log in can often be removed completely, or made non-compulsory. Too often security controls are applied for other reasons, such as to generate information for sales and marketing reports, rather than to ease the purchasing process. For more critical data, the use of authentication mechanisms other than static passwords should be considered.

* I stopped reading Alertbox after Jakob Nielsen became very defensive about his training material only being available on DVD and not VHS tape, as many people had requested. His argument was that DVD players were so cheap, people should upgrade. Yet at the time, he was promoting the idea that web sites would render in all browsers—including old legacy ones.

Update 7th July 2009: Password Masking Update.

We all have to deal with too many email messages. Sometimes you opt in for something, or it's a requirements for access to some service, and some time later you want to opt out again.

Well, one email too many from Haymarket Publishing (I can't really remember choosing to opt in for 3Dconferences anyway) and I copied the unsubscribe hyperlink (like http://ecm.hbpl.co.uk/public/unsubscribe.jsp but with some additional parameter values) into a secured browser to visit the unsubscribe form:

But the email text field was not activated—I could not tab to or click on the field to enter my email address. The field had the disabled attribute set:

Usability failure. Accessibility failure. Security challenge. Well, not so much a challenge as a minor annoyance.

Don't Haymarket Media Group check their response forms? Cynical people might suggest they don't want people to opt out from their mailings. However, allowing user to unsubscribe from marketing emails is not an optional obligation. The The Privacy and Electronic Communications (EC Directive) Regulations 2003 states:

Oh, and where are the privacy policy and company contact details?

Compliance failure.