Today the UK Information Commissioner's Office (ICO) announced the publication of its report on the business case for investing in proactive privacy protection, which it is launching at the Data Protection Officer Conference in Manchester.

The aim of the research and report defined in the tendering brief was to create a soundly argued business case for expending money on privacy friendly systems and business processes. John Leach of John Leach Information Security Ltd and myself working for Watson Hall Ltd submitted a proposal to undertake the project for the ICO. We were awarded the contract in August 2009.

We began the project by producing a public discussion document and initiated conversations with a number of experts. Our research was complemented by interviews with a cross-section of data processors and discussions held with an expert panel. We were particularly concerned about producing a report that would be relevant across all UK business sectors and size of organisation. Our draft report was reviewed by a small number of senior business leaders, and modified based on their experience and knowledge of justifying investments and practical experiences of implementing privacy protection measures.

The result? Well I'd like your opinions after reading the report. The Privacy Dividend is comprised of two volumes:

• Volume 1 - The Business Case (20 pages)
• Volume 2 - Supporting Materials (71 pages)

I hope you find "The Privacy Dividend" a useful resource. Additional updates and references are included on the Business Case for Investing in Proactive Privacy Protection project microsite.

Last month I described the ability to track users sessions with browser data. A recent posting on IT Law in Ireland highlighted a series of blog posts elsewhere that give further insight into what is possible.

Well, I just got round to reading them properly. The posts on Freedom to Tinker by David Robinson and Harlan Yu are:

• Identifying John Doe: It might be easier than you think
• What Third Parties Know About John Doe
• The Traceability of an Anonymous Online Comment

The conclusion? It is possible to trace and identify individuals easier than you may think. We are dropping evidence like dead skin cells as we traverse the internet. Fact or fiction? Well the US Defense Advanced Research Projects Agency (DARPA) are taking it seriously with a recent call for research into cyber genetics, cyber anthropology and cyber physiology in its Cyber Genome Program. DARPA hopes to develop advanced methods to fingerprint or identify the origins of a cyber attacks by examining digital artifacts, and presumably other criminal activities utilising computer technology.

Getting a bit more down to earth, web site owners need to consider what information is being gathered and why, ensure this is legal, check that consent is implied or has been explicitly given for the purposes and what monitoring and analysis is performed on the data. It could be easy for system developers to carried away with tracking and tagging. Contracts with third parties should state clearly what the expectations are about the security and privacy of information, to protect web site users (employees, customers, clients, citizens) and the business.

The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

A couple of weeks ago I mentioned listings of user agent (browser identifications). But can this data be helpful in validating logged in user sessions?

Session data (relating to the user) should be stored on the server rather than in cookies or locally on the client (browser) and this is often referenced by a unique, difficult to predict, session identifier, usually set as a secure, httpd-only, temporary cookie. It is sometimes better to validate the session identifier is still being used by the same user it was issued to. Apart from checking the session is still valid (exists and has not expired), you can also check that it corresponds to the same IP address, or at least an IP address range. It's also possible to build into this, checks that the following Hypertext Transfer Protocol (HTTP) request headers haven't changed:

• User agent
• Acceptable languages for response
• Acceptable encodings for response

by storing these properties, or a hash of them, along with the session identifier in the web application's database. They should not change. These additional checks make it harder for someone else to impersonate the (authenticated) user.

You might wonder how unique user agent data can be. In an attempt to determine the uniqueness of browser information and whether this constitutes personal data for privacy protection because it identifies them, the Electronic Frontier Foundation (EFF) has released a new online tool called Panopticlick to let you calculate how unique your own web browser fingerprint is. The test identifies the user agent string, HTTP accept headers, browser plug-ins, time zone, screen size, screen colour depth, system fonts, whether cookies are enabled and storage settings. There is a good write-up about the personal data issues on the Tech and Law blog. But can we use this data for session tracking?/p>

I tried three browsers with Panopticlick:

• Firefox 3.6 running several add-ons (FF3.6)
• Opera 10.10 with JavaScript enabled (O10)
• Internet Explorer 8.0.6 (IE8)

which indicated that all three browser's fingerprints were "unique among the 71,823 tested so far" with at least 16.13 bits of identifying information.

