Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

As a volunteer to the open and free knowledge created and distributed by the Open Web Application Security Project (OWASP), I have contributed time to a number of projects and am a member of its Global Industry Committee. But until this month I haven't been an actual project leader.

But now I have become project leader of the OWASP Codes of Conduct Project. This is intended to be the home for a series of documents that define a small number of minimal requirements for other types of organisation, specifying what are the most effective ways they could support OWASP's mission (to make application security visible, so that people and organizations can make informed decisions about true application security risks).

Three initial documents were drafted during the working session on Defining a Minimal AppSec Program for Universities, Governments, and Standards Bodies at the OWASP Summit 2011 which was led by Jeff Williams, Dave Wichers and Dinis Cruz. Although I did not attend this session due to clashing objective, I subsequently contributed to the draft documents and created a document aimed at a fourth type of organisation. The documents were labelled "codes of conduct" to imply they define normative standards, representing a minimum baseline, which should not be difficult to achieve.

During the summit, two other working sessions (Outreach to Educational Institutions and Certification) defined another code of conduct, for application security skill certifying bodies. The primary contributors were Jason Li, Jason Taylor, Martin Knobloch, Matthew Chalmers and Justin Searle.

OWASP wanted to formalize, complete and create release-quality documents, and therefore I offered to start a project and become its leader. The project will nurture these initiatives and collect feedback on the draft documents with the aim of issuing and promoting the documents later this year.

I have already standardised the formatting and content of the five codes of conduct, and raised some questions for the community to discuss. The version 1.1 (draft) documents are available from the OWASP web site as follows:

• The OWASP Application Security Code of Conduct for Government Bodies (The OWASP Green Book)
  • English version PDF
  • English version MS Word
• The OWASP Application Security Code of Conduct for Educational Institutions (The OWASP Blue Book)
  • English version PDF
  • English version MS Word
• The OWASP Application Security Code of Conduct for Standards Groups (The OWASP Yellow Book)
  • English version PDF
  • English version MS Word
• The OWASP Application Security Code of Conduct for Trade Organizations (The OWASP Purple Book)
  • English version PDF
  • English version MS Word
• The OWASP Application Security Code of Conduct for Certifying Bodies (The OWASP Red Book)
  • English version PDF
  • English version MS Word

If enough organisations can undertake these minimal requirements, we see this having a significant contribution to better application security. My plan is to gather feedback on these in the next month so that we can create peer-reviewed release-quality documents by the end of September. There is some further information on the OWASP Blog.

If you have any comments, views or ideas for these, or have skills or contacts to assist with their promotion, please let me know. The project has its own mailing list.

Last year I provided help with the definition of information assurance objectives and controls for the systems acquisition and development domain in the Common Assurance Maturity Model (CAMM), a joint-initiative originally created by originally created by European Network and Information Security Agency (ENISA) and the Cloud Security Alliance (CSA).

My contribution was on behalf of OWASP who were among the many organisations, groups and companies supporting the CAMM initiative. Well, the project has come a long way, and is now a key contributor to the plans to create a global repository of assessments for assurance of the IT supply chain.

At the end of last week, a paper Business Assurance for the 21st Century was published defining the common vision of a single approach for assessments (either self-assessed or independently verified) to make it simpler for organisations to select suppliers and partners based on the coverage and maturity of their information assurance practices. The concept is that the global repository, or "Third Party Assurance Centre", would support a number of assurance frameworks and allow vendors to publish information in a single open format, reducing the need for numerous separate assessments for each potential customer.

All the major assurance frameworks seem to be on board, so this could well achieve a step-forward in transparency, whilst at the same time introducing cost reductions into the market.

The European Network and information Security Agency (ENISA) has published a summary of Secure Software Engineering (SSE) Initiatives.

The report has compiled a list of existing Secure Software Engineering initiatives focused on finding and preventing software vulnerabilities. This is a first step in addressing the problem of software vulnerabilities by ENISA which it sees as a growing problem in cyber security. The report lists 80 initiatives in the areas of:

• Requirements engineering
• Procurement criteria for secure software
• Risk-based development
• Security in agile methods
• Policy frameworks for web access control
• Security testing methodologies and code reviewing
• Patch and update management

This will be a very useful reference point for other agencies, and for anyone involved with building security into the software development life cycle (secure SDLC). If anything is missing, ENISA would like to know. The report notes they found no government-driven SEE initiatives in the EU.

The project's manager Vangelis Stavropoulos and other ENISA representatives are holding a special workshop session Global Secure Software Initiatives - Beyond Awareness with OWASP to talk about this initiative with industry professionals at AppSec Europe 2011 on Thursday June 9th at Trinity College, Dublin. The session will focus on how to acheive the implementation of existing secure software development knowledge, and the role that governments can play in supporting these activities.

Also, at AppSec EU this year, the OWASP Global Industry Committee is hosting three outreach sessions on Friday the 10th of June. Nishi Kumar will be presenting "Security for Managers and Executives" to highlight the OWASP documentation, training, architecture, tools and infrastructure is available. Rex Booth will be discussing, and seeking feedback on, the upcoming "CISO Survey" to maximise the benefit to CISOs and their peers. Joe Bernik with Sarah Baso are holding an "Industry Outreach Roundtable" which will be a forum to discuss how OWASP can give value to all industry sectors, what the impediments are and what could be changed to help.

PAS 124:2011 (Defining, Implementing and Managing Website Policies and Standards) has been updated, superseding PAS 124:2008 which has been withdrawn. It was issued by BSI in March.

Publicly Available Specifications (PAS) are industry-led initiatives, are not full British Standards and generally not free. They can be withdrawn and replaced at any time. However, the topic is relevant enough to make it worth mentioning here. This PAS was originally commissioned by Magus, but members of the steering group also included the Cabinet Office, LBi, Olswang LLP, SDL Tridion, Shell International B.V. and Unilever plc.

So what does this document concern itself with? PAS 124 describes how to define, implement and manage web site policies and standards, and provides suggested areas they should cover, and example governance policy and further sources of information.

The scope says whilst PAS 124 can be used for "all types of website including: static websites, dynamic websites, web portals, mobile websites, e-commerce websites and content published by organizations on external sites such as social media sites", it does not cover "web-based services and applications: software-as-a-service (SAAS)/cloud computing services, virtual learning environments and internet enabled widgets and applications (e.g. mobile applications)". That's quite odd, because dynamic web sites and e-commerce web sites are applications.

Some of the benefits in taking the approach suggested by PAS 124:2011 are "protection of brand and company reputation by ensuring a consistent high quality user experience", "minimization of online risk through compliance with legal requirements" and "securement of appropriate protection of intellectual property" and "increased user confidence through a consistent, high quality user experience". I agree with those.

And what areas does it consider should be included to "govern the content, function and appearance of websites" to acheive these benefits? These ten key areas are listed:

• Accessibility
• Brand and template
• Co-branding
• Domain name and URL structure
• Editorial and copywriting
• Legal
• Search engine optimization (SEO)
• Social media
• Usability
• Website governance policy

Now, PAS 124 does state "this list... is not exhaustive...". True. There is no mention of affiliates, advertisers, wider marketing (not just SEO), testing, analytics, optimisation, performance monitoring, supply chain management, intellectual property, disaster recovery, business continuity, and use of multiple channels.

But how are aspects like information privacy and security, and the protection of assets belonging to the company, other organisations and individuals governed? "Data protection and privacy" are mentioned briefly as an example legal issue that "might" need to be considered.

Also, the PAS explains it does not cover "the following types of technical standards: infrastructure standards (e.g. connectivity, performance and availability), security standards, code standards, or the use of semantic web technologies."

I am disappointed. Technology requires governance too. And security is not just about technical controls — the administrative and physical aspects are just as important for preventative, detective and corrective actions necessary to achieve the benefits listed in PAS 124. In Appendix C (Useful Sources of Information) under the heading "security" is states "This is an area where there are a lot of standards. Visit the BSI website to review the range of available standards", but I'm not sure that really does the area justice. No mention of untechnical aspects? Also, surely there are some technical aspects in the listed key issues of accessibility, templating, domain name and URL structure, legal and usability? I can think of quite a few.

