On Thursday the UK Government's Central Office of Information (COI) is hosting an event about auditing government websites aimed at government agencies (EAs) and non-departmental public bodies (NDPBs) that have a deadline looming in April 2010.

Web site quality and value concerns were raised in a National Audit Office report on Government on the Internet: Progress in Delivering Information and Services Online in published in July 2007 and recommendation made in the Public Accounts Committee (PAC) Sixteenth Report. Along with their other web standards and guidelines, the COI has issued standards relating to costs, usage and quality. Version 1.1 of TG126, November 2009, on measuring website quality describes three requirements for measuring and auditing website usage:

The benefits of web site auditing were described last year by Adam Bailin on the Digigov blog.

It is very encouraging that the COI are developing standards to improve quality and value. Apart from usage measurement and audit, the quality requirements cover the topics of domain names, usability, accessibility, archival, browser testing, web site map, cost monitoring and web site closure (disposal).

But there are some areas that are not represented in these standards. A glance at something like ISO 9126 indicates other important software quality. A starting point would be to monitor some privacy and security metrics.

And of course, I'd like to see some government requiring some standards for security, which unlike privacy, has a much less firm legal guidance and regulation (for privacy these are the Data Protection Act 1998 and the Information Commissioner's Office). The most well-developed standard for web site security verification is the Application Security Verification Standard (ASVS) from the Open Web Application Security Project. It's free to download and use, and perhaps this can be incorporated or referenced by future government standards and other software security assurance programmes.

The use of particular top-level country domain names (e.g. .co.uk or .com) does add an element of trust to a visitor's impression of the site. On Thursday, the Metropolitan Police's Central e-Crime Unit (PCeU) closed 1,219 web sites selling fake designer goods.

If the fake sites had not been on .co.uk domain, they may have been less able to con consumers into parting with their money and not receiving anything or buying counterfeit products, and the PCeU would have had a harder time taking action. Providing sufficient evidence has been gained, it appears these measures were appropriate in the circumstances.

The new British Standard 10012:2009, Data Protection - Specification for a Personal Information Management System, has been published.

British Standard 10012:2009 was the subject of an earlier draft for public comment (DPC) and I worked with the OWASP Industry Committee on a response.

BS 10012 is not an alternative to the excellent guidance for organisations now produced by the UK's Information Commissioner's Office, but instead is a specification for a personal information management system (PIMS). A PIMS is a governance process for all types of personal information within a company but could also be used for other types of sensitive data. BSI's slant on this is that a PIMS, and therefore BS 10012, could help maintain and improve compliance with the Data Protection Act (DPA) 1998.

A good start and one to watch.

The Skittles.com website has been replaced by a mash-up of social networking sites and a navigational widget.

Including all this third-party content in a mashup could open Skittles.com web site visitors to many more vulnerabilities—any in the third-party content. Also, I imagine we'll see a rash of copy-cat brand sites doing the same combined with more phishing attacks replicating this approach. It will also be interesting to see the reactions to the framing of one site in another.

However, there are also some privacy concerns here. Visitors to the site are asked to provide their date of birth and opt in to a brief disclaimer:

Methods to get past this "age verification" include:

• lie about your age
• peep at what's behind the form on the screen
• go to Twitter, Facebook and YouTube directly
• fiddle with the cookies
• alter the address bar

Some screen captures of the cookie data and address bar are shown below:

But is asking for a precise date of birth really necessary? This reminds me about Don't Collect It If You Don't Need It because Mars Snackfood will have to expend effort to protect the information appropriately. Even this cookie by itself on a browser could be read by a malicious script to gain possible knowledge of the user's age. Full dates of birth are sensitive data that are also used for authentication to other websites such as online banking. Whilst the dates alone may not be personally identifiable information, it's possible these could be combined with other information cached on a (shared?) computer, or aggregated with an IP address or the details provided using the site's contact form. Simpler alternatives could have been:

• age (in years)
• opt in checkbox (I am over X years old)

depending upon what the purpose is—is it to collect marketing data, protect children or pacify the legal department? The "terms and conditions" seems to be the one sentence that "SKITTLES® isn't responsible for that stuff". Under-age visitors are presented with:

Just how accurate will this web-collected data be?

Without any clue as to why the data are being collected and it will be used for, visitors really are in the dark.

If you don't have to collect sensitive data, it saves you having to justify it, keep it securely, monitor access to the data and ensure it is destroyed completely at the end of its retention period. I came across this example from The Nuffield Trust.

Minimising the collection and retention of sensitive data is highlighted as a protection measure in the report for the Information Commissioner's Office Privacy by Design and the recent US National Institute of Standards and Technology (NIST) draft Special Publication 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) - see also my previous post Protection of Personally Identifiable Information.

The links to download publications from The Nuffield Trust give a web page with a hyperlink to download the Adobe Portable Document Format (PDF) version anonymously, as well as the option to register with an explanation why The Nuffield Trust thinks it would be useful to do this.

Why do so many other organisations make registration mandatory for access to resources, often available free-of-charge elsewhere? See also Too Little and Too Much Authentication.

In a post this week by Jared Spool, he describes The $300 Million Button about a web site where removing the registration step at check-out increased sales by 45%. And, they didn't have all that sensitive data to look after. Interestingly he also notes that almost half the previous customer accounts were duplicates.

