I've just completed one of those web forms people put in front of useful information before giving you access to gather market research data.

This was published by an information security organisation:

I'm afraid I couldn't "check all that apply" since the nice form only had radio buttons and I didn't feel inclined to edit the HTML myself. Would that have been hacking? Other questions on the same form had the same problem. It didn't instil any confidence in me about their design and testing processes.

Data quality is important. Junk data in will lead to junk answers out.

For those of you planning new web projects in the new year, here are some pointers for accessibility resources to keep in mind. Accessibility is not a marginal issue—by enabling web site users to interact with your web application without hindrance increases trust, improves the accuracy of information submitted and reduces errors. These are all aspects of software quality.

Accessibility sometimes get lumped in solely with talk of disability. But lack of special aids or adaptions haven't been a significant barrier to internet usage by disabled people. Like everyone else it's cost, lack of skills and confidence. So what should we be doing for all users?

BSI British Standards is now inviting comments on a new Draft for Public Comment (DPC) BS 8878:2009, the draft standard on accessible websites (registration required). Based on the Publicly Available Specification (PAS) PAS 78:2006 Guide to Good Practice in Commissioning Accessible Websites which will ultimately be withdrawn, the final date for submissions is the end of January 2009 with an aim for the standard to be published in summer 2009. Thankfully, BSI have now published the complete documents in PDF and Word format (no registration required), since the mechanism for reading and providing feedback is an excellent example of an unusable application! The draft standard is summarised by the document's statement:

I'd add "safe" to the list.

Last week saw the Web Content Accessibility Guidelines 2.0 (WCAG) becoming a full W3C Recommendation. Key reference WCAG 2.0 Documents are:

• WCAG 2.0 at a Glance
• How to Meet WCAG 2.0: A Customizable Quick Reference
• Understanding WCAG 2.0
• Techniques for WCAG 2.0
• How to Update Your Web Site to WCAG 2.0
• Essential Components of Web Accessibility

These aspects are increasingly being highlighted in web project contracts and specifications - and system architects, designers, developers and testers need to know how to build compliant applications. It is important to understand that users won't just be using popular modern web browsers; all sorts of devices will be utilised. The information security shouldn't be less for anyone—regardless of their access method.

One aspect of WCAG 2.0 is maximising compatibility with current and future user agents, including assistive technologies. A related project from the Accessibility Interoperability Alliance (AIA) worth monitoring is concerning Common Keyboard Shortcuts for Accessible Technology (AT) Products Used with Web Browsers along with the Open Web Application Security Project (OWASP) Intrinsic Security Working Group's efforts on introducing more useful security into all web browsers.

Recent proposals from the Ministry of Justice in the government's response to the Data Sharing Review suggest the Information Commissioner will receive greater powers and charge more for data protection registration.

As a result of a consultation, the Ministry of Justice has proposed tougher powers for the Information Commissioner including:

• monetary penalties for deliberate or reckless loss of data
• after a warrant has been served, require the provision of information required to determine compliance with the Data Protection Act
• impose a deadline and location for the provision of information necessary to assess compliance.

The ability to determine Data Protection Act compliance could be difficult for many web enabled processes if there are insufficient controls, monitoring and reporting. I've already found the potential compliance issue is a consideration now for current and new web project specifications.

