The pro's guide to the new cookie law (part 1)

What exactly is the cookie law?

The Privacy and Electronic Communications Regulation (PECR), more commonly known as the 'cookie law', is UK legislation designed to protect internet users' privacy. It is one of five EU Electronic Communications Directives, which were required to be implemented by all EU member states by 25 May 2011. Yes, 2011 – but it caused so much confusion in the industry that the UK's regulator, the ICO, extended the deadline to 25 May 2012. 

Richard Beaumont's 'A beginner's guide to the new cookie law', published on 23 May 2012, provided a fantastic overview of what web designers and developers should be thinking about. Three months on, and although the furore has died down, the finer details of compliance and technical implementation are widely interpreted and inconsistent.

Advertisement

But it's more than just cookies

Although the focus has been around the use of cookies, the PECR covers other technologies that impact on users’ privacy. These include:

• Third party services embedded into websites, such as YouTube
• Third party services integrated into websites through the use of APIs, such as social media
• Technologies that enable the reading and writing to a website, web application or mobile application's database

Of the greatest concern are the technologies used to store data on computers and mobile devices to track behaviour.

In addition to cookies, other existing and emerging technologies that help perform these functions include:

• Flash cookies or Flash locally stored objects
• HTML5 storage
• Web storage or DOM storage
• Indexed Database API or Indexed DB
• Local data storage in mobile applications

For simplicity's sake, we will refer to all technologies covered under the PECR collectively as 'cookies'; for the same reason websites, web applications and mobile applications will be referred to collectively as 'websites'.

What’s all the fuss about?

Cookies are well established in mainstream digital communications and are vital components of the internet eco-system. With most organisations using content management systems
(CMSes) to efficiently create, publish and manage website content and such systems embedding cookies' functionality in their core code, cookies have become an integral part of the way the modern web works.

Cookies were not created to invade or abuse privacy: because HTTP is a stateless protocol, cookies were designed to work alongside browsers, enabling HTTP to maintain state. As the web evolved, so did the use of cookies.

As far as the cookie law goes, organisations that use cookies in ways that infringe users' privacy by serving unwanted or intrusive advertising and technologies that access and use personally identifiable information are the real culprits, but the law focuses on the technology used and not what the technology is used for, so all cookies are deemed a threat to privacy. Just not so.

What's the web industry doing about it?

As the web industry is not a cohesive one, there is no one voice, which has not made things any easier for web designers and developers who just want clear guidance on what to implement.

Although there is broad agreement that the legislation is overkill, the ICO's approach to cookies has resulted in the real issues being diluted; instead of the interests of consumers being protected by providing them with the information they need to make informed choices, website owners hurried to meet the ICO's deadline in fear of enforcement, with a variety of sticky plaster solutions, most that did not meet compliance requirements.

The trouble is that:

• Most organisations do not have the expertise in-house to fully comply.
• There is no industry-wide consensus on approach, interpretation or policy.
• There are no technical standards, norms or guidelines.

As a marketer and an advocate for inclusive design, I have yet to see a single solution that I don’t find irksome in one way or another, but the real concern is that the cookie legislation appears to have been drafted in a vacuum. At present there are simply no solutions to full compliance that are not in conflict with other legislation.

There are conflicts with several of the Data Protection Act's Principles, and not meeting accessibility standards conflicts with provisions under the Equality Act. Moreover, with 96 per cent of UK organisations employing nine people or less, the financial impact for SMEs must be a consideration. Obtrusive technical implementations that erode UX will lead to loss of revenue and, in addition to the costs of meeting compliance, this could lead to SMEs falling foul of their obligations to shareholders under the Companies Act.

Even so, implementation on a site-by-site basis will not solve the wider privacy issues that the internet faces; ensuring that users privacy and security are maintained across multiple digital channels must be an industry wide concern.

Not everyone is a risk taker, but …

I have enjoyed watching how Silktide's bold "DEAR ICO, SUE US" approach has played out, but as .net is not here to dispense legal advice, this is not a recommendation. Nevertheless, Silktide has a point. Well several actually. It will be interesting to see what happens when the ICO responds fully, but in the meantime, as the rest of us are probably not so bold we shall trudge through.

