The Information Commissioner's Office (ICO) has updated its guidance relating to the use of tracking technologies under changes to the UK's Privacy and Electronic Communications Regulations (PECR) which came into force last year, but which began to be enforced last saturday, 26th May 2012.

Version 3 is an update to the version issued last December, and provides further information on "implied consent". The guidance is accompanied by a blog posting and video presentation.

Client-side, or local, storage is an area of concern for privacy and security. Therefore I was keen to attend the latest meeting of the London Web Performance Group titled HTML5 and Localstorage - Storage in the Browser at the Lamb Tavern (building c1780, but on the same site since 1309) in Leadenhall Market on Wednesday evening.

I almost changed my mind as I was also tempted to attend another local event on the same evening about NoSQL for Java Developers. Anyway I was very pleased I went to the client-side storage event, but it was so well-attended I almost did not have a seat. As usual, Stephen Thair (@TheOpsMgr) had done a great job organising the event.

Andrew Betts (@triblondon) described his experiences developing HTML5 applications for mobile devices, avoiding native code whenever possible, so that content could be available when the device is offline or in poor signal areas by using client-side storage. He described the pros and cons of using HTTP cookies, Indexed Database API (IndexedDB), Web SQL Database (WebSQL), local storage (key/value store) and Application Cache (or AppCache). Well the answer of which to use is "all of them". Andrew described how the FT.com application makes use of each type's advantages, to combine together into a responsive and network-robust application suitable for the most frequent and demanding of users. Therefore cookies are used for session management, AppCache for a default fallback page, local storage for static content such as HTML scaffolding, JavaScript and style sheets, and IndexedDB/WebSQL for the HTML content of pages. Thus they manage to fit the application into the HTML5 constraints imposed by different operating systems.

He explained many of the techniques used to circumvent mobile network and device-specific issues, but also explained how they managed to squeeze extra storage by compressing content as ASCII or base64 encoded data into JavaScript's UTF-16 double-byte encoding. It is a very clever piece of optimisation, which could also be used for code obfuscation. Details in the presentation slides.

I think users of client storage will have to be careful if it might be determined to be tracking technology. In the FT.com application case, this client storage is not offered to casual web site users, but only to those who have installed the app, are registered and log in. Thus there are opportunities to obtain consent, over and above any warning the device may offer. We are expecting to hear more about the ICO's plans for enforcement of the new regulations at a press conference this morning. Other HTML5 security issues are of course still a concern here. I was slightly troubled by one feature mentioned.

The presenter's slides are now available.

It's not just lambs that are bouncing around madly this March.

The UK's Information Commissioner's Office (ICO) kindly gave a period of grace to allow organisations to align their operations with the guidance concerning updates to the UK Privacy and Electronic Communications Regulations (PECR). The 26th May 2012 is not far away now.

Although guidance has been available since May 2011, with an update issued in December, it seems many organisations have not done anything, or are unsure what to do, or do not know what is required. In a blog post last week on E-Consultancy.com, the replies to EU Cookie Law: Three Approaches to Compliance give an air of desperation and a feeling that no-one wants to jump first.

Some of the comments are reasoned and practical, but there seems to have been much denial, and a need to place the blame somewhere else (Europe?), instead of proactively complying with the law, and helping individuals to protect their privacy. The comments from Lord Manly, Mike O'Neill, Carlton Jefferis and Russ add some welcome sanity to the hysteria.

Of the three suggestions made in the blog post for gaining compliance, none suggest avoiding the use of tracking technologies. And of course, it isn't just cookies, despite the headlines. As mentioned previously, technologies include:

• HTTP cookies
• Local Shared Objects (LSO) i.e. Flash cookies
• userData in DHTML Behaviors
• data in a Google Gears database
• data in an Indexed Database API
• local data storage in mobile applications
• HTML5 storage

...and anything similar that exists now or in the future.

I think the time to lobby is well past, and the time for action is about to run out. There are services/products that address some of the issues, but to do this properly in a way that covers all similar technologies probably requires building greater consideration of the issues into your own development and change control processes. Post-implementation sticky tape won't really do.