The differences appear to be related to how much information could be gleaned from the browser and system, with plug-ins, screen dimensions and system fonts being very unique—the computer has two graphics packages installed and several custom fonts. Making the browser full screen reduced this aspect's uniqueness, but had no overall change in the browser's identifiability.

This means that some of these data could be used to check for impersonation or even to help identify returning site visitors without setting cookies or requiring people to log in, but you would have to be careful because some browsers won't send all of this data e.g. if JavaScript is disabled. For example, with NoScript enabled, FF3.6 reported as only one in 2,433 browsers with the same fingerprint and that it conveyed 11.25 bits of identifying information instead of over 16 bits.

Further reading about the scary things here and here that JavaScript might be able to detect about your computer and network.

I have updated the chart detailing the most important guidance, standards, legislation and organisations that can affect web development security and privacy in the UK.

The Principal Influences on UK Web Applications is published on my company's web site and details the changes made since the previous version in August. The information is laid out as a mind map diagram, and as a text tree.

Not all the items are relevant to every web site—some aspects are sector specific—but much of the guidance from organisations, in guidelines and in standards can be of use beyond their intended audiences.

But this chart isn't just about web site security and privacy. The chart can also be useful for organisations implementing an information security management system (ISMS) that need to keep up-to-date with compliance requirements, and those with a need for knowledge on wider information assurance (IA) aspects. There's quite a lot of overlap.

This week the Ministry of Justice published the summary of responses to their consultation on revised fines for serious breaches of the Data Protection Act.

In Civil Monetary Penalties: Setting the Maximum Penalty proposals were made for a maximum £500,000 fine following granting of powers to impose civil monetary penalties being added to the Data Protection Act (DPA) 1998 (Sections 55A to 55E) by the Information Commissioner's Office (ICO) through section 144 of the Criminal Justice and Immigration Act 2008.

The 52 submissions described in the summary of responses showed broad agreement for fines up up to £500,000 for data controllers who seriously contravene data protection principles. The ICO issued a press release Data Breaches to Incur Up To £500,000 Penalty on the same day with details of how they will consider:

• the circumstances including the seriousness of the data breach
• the likelihood of substantial damage and distress to individuals
• whether the breach was deliberate or negligent
• what reasonable steps the organisation has taken to prevent breaches.

The ICO has produced statutory guidance about how it proposes to use this new power, which has been approved by the Secretary of State for Justice, and has been laid before Parliament.

The statutory guidance is worth reading since it outlines things such as "reasonable steps the Commissioner expects the data controller to take" that include (in a non-exhaustive list that includes mention of risk assessment, governance, audit, policies, procedures and practices):

So, the standards are being raised.

Subject to Parliamentary approval, the civil monetary penalties are expected to come into force later this year on 6 April:

• Draft Order "The Data Protection (Monetary Penalties) Order 2010"
• Statutory Instrument 2010/31, The Data Protection (Monetary Penalties) (Maximum Penalty and Notices) Regulations 2010

P.S. If you are interested in privacy matters, The EU's Article 29 Working Party and Working Party on Police and Justice have jointly published a paper on The Future of Privacy (WP 168) and there is an excellent summary and overview on the Tech and Law blog. The conclusion: a new comprehensive legal framework for data protection is needed in the EU.

Following on from Tuesday's topic of terms and conditions for interactive advertising, the US Network Advertising Initiative (NAI) has just released their 2009 compliance report.

The NAI is an association of 35 US advertising networks, data exchanges, and marketing analytics services providers including Advertising.com, Google and Yahoo.

The NAI Compliance Report 2009 discusses compliance by its members with its self-regulatory code of conduct governing the collection, use, and disclosure of data for online advertising services by its member companies (the NAI Code). The NAI Code has its own definition of personally identifiable information (PII) and sensitive information and its own protection principles. The NAI found its members to be broadly in compliance with the code, apart from ten members that did not disclose specific retention periods for data collected.

Whatever your views of behavioural advertising, industry initiatives like this to improve, and report on, standards are a welcome contribution. No doubt the code will evolve over time, but it is a good starting point. The code perhaps lacks requirements for measuring the accuracy of data or requiring ways for consumers to correct information about themselves, and it would be useful to know what checks are being undertaken as part of the audit. For example "Reasonable security is determined in light of several factors including, but not limited to, the sensitivity of the data, the nature of a company's business operations, the types of risks a company faces, and the reasonable protections available to a company" could be interpreted in a number of ways and some guidance on what is "reasonable" both from the organisation and individual's points of view would be welcome.