There really is more to governing a web product today than what is listed here. PAS 124 seems to reflect the thoughts of a somewhat silo-style organisation which does not have a connected overall viewpoint. It feels like the old-fashioned web manager in the corner office; someone disassociated from the business and out-of-touch with supporting legal, marketing & information systems services. What it covers is good, but its vision is too constrained.

So, I think the PAS has set too narrow a focus for its scope — PAS 124 is more 2001 than 2011.

A US survey of has found that 88% of companies spend more money on coffee than on web application security. We (in the UK) seem to legislate more on fruit juice than either coffee or web application security.

Whilst it was encouraging to read the section on security in the ICO's new Data Sharing Code of Practice, we do seem to have rather more detailed legislation on things like fruit juice than information security. The Fruit Juices and Fruit Nectars (England) (Amendment) Regulations 2011, which were laid before Parliament in April and come into force on Monday, define the minimum Brix levels (sugar content) for fruit juices from concentrate. Wouldn't it be great to see some similar highly specific legislation on securing online applications (and labelling) like this across Europe?

But, back to the coffee... Cenzic have issued their Web Application Security Trends Report Q3-Q4, 2010 which provides an analysis of reported vulnerabilities and breaches attributable to web applications. Its results confirm other recent reports that cross site scripting and SQL injection continue to dominate, despite these issues having being know about for a long time, and there being readily available methods to solve them.

But Cenzic and Barracuda Networks also commissioned the Ponemon Institute to survey 600 IT and IT Security professionals in the United States. The report's findings showed that most companies are spending more on coffee than keeping their web sites secure.

I'm sure the findings for tea in the United Kingdom would be similar. After all, there is a British Standard about how to make tea (BS 6008:1980/ISO 3103:1980). I can't find the application security standard from BSI (...just yet).

Whilst on the theme of the privacy protection, this afternoon I attended the launch of the Information Commissioner's Office (ICO) Data Sharing Code of Practice, at the House of Commons.

If you remember there was a public consultation at the end of 2010, and the final document is now complete. I contributed to my company's written response, as well as to a response by OWASP on the security aspects of data sharing.

The event was sponsored by John Leech MP, Alun Michael MP and Dominic Raab MP, and the new code of practice was introduced eloquently by the Information Commissioner, Christopher Graham. He made the important point that the ICO is about enabling safe use of personal data, and that blocking the use of personal data is not its role. In fact, consumers and citizens can benefit from transfers and sharing of their data — it just has to be done legally. He described the guidance as "making sense on paper, and in the real world".

Note this is statutory guidance which has therefore been approved by the Secretary of State and laid before Parliament. It does not impose new legal obligations nor is an authoritative statement of the law. But both courts and the Information Commissioner must take into account the contents of the code when determining any question arising from proceedings, or functions being performed by the ICO under the Data Protection Act (DPA).

It applies to all sectors — public and private — although there is some sector-specific guidance included. Importantly it applies to both routine systematic data sharing as well as one-off data sharing tasks. The guidance notes data protection principles also apply to the sharing of information within an organisation, such as between divisions, departments and teams. Examples and case studies used in the document include "a retailer providing customer details to a payment processing company", "a mobile phone company intends to share details of customer accounts with a credit reference agency" and "a marketing company wants to share data with a fulfilment company so it can send out free samples". Practical, yes.

I was interested to read the new document to see what changes had been made in the period since the consultation. The draft document was quite good, but the final guidance is an order of magnitude better. It looks as though considerable re-writing, greater explanation, and addition of a glossary and quick-reference checklist have improved its content and usability. Additionally, I am pleased to see many more practical private-sector examples have been included throughout the main body, and in the case studies in Annex 3.