From May 2012, the ICO will be "accepting complaints" from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

In May, the UK's Information Commissioner's Office (ICO) published its initial guidance on how cookies and similar technologies that store information on user's devices should be deployed (see my previous posts here, here and here). The European Union's Article 29 Working Party has now published its own views concerning obtaining consent.

The working party's Opinion 15/2011 (WP 187) suggests that prior consent will always be required and this may mean that the ICO will need to update its own current guidance and enforcement guidelines.

Although the working party's opinion is quite a long document, if you are considering how to build consent for cookies, etc into your future web product development plans (e.g. web sites, mobile apps, social networking activities, e-commerce and f-commerce), it is worth the read.

They emphasize the need to obtain unambiguous explicit consent before any personal data processing can occur, and to be able to subsequently prove this was given. This does not affect mechanisms "strictly necessary" for the provision of the service as discussed before about session cookies. The examples included in the text add some realism to the intent of the opinion, and it is likely the recommendations will form part of future updates to EU legislation.

And remember not to lose sight of the other data protection principles. Obtaining consent does not negate the controller's obligations for fairness, necessity, proportionality, security and data quality.

Further to the recent guidance and announcement of enforcement plans, the first demonstration of what this might entail for web sites which undertake user-tracking or store user data, has been revealed.

The UK Information Commissioner's Office (ICO) utilises up to six cookies on the ICO web site (four relating to Google Analytics). Alexis Fitzgerald discusses the implementation in his Web Application Security - From The Start blog. There is no cookie to say you have opted out of accepting cookies — which is good — but for now the site does leave that rather annoying message at the top of every page which persists in the print version too. Giving consent also sets a cookie "ICOCookiesAccepted".

I see the ICO has stated the session identifier "ASP.NET_SessionId" is an "essential site cookie". It is set by default as soon as you visit the site, and thus presumably is exempt from the regulations for consent due to being "strictly necessary for the provision of an information society service". Take note.

Well, many web sites manage not to use session identifiers except in a subset of the site, such as for authentication and authorisation checks in areas limited to certain users. I wonder whether there really is any functionality on the ICO web site which really requires this session cookie to work?

Putting that aside, the cookie is "session-only" and should be destroyed when the browser is closed. But some web browsers are not routinely closed, and this would leave evidence that the site had been visited. In the case of the ICO web site, it would almost always be an insignificant matter, but there could be situations when even accessing the this might be deemed unacceptable or suspicious, leading to some sort of potential harm to an individual. Other web sites are likely to copy the ICO approach, so it is interesting the ICO has not removed the need for a session identifier cookie for general site browsing.

My baseline tips for cookies used for session management would be:

• Have only one session management cookie if possible
• Ensure session management cookie(s) expire automatically
• Destroy sessions server-side once they have expired, or when their use is no longer required, and after a fixed time period
• Do not store any personal data or business data in the cookie value — just store a long highly-random, difficult to predict identifier which has some meaning server-side
• Restrict session cookie scope to the site's particular domain and URL path
• Set the HTTPOnly, and if SSL is used SSLOnly, cookie attribute
• And preferably, limit where session identifiers are required (i.e. not the whole site)

These are just a starting point. If the session management cookie is part of authentication processes, there are further recommendations for implementation.

No doubt, additional advice on the new cookie regulations and standard practices will be forthcoming in due course. Of course, the ICO could have removed client-side web analytics completely, reducing the number of cookies to one (and this may not really be required either).

As mentioned previously, the new UK regulations on cookies, etc came into force today, 26th May 2011.

The Information Commissioners Office (ICO) announced yesterday that web site owners will have up to a year to comply with the law. The ICO also published guidance on its approach to enforcing the new rules and other powers as part of the revised the Privacy and Electronic Communications Regulations (PECR), which are subject to its own Data Protection Regulatory Action Policy.

The Information Commissioner's Office (ICO) has now published its initial guidance on how cookies and similar technologies for storing information on user's equipment. This becomes a legal requirement from 26th May 2011, following an amendment to the EU Privacy and Electronic Communications Directive.