It is also suggested that the current flat rate notification fee is replaced by tiered a fee structure based on size of organisation (similar to the bands defined in the European Union's Recommendation 2003/361/EC regarding the SME definition) so that businesses with more than 250 employees or with a turnover greater than about £26 million will receive the highest charges.

You can read the full proposals in the response document The Information Commissioner's Inspection Powers and Funding Arrangements under the Data Protection Act 1998 and related press release.

Two articles in particular caught my attention this week relating to designers and developers engaging clients in the development process. Both are worth a read and, I think, consideration in your own web projects.

The first was a great outline of Educating the Client on Information Architecture on A List Apart. The discussion seemed to focus a little too much on static content (data) and probably needs to address data flows and where security boundaries occur in the information architecture. But by using the suggested approach, it makes consideration of security controls much easier.

Secondly, the business case for web application security was discussed on Securosis.com - this was Part 2 of a series of posts about building a web application security program - Part 1 which I had missed was an introduction. The post lists six typical drivers used to justify web application security investments - but I think "User Trust" should be an additional one. Increased trust helps overcome perceptions of risk and insecurity and leads to a greater likelihood of users undertaking, completing and repeating web site processes.

If you are interested in the effect of trust, the multidimensional nature of trust is discussed in detail in McKnight, Choudhury and Kacmar's papers on Developing and Validating Trust Measures for e-Commerce: An Integrative Typology, Information Systems Research, Vol 13, No 3, September 2002, pp 334–359 and Distrust and Trust in B2C E-Commerce: Do They Differ?, Proceedings of the 8th International Conference on Electronic Commerce, 2006, pp 482-491. The reference lists included in these papers provide additional and alternative views on trust.

"Privacy by Design" is the latest must-read document produced by the Information Commissioner's Office.

After a brief consultation period, the Information Commissioner's Office (ICO) has published its report on Privacy by Design to address the general lack of data protection and privacy safeguards. The report was prepared by Enterprise Privacy Group on behalf of the ICO and examines why good privacy practices are not being applied, what can be done to remove these barriers and how to build good privacy principles into all stages of the information systems development and data management life cycles.

Although the concepts relate to an organisation-wide approach for public or private bodies, everything is relevant to the development of an individual web application. Like any form of security the report recommends that measures - privacy enhancing technologies (PETs) - are built in from an early stage and not added on as an after thought. The report also advocates the use of privacy impact assessments (PIAs) and designing privacy protection into the business case for projects - all good stuff.

Update later on 28th November 2008: Bob Lewis has published an article today in Computer Weekly on how to respond to a data security breach and thus protect the people whose data has been lost and, where possible, the organisation's reputation and data. The useful suggestions should be tailored to your own organisation's requirements. For a web site or web application it may be difficult to identify when a breach has occurred and what data has been lost - this is where logging and monitoring can be of assistance. But remember, if you don't collect the data in the first place it can't be misplaced.

This week one of my friends is staying with me. She attended the launch of a new interior design web site yesterday and asked some pertinent questions during the demonstration.

During the walkthrough of the shopping cart and checkout, real credit card data belonging to the demonstrator's assistant were entered on the projection screen in front of a large audience including journalists. My friend pointed this out, but too late - they had to continue. Demos should always try to use appropriate test data whenever possible - in this case it's likely the site, or a copy in a test environment, could have been set up to use test card data - so-called "magic numbers" - with a test merchant account provided by the payment gateway provider.

The web site can act as a store front for individual designers, such as my friend, and she asked where the customers were opting in for the use of their personal data, and who had access to it - the site operator or the end supplier (designer). This seems a very valid question. Apparently that hadn't been looked at yet.

Even the "best" projects seem to have a lack of data protection forethought. In this case, it clearly wasn't a problem with the budget, but the planning and system design.

I have been catching up on some reading and a paper published in October "Continuing Business with Malware Infected Customers" caught my attention.

Gunter Ollmann's paper Continuing Business with Malware Infected Customers - Best Practices and the Security Ergonomics of Web Application Design for Compromised Customer Hosts highlights the issues of building web applications where many of the users have computers already compromised by some sort of malware. This very readable paper is just as relevant to 'ordinary' transactional web sites - not only e-commerce or finance-related ones.

His concept that all customer data should be "untrusted and [may] not have been intentionally sent by the customer" is very important to realise. His suggested practices are practical and relatively easily implemented. They are worth considering for every web site.

Last week's Open Web Application Security Project (OWASP) summit in Portugal was a great success. The summit pages will be updated with the presentation materials and working session outcomes over the next few days.

OWASP has the most comprehensive range of information and tools to help development, testing and operation of secure web applications. It's open to everyone and everything is available free of charge. The active contributors to the Summer of Code 2008 Projects were invited to the EU Summit 08 to participate in sharing of information, discussion of issues, development of ideas for solutions and creation of suggested objectives for the organisation next year.

I managed to attend many of the project briefings and the OWASP Documentation Projects, OWASP Testing Guide, OWASP Intra Governmental Affairs, OWASP Live CD and Live DVD, OWASP Certification and OWASP Strategic Planning for 2009 working sessions. I am looking forward to working on providing official OWASP input into draft standards, guidelines and legislation, along with the other people who attended the OWASP Intra Governmental Affairs working session.

Look out for the new version (3) of the OWASP Testing Guide, available within a week. Version 2 was such an impressive piece of work, and it has been completely reviewed and extended.

I'd recommend anyone involved with the specification, development, testing, operation and management of web applications to have a look at OWASP's key resources like the Top 10, Development Guide, Code Review Guide and Testing Guide, view some of the many presentations and go along to local meetings.

The 2008 EU Summit for the Open Web Application Security Project (OWASP) has begun and I'm looking forward to learning about more of the projects - directly from the project leaders who are here. Many of the initiatives are to reduce vulnerabilities as early as possible in project development - and this means in studies, planning, specification, design and development. An area that interests me is how vulnerabilities become incorporated into an application.

Organisations spend considerable resources trying to ensure their design and functional requirements are built into the delivered web site application. Security issues often relate to functionality that exists, but wasn't asked for.

What does this mean? As an analogy, consider the domestic gas meters found in many United Kingdom (UK) homes:

Like many things, gas meters are regulated - see the UK Statutory Instrument Measuring Instruments (Gas Meters) Regulations 2006. While gas meters must comply with the legislative requirements such as certification, the functional requirements will typically include:

• Measurement of gas usage
• Local indication of the cumulative usage on the meter (often dials and/or a numerical display)

Some may also have the following:

• Remote indication of usage elsewhere
• Prepayment charging

But what other functions are there?

• Some meters were found to be susceptible to "tipping" where flexible connectors are twisted until the meter is laid horizontally on its back rather than vertically, allowing gas to pass without being measured.
• Meters are often in publicly accessible locations and are therefore subject to having the supply valves turned off as a prank or maliciously
• Meters can be bypassed
• Others have stolen the newer Electronic Token Meters (ETM) with payment credit value on the meter, which can be used at another house by stealing and moving the meter.
• Yet others have stolen the adjoining pipework due to the scrap value of the copper.

None of these uses/functions were intended. This is similar to web sites and web applications. Good designers and developers will develop, implement and operate these defensively with a security mindset - because people will accidentally and maliciously attempt things that you never intended them to be used for.

People are at the centre of implementing information technology (IT) projects securely. At last week's British Computer Society (BCS) North London Branch event, the problems were explored and ideas discussed about methods to improve the process.

Jules Gascoigne from Barclays Wealth and Justin Clarke from Gotham Digital Science delivered an engaging talk and led the discussion on what ensures security requirements are built into projects successfully.

Hopefully the presentation slides will appear on the branch web site soon, but I don't think I'm giving too much away by saying that taking care of project staff and suppliers are both properties found in projects that sucessfully implemented security requirements into the final developed systems.

These ideas aren't often seen in project management methodologies.