In terms of information security, the primary aspects are detailed in Section 7, which lists good practice to take in respect of information shared with other organisations, highlights the need for building a security-aware culture, identifies the need to take reasonable steps to ensure the receiving organisation understands the nature and sensitivity of the information, the need to consider all modes of transmission, and provides two short lists of physical and technical security measures to be considered. One which stands out in particular is:

Well, that's quite specific! And, good advice.

So, data controllers take note. If you are involved with specifying or designing online (or other) business systems, read the whole document — it really will help. The code of practice does not itself have the force of law (the DPA does), but it describes good practice, and the ICO can only take enforcement over breaches of the DPA. But as the guidance says doing nothing, risks breaking the law.

The whole structure of the document is:

1. Information Commissioner's Foreward
2. About this code
3. What do we mean by "data sharing"?
4. Data sharing and the law
5. Deciding to share personal data
6. Fairness and transparency
7. Security
8. Governance
9. Individual's rights
10. Things to avoid
11. The ICO's powers and penalties
12. Notification
13. Freedom of Information
14. Data sharing agreements
15. Data sharing checklists

The annexes are:

1. The Data Protection principles
2. Glossary
3. Case studies

Coincidentally today a potential £200,000 penalty was imposed by the ICO for a recent web site personal data loss, and the full amount was only avoided because the sole trader had already ceased trading.

The code of practice has not yet been published on the ICO web site. I will check again tomorrow morning.

Update 11th May 2011: The ICO has now announced and published the Data Sharing Code of Practice and checklists on their web site.

Microsoft has released their annual update to the Security Development Lifecycle (SDL) Process Guidance.

SDL 5.1 includes several new, updated and promoted controls which probably reflect better more typical design and coding faults. For example in Phase 2 - Design, these have been added:

• Mitigate against Cross-Site Scripting (XSS).
• Apply no-open X-Download-Options HTTP header to user-supplied downloadable files.

In security controls for cryptography:

• Provide support for certificate revocation.
• Limit lifetimes for symmetric keys and asymmetric keys without associated certificates.
• Support cryptographically secure versions of SSL (must not support SSL v2).
• Use cryptographic certificates reasonably and choose reasonable certificate validity periods.

During Phase 3 - Implementation, the following requirements have been updated:

• Use minimum code generation suite and libraries.
• Compile native code with /GS compiler.
• Use secure methods to access databases.

And still in Implementation, the following have been added/promoted:

• Do not use Microsoft Visual Basic 6 to build products.
• Ensure that regular expressions must not execute in exponential time.
• Harden or disable XML entity resolution.
• Use safe integer arithmetic for memory allocation for new code.
• Use secure cookie over HTTPS.
• AllowPartiallyTrustedCallersAttribute (APTCA) review.
• Mitigate against cross-site request forgery (CSRF).
• Load DLLs securely.
• Minimum ATL Version and Secure COM Coding Requirements.
• Reflection and authentication relay defense.
• Sample code should be SDL compliant.
• Internet Explorer 8 MIME handling: Sniffing OPT-OUT.
• Safe redirect, online only.
• Comply with minimal Standard Annotation Language (SAL) code annotation recommendations
• Use HeapSetInformation.
• COM best practices.
• Restrict database permissions.
• Use Transport Layer encryption securely.

And finally in Phase 4 - Verification:

• File parsing.
• Network fuzzing.
• Binary analysis.

There are also some changes to the SDL-Agile Requirements.

So, quite a significant update really, with many good recommendations being added or improved upon. Whatever your programming language, it is worth cross-checking these items with your own coding standards.

On Sunday morning, I was intrigued to read on Web Application Security - From the Start about a security vulnerability supposedly found on the Child Exploitation and Online Protection Centre (CEOP) web site.

But it is apparently true, the short story on the BBC web site seemed to be confirmed in their interview with CEOP which was mentioned by @StewartRoom, @xklamation, @siliconglen, and received further coverage yesterday in IT Pro and IT Week. I wondered where this report came from and how the Information Commissioner's Office (ICO) became involved so quickly. IT Week suggests a member of the public tested the CEOP site and then told them of the problem; presumably CEOP then reported it to the ICO.