Will the ICO loosen the legislation then?

At present, the requirement for compliance by all UK website owners is absolute; the legislation makes no distinction between types of cookies, the purposes they are used for or the types of data they store and applies blanket provisions. In the run up to the May 2012 deadline, although the ICO acknowledged the challenges faced by organisations seeking to comply, the guidance was woolly at best.

In April 2012, the UK Department for Culture, Media and Sport wrote an open letter to the ICO imploring it to consider a more business led and pragmatic approach; this was quickly followed by the folk at GovUK, Government's Digital Services department, publishing their guidelines, which were aligned with the DCMS's letter. The ICO's response was unsatisfactory – it stood its ground – but the Government's own non-compliance set a precedent.

The ICO’s expectation was that industry would find a single solution, but none was forthcoming and so in the final hour the ICO made a pivotal change to the guidelines. It relaxed how it will regulate and apply penalties for those in breach and, more importantly, it introduced the option for implied consent to be deemed acceptable – in recognition of the use of session cookies as an industry norm.

Although Silktide's public challenge to the ICO is gaining momentum, the ICO isn't biting and has stated on its blog: 

"…while some are still unclear around whether implied consent is allowed, we continue to work to educate around this."

The ICO further states that it is responding to consumer complaints and will publish a progress update in November.

And so the cookie crumbles.

What are we expected to do right now?

So, for now, the ICO says organisations should do:

 “....everything they can to get the right information to users and that they are allowing users to make informed choices about what is stored on their device”. 

Clear as mud. The only exemption being when the use of cookies is “strictly necessary”, which is a term used by the ICO, but is loosely defined and hotly debated. Put simply, if the cookie is required to protect user privacy and security, then it is strictly necessary. For all other uses, the probability of enforcement increases in line with the risk the cookie places of infringing on users' privacy.  

Despite the disparity and confusion, it is not a good idea to just 'wait and see'.

The quest for consent

One of the major changes the PECR brings is the requirement for websites to obtain consent from users to store cookies on their devices. Initially, the ICO guidelines expected all consent to be obtained before any data was stored; the web industry heaved a huge sigh of relief when the ICO accepted that this is not always possible and included implied consent in its guidance. 

First party and analytical cookies

At this juncture, the ICO will deem it acceptable if websites use first party cookies:

• for non-intrusive functional or analytical purposes only;
• properly inform users about what Cookies are being used; and
• request consent as soon as is reasonably practicable.

However, as the legislation itself remains unchanged, this is not a get out of jail free card.

Third party cookies

If websites allow third parties to set cookies on users' devices, the process of obtaining consent is considerably more onerous, because website owners will be asking users to accept cookies from other domains not in their control.  

Prior vs implied consent

The ICO has taken into consideration that most websites set a session cookie as soon as a user accesses the website, in order to seamlessly enable the stateless HTTP protocol to pass state data.

As such, if it is not possible or practical to obtain prior consent, websites should clearly demonstrate that they are doing everything they can to minimise the length of time between a cookie being set on a user’s device and the user being able to access relevant information about cookies and being provided with options.

Presently implied consent is the most commonly used mechanism, despite the ICO stressing that users would need to have the appropriate knowledge and understanding about cookies before the ICO could be confident that implied consent is an effective method.

Can I just plug and play?

There are no off-the-shelf solutions, but ethical organisations that don't use third party cookies and just want to do the right thing need not fear. In advance of the ICO deadline, I led a multidisciplinary team advising on all aspects of the PECR – design, technical, marketing, legal, operational and then some. Yes, I am that boring – and the information in this article has been distilled from what I have learned.

Considering the likelihood of enforcement

Before jumping into the how-tos of implementation, one of the key things to assess is the likelihood of enforcement. The ICO bases its determination on an assessment of risk, but I shall not bore you with the details of procedure

It is improbable that the ICO will take regulatory action if:

• there has been no apparent privacy detriment;
• you have satisfactorily reviewed Cookie use on your website, web application or mobile application;
• you have satisfactorily informed users about the Cookies you use;
• you have enabled users to choose whether or not they accept Cookies; and
• the user has not set their browser to reject Cookies.