P.S. Happy new year.

Britain has some snowy and cold weather at the moment causing difficulty for people getting to shops or going on holiday, and web retailers are likely to be doing brisk trade if they can still deliver before Christmas.

E-commerce sites are often associated with HTTPS (a combination of HTTP with the SSL/TLS cryptographic protocol). There was a time when HTTPS was used only where absolutely necessary due to the additional encryption/decryption overhead it placed on a user's browser (client) and the web application (server). But what's the situation today?

N.B. the padlock symbol or green/blue coloured address bar (depending upon the type of certificate in use) indicating the use of a "secure" web server, does not mean your data is safe; it shows the server identity is verified to a certain extent and that data in transit between your web browser and the web server is probably safe from interception, if it is configured correctly on the server, the certificate has not expired or been revoked, and you can ensure the content you see is on the site the address bar says it is. It also says nothing about how the organisation and partners that handle the data once it has been received by the web server—they might forward it by email, allow third parties to have access to the server, print the data and leave it unprotected, etc.

Almost all web sites have some aspects that should only be accessible over HTTPS. Any sort of data entry form is likely to include personal information and therefore HTTPS should be used to at least protect the confidentiality of the information in transit. User registration, authentication (log in) and any pages that contain confidential information would also be included. Previously, many search engines did not index HTTPS addresses, but since its use was mainly restricted to content protected by some type of authentication and authorisation, this was never much of a concern.

But nowadays, search engines are indexing HTTPS content and a few web sites are only available using HTTPS. Is this a configuration worth following? In a discussion Ivan Ristić described the additional benefits of HTTPS (HTTP over SSL):

Issues

So while there are benefits relating to authenticity and integrity, in addition to confidentiality, and dangers to mixing HTTP and HTTPS on the same site due to badly designed authorisation and session management systems, what other issues are there?

Search engines

The most popular search engine robots no longer discriminate whether the content is HTTP or HTTPS, so this is no longer a concern. I am not aware if any adverse effect on search engine optimisation (SEO), other than the effects of changing from HTTP to HTTPS or vice versa which would have to be managed carefully and appropriate permanent redirects set up (also called 301 redirect due to the HTTP response status code of 301 for "moved permanently").

Note that Google, and apparently Yahoo and Microsoft, support the "rel='canonical'" link element and state it can be used for indicating a preference for HTTP vs HTTPS, or vice versa, when pages are available by both. There is also a setting for this choice in Google webmaster tools if you are a site owner. But be careful with allowing both HTTP and HTTPS access to the same page, since this quite often is implemented in a way that adds vulnerabilities to user authentication and session management.

Resources on the server

The server is affected by two aspects—the increased number of requests (see also resources on the client, below) and the overhead of encryption/decryption/building SSL connection. Intermediate proxies should not cache the content and therefore a greater number of requests is to be expected. The additional resources required to serve content using HTTPS are discussed extensively here and in a research paper, i.e. there will be a performance hit, but whether this is a problem depends on your traffic profile, architecture, server utilisation and site's design.

Server side processes

It is possible that any server-side indexing or reporting systems may not support HTTPS and they may need to be updated or configured to work with the different protocol. If you syndicate data to other systems via XML, RSS or web services, these processes will also need to be checked for compatibility.

Traffic management

Network devices that inspect and route internet traffic must be SSL-aware to be able to read and analyse the content. Most modern devices will be able to support this mode of operation.

Client device support

Some devices (e.g. mobile) may not support HTTPS, or HTTPS may not be allowed through firewalls but this is probably less of an issue now. Check if these are issues with your expected users and the devices your site supports.

Address familiarity

Most people will not recognise (or type in) HTTPS addresses and use the common shorthand of the host name (e.g. www.clerkendweller.com) or an alias (e.g. clerkendweller.com) rather than the protocol followed by the full host name. So this would require a redirect from the HTTP address to the HTTPS one, and for many web sites this will be acceptable. For sites of a more sensitive nature, this would have to be handled carefully to protect any session identifiers and still leaves the user potentially vulnerable to a man in the middle (MITM) attack. These are where the redirect is amended and the user taken to a malicious web site instead. If you can rely on users using only the SSL address, perhaps by bookmarking it, you are on safer territory.