Don't get me wrong, I think the ICO should investigate whether there has been a breach of the Data Protection Act 1998, but some of the information released so far doesn't seem correct. The BBC story includes several statements supposedly attributed to CEOP's Chief Executive Peter Davies. But I cannot quite believe CEOP would say some of these things about a web form to report alleged offenders, so perhaps sadly there is some over-zealous PR going on, or misinterpretation by the BBC's journalist.

A later item on The Register Child protection Website Insecurity Fixed paints a slightly different picture, suggesting the form is, and always has been, using SSL only, but that there was a link to a non-SSL address which then redirected. I must say, I'm inclined to believe The Register's version more than the BBC. I think we have to leave it up to whoever is investigating to get to the true facts, but it does seem to be creating a link between personal data protection and the use of SSL.

It is perhaps not always clear to government agencies what administrative, physical and technical security practices should be implemented to protect a web site, and who makes the decisions. The government's Central Office of Information (COI) have never published any web standards and guidlines on security or privacy protection, perhaps feeling it is some other agency's responsibility (maybe CESG, CPNI or even the ICO?).

The security measures implemented for a web form like this ought to be similar to those defined in open standards, and common sense alone would tell you this is an obvious place for using appropriately designed HTTPS. Anyone auditing or verifying the security aspects would have made this clear in large red letters, but waiting until after being made live is incomprehensible too. Security and privacy need to be considered from early stages in every project, and built in to the final system. There are existing standards for that too.

But I am concerned about some statements which have been reported. If they are true, I am worried.

"All secure website carried the prefix https, compare[d] to http for insecure ones"

False. Using HTTP over SSL does contribute to the protection of a user's, or organisation's, data in transit and also gives some degree of identity assurance. There is even a campaign to increase adoption. But SSL is not the same thing as a web site being secure. A web site using SSL can still be vulnerable to attacks (e.g. SQL injection, cross-site scripting, cross site request forgery) leading to contamination with malware or data damage, loss and destruction.

SSL does not stop breaches of the Data Protection Act.

"It's been fixed now"

Really, that quickly? There's more to implementing SSL than just turning it on. Last year I mentioned some other concerns about CEOP and trust, but you cannot check or test a web site without authorisation. On Sunday, @siliconglen also asked why they CEOP were not using an extended verification (EV) SSL certificate. For many purposes I'm on record as saying EV certificates are not needed, but here I agree, I think an EV certificate should be used. And really, why not have the whole site SSL.

Of course, all organisations would do well to ensure that their SSL certificates are valid, applied appropriately to the applications and that SSL is configured securely, such as ensuring weak protocols and ciphers are not available. They should also think about whether any data can be cached locally on the web browser, whether other domains have access to the web page contents, and what exactly is done with the sensitive data once it is saved on the web site. How secure are the information systems and subsequent processes?

Fix and verify.

Conclusion

Other public and private sector organisations take note. It will be interesting to see the outcome of the ICO investigation and whether this incident leads to a change in attitude, or even sets a precedent for online data protection requirements.

SSL has its problems, see here, here and here, but it would be wrong not to implement it. After all we've been using it for over ten years to help protect credit card data in online shopping; information from children about possible offenders is an order of magnitude more important than payment card data.

I just hope some of the statements that appeared in the BBC article about SSL were misinterpreted, and don't become the accepted understanding. CEOP please set the record straight.

Earlier this month I discussed a seminar being organised by the Information Commissioner's Office (ICO). I was fortunate enough to be able to attend the event on Wednesday at The Wellcome Trust on Euston Road in London.

The event began with a welcome from Christopher Graham (Information Commissioner, ICO). He explained the seminar was not a theoretical debate about legal definitions, but instead a discussion of the current and emerging practical risks of re-identification. In particular he hoped ideas would form on how best to assess and mitigate the privacy risks of some form of statistic leading to someone being identified.

Sir Mark Walport (Director, The Wellcome Trust) continued on this theme but focused on the medical research sector. He explained that having good data is inextricably linked to good public health. He outlined various benefits of sharing data to individuals and the public, and identified proportionality, choice of terms of service and confidentiality vs. consent as the key issues. He also touched on some of the content in the Data Sharing Review Report, written in conjunction with the previous Information Commissioner Richard Thomas.