Stuff all web designers and developers need to know

Why websites use cookies

The HyperText Transfer Protocol (HTTP), the means via which web pages are requested and delivered via the internet, intranet and other networks, is described as a ‘stateless protocol’, wherein every web page is requested and served in isolation. There is no provision in the HTTP protocol for the server receiving a request for a web page to 'know' about any previous requests made to serve web pages to the requesting browser.

For websites that have static pages only, this statelessness does not present an issue. However, as most websites, web applications and mobile applications are not static and have some level of user interaction, owing to its stateless nature the HTTP protocol alone cannot facilitate user interaction. 

On an ecommerce website, for someone to add a product to a shopping cart and then proceed to checkout, the technology must perform certain functions in a set sequence and in order to do so, the system as a whole has to be stateful, and cookies are the most popular and efficient way of overcoming the shortfalls of HTTP.

How cookies work

Cookies provide a means whereby a server can take action. When the server receives a request to set a cookie, it takes action and does so. Once the cookie has been set, the server is able to take further action based on the value of the cookie, because the system has become stateful.

From the user's perspective, the initial interaction occurs when the user requests a web page and their browser sends an HTTP request to the server. The server responds by serving the web page, with state data in the form of a cookie, which is embedded in the HTTP header of the response. The browser receives and renders the web page and, assuming that the user has not changed settings so that cookies are not accepted, the Cookie data is stored on the user’s device and filed under the domain of the server that sent it.

Subsequent interactions occur when the user requests another web page from the same domain. The browser has a cookie filed for that domain, and inserts it into the HTTP request header before despatching it to the server. The server receives the request, 'knowing' about the previous request, owing to the presence of the Cookie in the new HTTP request header.

Cookie alternatives and why they are not used

It is untrue to say that no alternative means of passing state information exists: there are other technical means whereby the functionality of a cookie may be replicated. However, they are neither practical nor desirable; the cookie is far superior and offers a seamless and unobtrusive user experience.

Users anonymity cannot be guaranteed

At present, there are no mechanisms that ensure total anonymity on the internet. Disabling cookies and using DNT will not prevent people from being trackable. The use of a standard PC and browser avails the following data:

• IP Address
• Timezone the device is set to
• User preferences, such as screen resolution and colour depth
• The fonts installed on the device
• Which browser is being used and on what device
• What browser extensions and plug-ins are installed on the device
• Whether the user has JavaScript turned on or off
• Whether the browser accepts cookies or not

Web standards, UX, accessibility and best practices

As I trawled through the code and techniques of the various technical solutions emerging to tackle consent, none met with the standards or best practices that we work to and this poses one of the biggest challenges for web designers and developers around cookies; although there are lots of interesting and creative solutions, most have been developed in isolation to provide a technical solution for cookie consent, in many instances this puts them in conflict with best practices for UX, web standards, accessibility guidelines and other legislation.

For example, the ICO uses CSS for absolute positioning of its opt-in overlay feature, so although it is visually prominent, the feature is actually at the end of the footer in the HTML. Keyboard-only and screen reader users are unlikely to access the feature unless they navigate through an entire web page to the footer, so will be able to freely navigate through the ICO website without ever having to opt in. If they did want to do so, it is unlikely that they would be able to locate the mode of access.

Coming up in part two: implementation

Once you've assimilated the whys and the wherefores, part two will provide all you need to get down to the how-tos of implementation, whether doing so in-house or using an agency. You'll be equipped with indispensable knowledge, so that you can conduct a thorough cookie audit, create a plan of action, determine which route to implementation and technical solution is right for your website and be able to manage how your website uses cookies as the ICO's approach to regulation evolves and technology changes over time.

In the meantime:

References and further reading

EU Data Protection Framework

• EU Data Protection Directive

UK legislation and guidance

• The Privacy and Electronic Communications (EC Directive) (Amendment) Regulations 2011
• ICO PECR Compliance Guidance
• ICO PECR Monetary Penalties Guidance

Industry resources

• How Google Analytics uses Cookies
• IAB EU ePrivacy Directive: Consumer Transparency Framework for Publishers / Affiliates
• W3C Blog: The state of Do Not Track