Resources on the client

Again there will be a performance hit on the user's client device (e.g. browser of a desktop computer). Much of the time this will not be a problem unless the device already lacks resources (e.g. a mobile device). Then again, due to the lack of caching, more requests will have to be made directly to the server, creating additional lag to download and build content.

Mixed content

Even if all the content from your own site is sent using HTTPS, you may have embedded content such as:

• client-side web analytics
• advertisements
• news feeds
• widgets
• images, videos, scripts and other content hosted elsewhere.

These must also all be provided using HTTPS, otherwise the benefit of being HTTPS-only will be lost and users may see "mixed content" warning. But this can be a problem as much third-party content is not available using HTTPS (SSL), notably including Google AdSense, Amazon Affiliates and YouTube. However, Google Analytics does support SSL.

Conclusions and further reading

An all-HTTPS web site provides additional security benefits, but user acceptance and server constraints need to be considered in the site's design and architecture decision making processes. The partial, or full, use of HTTPS (SSL) in a web site needs to be considered carefully during design and development to ensure weaknesses that could be exploited are not built in, and then verified by thorough testing. If you have a heavily consumer-focused web site or include third-party content, some of the choices may have to be on the side of ease of use rather than with the lowest security risk.

"Whole site SSL" should be a serious consideration for "green field" web sites, especially where user authentication is required for any part of the content and for sites where phishing is a major risk (e.g. gaming, web mail, banking). User knowledge and acceptance may be difficult until we see the likes of major banks or large consumer-orientated sites (Google Mail, Google Docs, Twitter, Facebook) use this configuration and and display a warning/educational message to people who go to the non HTTPS site, rather than a redirect.

On Wednesday I attended the Information Commissioner's Office (ICO) Personal Information Online Conference 2009 at which the ICO launched their consultation on the new Personal Information Online Code of Practice.

Manchester and Salford gave us a beautiful sunny day for the event which briefed delegates on the ICO's approach to data protection and an outline of the collaborative process used to develop the draft code of practice. Iain Bourne, Head of Data Protection projects, noted that fewer than hoped public sector organisations had been involved to date, and they would like more feedback from this sector in particular during the consultation phase that ends on 5 March 2009.

My first impressions are this will be a useful document for organisations without staff dedicated to data protection or compliance, especially once the examples and SME checklist are added. The structure and content are still a little raw, but probably about right for the start of a 12-week consultation process. Areas where I am already considering providing feedback are:

• local storage of personal information (not just cookies)
• verification of protection
• suppliers, sub-contractors and staff
• monitoring and anomaly detection
• transmission of personal information
• inclusion of third party content in web sites
• using cookies to enforce an opt out
• additional reference materials.

The full text and consultation document is available as a PDF.

Feedback on the Personal Information Online Code of Practice can be provided using the ICO's consultation portal with further background available in the related press release.

The Ministry of Justice has announced the Government's consultation on revised fines for serious breaches of the Data Protection Act.

In Civil Monetary Penalties: Setting the Maximum Penalty proposals are made for a maximum £500,000 fine. The powers to impose civil monetary penalties were granted to the Information Commissioner's Office (ICO) by being added to the Data Protection Act (DPA) 1998 (Sections 55A to 55E) through section 144 of the Criminal Justice and Immigration Act 2008.

The civil monetary penalty would apply in serious contraventions of section 4(4) of the DPA by the data controller, of a kind likely to cause substantial damage or substantial distress, and the contravention was either deliberate or "the data controller knew or ought to have known that there was a risk that the contravention would occur, and that such a contravention would be of a kind likely to cause substantial damage or substantial distress, but failed to take reasonable steps to prevent the contravention".

The closing date for comments is the 21st December 2009 and a paper summarising the responses to the consultation will be published by 11th January 2010.

Update later on 17th November 2009: Just caught up with the news and heard the ICO is investigating whether T-Mobile has been selling their mobile phone customers' records illegally.