Dr Mark Elliot (University of Manchester) discussed anonymisation as disclosure avoidance and the need for formal disclosure risk assessments. This can include undertaking simulated data intrusions to help rank file riskiness, in a similar way an organisation might rank processes or applications by other forms of operational risk. He explained such processes need to consider the intruder's motivations, the consequences of disclosure (to individuals, organisations and society), but also that it needed to take into account the issue of spontaneous recognition.

Following a short break, Nicola Westmore (Cabinet Office) outlined the government's transparency agenda which has the aims to promote efficiency & effectiveness, improve public services and allow citizens to make an informed choice. She talked about the privacy risks inherent in data.gov.uk and the drivers for government data disclosure.

Dr Kieron O'Hara (University of Southampton) asked whether transparency will pose a threat to privacy, especially in the areas of crime data and demand-driven transparency which he believes will be strongest in the area of health, education and court data. He said that privacy is not only a legal matter — it is not just data protection, as this is insufficient to retain trust, the law has grey areas, and citizens' perceptions do not follow the content of the Data Protection Act. He felt the law was not the answer and a discussion was needed between transparency activists, privacy activists, technical experts, domain experts and information entrepreneurs. He would also like to see auditable debate trails by organisations making decisions as to whether and what data are released.

Dr Marie Cruddas (Office for National Statistics) talked about the balance between data utility and risk. She walked through the confidentiality protection framework, used to determine how data are released by the ONS. This considers the end-user requirements, data quality, sensitivity, age, coverage and other characteristics, a disclosure risk assessment, disclosure controls (legal, ethical and practical), management of disclosure risk and implementation. An interesting idea was the concept of undertaking a penetration test on data sets, to see how they can be re-identified alone, or together with other data sets.

Once delegates had re-assembled from the lunch break, Paul Ohm (University of Colorado) described how there is a perception that anonymisation is ubiquitous, trusted and rewarded by law in terms of benefits and exemptions. He described how even relatively innocuous data can be used to identify individuals and discussed how policy makers should respond. He believes lists of personally identifiable information (PII) are unsustainable and that technology will not be a solution, partly due to the accretion problem where we creep closer and closer to personal data releases. He believes in the use of contextual risk assessments, best effort approaches, consideration of risks, motives & criminal behaviour, accountability measures and reduction in unjustifiably risks collection of information. I can see how threat modelling can be extended into this area further.

Barry Ryan (Market Research Society) provided a background to the MRS' principles, from classical research to how this has changed through the use of non-anonymous participation, qualitative groups, online market research communities, and ethnographic and deliberative techniques. Research clients often provide individual contacts, and they are demanding more information which is more detailed.

David Smith (Deputy Commissioner and Director of Data Protection, ICO) chaired the panel discussion where the speakers discussed whether access controls are useful, the rights of individuals to compensation and redress, audit trails for data downloads, the usefulness of a register of data controllers, anonymisation as a failed concept, the influence of China on the internet with its focus on traceability, the need for trust, effort needed in the education system and, inevitably, the need for further research.

David Smith thanked all the speakers and provided an engaging summary of the seminar. Since he considered the outcome was that true anonymisation is not possible, this made summing up more difficult. The ICO will develop and issue a report on the day, together with the presenter's slides, and David Smith asked if there were any further contributions, to forward them to the ICO.

My own conclusions? The situation is complicated, and there isn't yet agreement on the best path forward. Anonymisation is a partial privacy protection method, but data can almost always be re-identified and therefore it cannot be relied upon as a definitive protective measure, or as an excuse/exemption from data protection requirements. It seems there may be a move towards risk assessments rather than specified conditions and controls.

But do read Paul Ohm's paper Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization which I highlighted in a previous post about test data. He also provided the best quotation of the day: "Data can be either useful or perfectly anonymous but never both".

Update 5th August 2011:A report of the proceedings is now available.