I had discussed the change last month, but now the guidance has been published. It does appear to be a reasonable, practical, approach but is still work-in-progress and will be subject to change. In general, it requires UK organisations to obtain informed consent from visitors to their UK web sites in order to store and retrieve information on users' computers (including mobile devices).

The ICO advises organisations to take three steps:

• Check what type of cookies and similar technologies are implemented and how they are used.
• Assess how intrusive the use of cookies is.
• Decide what solution to obtain consent will be best in the particular circumstances.

Generally both notice to the user and consent will be required. However, two important exclusions exist for technical storage of, or access to information:

• for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
• where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

This is why temporary state management session identifiers (IDs) used only for the purpose of the provision of a service requested by the user (e.g. looking at an area of a web site they have chosen to access, to log in to a member-only area, to use a shopping basket), are probably excluded from the requirement for consent. But organisations need to check what information is being collected & stored using cookies, etc, when it is being collected, and how it is being used. If session data (as cookies, etc) is transient and only used for the purpose of navigating the site, I would argue it is strictly necessary.

The guidance reminds organisations "strictly necessary" means it must be limited to a small range of activities, and encourages organisations to test whether the activity was "explicitly requested" by the user in some way. Persistent cookies which last beyond the user's current session (e.g. remember me, site customisation) are very likely to require consent, and this is an area where further guidance would be welcome (e.g. session management without authentication).

The guidance includes information on how to obtain consent, and in particular discusses passing data to third parties and the use of third party cookies. If you must allow third party content, the onus is still on you to make sure your site, and all its content, complies with the new law. See also the previously mentioned IAB Europe Self Regulation Guidelines.

Remember, this is not just about cookies — all similar technologies for storing information on the user's device which can then be retrieved are covered by the new requirements. So that will include:

• HTTP cookies
• Local Shared Objects (LSO) i.e. Flash cookies
• userData in DHTML Behaviors
• data in a Google Gears database
• data in an Indexed Database API
• local data storage in mobile applications
• HTML5 storage

...and anything similar that exists now or in the future.

It's a busy week for the ICO; this afternoon, it will publish the new Data Sharing Code of Practice (see my discussion about the consultation last year).

The 25th May is the deadline for implementing changes to the EU Privacy and Electronic Communications Directive. Organisations need to make efforts to comply with the regulations.

The changes mean organisations have to obtain consent from visitors (consumers) to their web sites in order to store on and retrieve usage information from users' computers. Whilst this is aimed at tracking cookies (e.g. behavioural advertising, site personalisation, remember-me functionality), the effect on cookies used for session management and tracking to defend privacy & security is not clear.

But what to do? Self regulation guidelines have just been issued by IAB Europe, the trade body for the European online advertising industry, but this pre-empts formal guidance. The Department for Culture, Media and Sport (DCMS) is leading on implementing the new measures in the UK while the Information Commissioner's Office (ICO) will be responsible for regulation, but the guidance is not expected until after the 25 May deadline. Part of this delay is likely to be due to wanting a joined up approach with the US Federal Trade Commission (FTC) who have been consulting on similar measures, and received a large amount of feedback. DCMS commissioned a report on regulation of internet cookies and this contains much useful information, but doesn't give any firm clues about what the guidance will be.

In the meantime, I would recommend organisation undertake the following steps if they don't already have this information:

1. Identify all their web sites and applications.
2. Determine which of these are accessed by consumers.
3. Create a schedule of all the cookies created or used, including cookies from third-party content hosted on the site (e.g. analytics, advertising, widgets, code libraries).
4. Detail other functionality which collects or stores information about users.

Then await for announcements from the DCMS and ICO.

Update today: The government's summary and response to its own consultation was published today after this item was posted. This confirms (see paragraphs 305-326) a non-prescriptive approach, that is not expected to affect the use of cookies strictly necessary for the provision of a service specifically requested by a user (e.g. session identifier, or a shopping basket). In addition, due to need for future phased implementation of technical solutions, it does not expect the ICO to take any enforcement action against organisations who are at least making some efforts to comply.