Just a note, the forms to log in, register and recover the password on this example page—and the actions of these—should be undertaken over an encrypted connection (i.e. SSL/TLS) to protect the data in transit; so, the trust's page is an example of both good practice and bad practice.

Creation of representative data sets is very difficult and time consuming. Therefore, developers and testers often want live data from your web application to work with. This needs to be complete, current and representative. Make sure this is controlled - live data should never be used in development or testing. Live data are also sometimes requested for "running reports offline" - this can be just as risky and illegal.

For example, I've seen a developer testing their work on an email broadcast module send thousands of test messages to real customers of their client because they were working with an exact copy of the live data.

Live data may contain personally identifiable information, authentication credentials or other sensitive information such as contract values or intellectual property. Three methods that can be of help are:

• Extracting a subset - to limit the number of records
• Anonymise records - to remove personally identifiable information
• Masking - to hide sensitive information

On smaller, less complex, systems where the file & database structure and data content are well understood, this could be undertaken manually, or more likely with some pre-prepared scripts. If possible, these should be done on the devices hosting the existing data, so as not to have to manage the transfer of such data elsewhere first. The extract could be exported, treated and then removed from the server over a secure transmission protocol, to a possibly less-secure destination.

In more complex systems such as customer relationship management (CRM) and enterprise resource planning (ERP) applications, the effort of extracting subsets, transforming and masking data can be very time-consuming, complicated to maintain data integrity and difficult to ensure statistical consistency. A difficulty can be the introduction of inconsistences... for example in an insurer's data where the postcode and house insurance premium are inter-related. In these cases, tools can be purchased to help with the task. However, firstly understand the purposes for which the data extract will be used, and ensure that the tool can be used to generate suitable data sets.

Ensure the extracted data sets cannot be reverse engineered back into the original data, are tracked and disposed of securely at the end of their use. Don't forget that "data" can exist in formats other than database files and office documents... in images, multimedia files, caches, logs and backups.

Are there legal restrictions? Under the Data Protection Act 1998 (DPA), you need to inform subjects of your intended uses for the data they provide. If they haven't agreed to its use for testing your systems, you mustn't use it in this way. Remember, if the data cannot be used to identify individuals, the DPA doesn't apply.

Do you have any experiences to share?

Update 7th November 2008: The question of whether IP addresses are personally identifiable data often arises. Comments by Peter Hustinx, the European Data Protection Supervisor, at the RSA Conference Europe 2008 are a useful reminder that nameless data, such as IP addresses, could be personal data and are thus protected by data protection legislation.

Making sure you have everything needed to rebuild a website in the event of a disaster is one of the most useful "calm seas" things to do.

Good practice is to maintain a schedule of all the necessary software, components, services, hardware and configurations required for the complete process of operating your website. This should also include details of all contracts, licences, agreements, contracts and rights required - and details of who to contact with queries or to update any details.

Licensing conditions are important. It might be that there is a limit on the number of server, simultaneous users or domain names that a component like an in-line HTML editor in your content management system (CMS) might be allowed to run in.

There's been a flurry of activity since Google launched its Chrome web browser on Tuesday and it reminded me that the browser used by web site administrators is as much part of the CMS as the application software, database and web servers. The licensing conditions of any component can have a dramatic effect on the system. In the case of Chrome, it might have meant that anything you publish could have been re-purposed elsewhere by Google.

Here are some good discussions on the subject:

• Tap the Hive
• Matt Cutts: Gadgets, Google, and SEO

I'm pleased Google acted promptly and have now changed their terms of service. But beware of licensing conditions - you might not have what it takes.

Home Information Packs (HIPs) were introduced in England & Wales last year to provide information up front to potential house purchasers. These documents contain sensitive information and many are freely available on property and estate agents' web sites.

A friend is considering buying a property and they were provided with a link by the estate agent to download the HIP from a web site. He mis-typed the address and to his surprise got access to the HIP report for another property. The HIP provider "protected" the documents with a number, but it was incremental so simple to find another one, and in any case some had been indexed by search engines, even though it was in some sort of "admin" area.

HIPs contain the sale statement, local searches, evidence of title, an energy performance certificate and advice on how to cut fuel bills and CO₂ emissions. Leasehold property HIPs will also contain a copy of the lease and optionally regulations/rules that apply, recent service charge summaries or statements, recent claims for payments and insurance, the name and address of the lessor, details of any managing agent and details of any works in progress. Similarly commonhold HIPs will have the commonhold community statement and optional items similar to those for leasehold properties.

If there is a mortgage on the property, the name of the mortgage holders and the mortgage company will be shown:

It's not a great leap to guess which building society their current account may be held with. Isn't this all the information that could be used for identity impersonation (also called "identity theft")?

But it seems that these documents aren't meant to be private... some property web sites allow you to download the reports without any authentication of who you are.

I'm not sure how much thought has gone into protecting the seller's personal information and there are large differences between how the various HIP providers and estate agents are allowing access. In May 2007 a question was asked about the security of personal identity in the House of Commons but in a written answer, it was stated the Home Office Identity Theft Unit were satisfied that "...Home Information Packs do not pose a significant risk...". The Home Information Pack (No.2) Regulations 2007 Explanatory Memorandum and Procedural Guidance make interesting reading. There appears to be potential for restricting access and obligations on those providing the reports.

Like other web-enabled processes, estate agents, HIP providers and solicitors need to consider their customer's data security, as well as their own. I'd like to see more thought put into the issue.