PECR, ICO cookies regulations
The new Privacy and Electronic Communications Regulations (PECR), announced by the Information Commissioner’s Office (ICO) in 2011, comes into effect on 26th May 2012. In advance of the ICO cookies compliance date, organisations are expected to take appropriate steps to be compliant, which include making proactive changes to their websites.
We have blogged about this topic before and reference should be made to the official EU cookie compliance guide (registration required) which contains news and advice for organisations in Europe and around the world for complying with the cookie law.
The ICO provides specific guidance on PECR compliance. However this is not all that clear (to me at least), so the absence of clear guidance on cookie compliance, and the range of practical difficulties that will be encountered in determining what to do with each identified cookie, may lead many website operators to struggle with the compliance process.
There are basically four steps to be undertaken to make the appropriate changes to your website in order to comply with the PECR cookie regulations.
1. Remove as many cookies as possible.
The first step is to clean up your website. Start with the list of cookies discovered during your internal cookie audit, and work with your Web developers to remove unnecessary cookies. In particular, remove the most intrusive cookies first. Any cookies that are designed to track individual visitor behaviour are likely to be considered intrusive. Early evidence suggests that, when faced with an intrusive “cookie notice,” visitor volumes will fall off quite rapidly. Organisations that prize their visitor volumes will therefore need to work hard to find and deploy visitor tracking options that don’t depend on intrusive cookies.
For the cookies that remain, identify those that are essential to the website’s operation and for which the browser’s consent can be assumed. Remember that the test for “assumed consent” is narrow: The cookie must be essential for the specific, advertised purpose of the website. This would include a cookie that connects an item put into a shopping basket to the browser of the visitor that put it there. There is, however, no formal list of criteria for individual cookies assessment. Until there are some legal test cases, “assumed consent” should be interpreted in line with the ICO’s guidance, which is narrow.
2. Deal with your software suppliers.
Third-party cookies are more difficult to deal with. You will need to contact any you are using for website components, such as an online shopping cart software maker or service provider, to determine what changes (if any) they are planning to make in terms of cookies. If a third party is not planning appropriate changes, you may have to consider switching partners.
3. Create questions for all remaining cookies.
In principle, you will deal with all the remaining types of cookies by providing users with some form of pop-up box that enables them to decide whether to accept the cookie. It is likely to be expensive and complicated to enable a pop-up consent box prior to every cookie, so a simpler solution is to have your Web developers write a script that either loads a user consent box when a browser first visits the site, or shows a user consent banner that is visible from all pages of the site. Whichever option you choose, here is the minimum information that should be provided to users:
- A statement that cookies are being used, and some cookies are necessary for the site to work correctly.
- A link to a page that provides detailed information about each of the cookies being used.
- A tick-box for the user to express consent. Remember, it may be necessary to install a cookie in order to remember that decision!
- A tick-box for the user to indicate whether those cookies should be installed for this session or permanently.
4. Develop a server-based tracking alternative.
For those users who choose not to accept cookies, work with your developers to create a server-based tracking alternative so that relevant details about those users are stored in the website database rather than in the visitor’s browser. While this is not a complicated piece of coding, it must be done carefully to work properly. Even so, these visitors' browsing experiences may be less smooth than they would be with cookies installed on their browsers.
Cannot see this being done for Joomla in the near term at least!
How does this impact Joomla based sites?
There are a number of forums devoted to the topic of which one is the Joomla Forum.
My reading of the topic indicates that as far as can be determined Joomla drops its first cookie on login, without explicit consent. This is to set the session to keep the user logged in. If there are any Advertisement based cookies they will be placed afterwards according to what Ad plugins you have installed. Some Joomla components such as Virtuemart and some templates also add their own cookies.
There are a number of thoughts around ‘implied consent’ and ‘explicit consent’ to accept cookies. It seems that the current thought is to display some pre login text to ensure that users know that a cookie will be set. There is AFAIK currently only one piece of software written for Joomla that will perform this task. This is Kookie Grab which I have not yet tested, but implies it will perform the required task. It certainly addresses point 3 above. Whether this will on its own be sufficient is open to dispute.
Strictly speaking this does seem to imply that Joomla straight out of the box in the EC will be illegal once the various countries have brought forward their domestic legislation to comply with the Regulation.
These four steps are at least a start to meet the regulations but potentially there is a long way to go, before we know the true impact of these regulations.