The pro's guide to cookies (part 2)

In Part One, you learnt everything you wanted to know about cookies but were afraid to ask and more. Now that you understand the context of cookies, the legal framework, how cookies came to be, how they work, how and why they're used, the industry norms or lack thereof and what is expected of web designers and developers, you can now roll up your sleeves and get down to implementation.

Audit your cookies

Although auditing does not sound enthralling, it is pretty straightforward and is a matter of taking inventory and documenting your findings. Auditing can be conducted by internal web staff or external consultants.

However you decide to progress, there are generally four key stages to conducting an audit. Step one should involve identifying the cookies that are being used. Next, explain what each cookie is being used for.

In step three, assess the level of intrusion each cookie imposes on users’ privacy. As there are no standardised measures, I created my own 'intrusiveness legend', but only after plenty of benchmarking research.

The final step is to document your findings. Key information should include:

• The name of each cookie being used
• The type of each cookie – whether temporary or persistent, first-party or third-party
• What each cookie is being used for
• The data that each cookie stores
• The expiry date of each cookie
• The level of intrusiveness of each cookie

An audit methodology for CMS

As most websites use CMS and most CMS cookies are inherent in the system's core code. There is an exception though: session cookies will be used as a matter of course.

It is best practice for the core code of any CMS not to be modified by those designing and developing websites with them. Modifications should only be made through the service patches and updates provided by CMS developers over time.

Most CMS systems do not have tools available within them to audit cookies in use, so the use of cookies should be determined by these means:

• Performing various actions on a development version of the live website, and observing and noting which cookies are set after each action.
• When the CMS uses PHP, searching the system's code for occurrences of the PHP setCookie() command, the Cookie::set() command of the CMS itself and any other occurrences of the cookie class of the CMS, in order to ensure that no alternative invocations are used.
• If the CMS uses a programming language other than PHP, searching the system's code for occurrences of the equivalent to the PHP setCookie() command, the Cookie::set() command of the CMS itself and any other occurrences of the cookie class of the CMS, in order to ensure that no alternative invocations are used.
• The use of an automated cookie audit tool, if available.

Distinguishing types of cookies

As well as identifying cookie characteristics, it may be helpful to classify cookies from the system perspective.

Non-CMS cookies include Google Analytics. Google Analytics may be used on any website and tracks website usage through the use of cookies.

Google Analytics cookies do not interact with CMS, and should be considered as separate to cookies that are used for the operation of the CMS.

Although Google Analytics is a third-party service, Google Analytics cookies are first-party, rather than third-party cookies. That is, they are set within the context of the website's domain, by a script embedded within CMS page templates.

As Google Analytics is provided free to website owners and provides invaluable metrics. It is firmly embedded in the internet ecosystem, so no one will be turning it off anytime soon. If you want to however, this can be done simply by removing the Google Analytics script.

Third-party advertising cookies

If your website displays advertisements from third parties, these third parties are likely to use their own cookies for tracking purposes and to manage and monitor user behaviour anonymously.

Although your website may not be setting the cookie, you are responsible for the cookies set on your users' devices.

If your website utilises third-party applications, such as social media features, then cookies may be set by the third-party application to manage and monitor anonymous user data. In all circumstances, it helps to know about the different types of cookies that are out there. Here's a quick list:

• CMS cookies – CMS cookies are those set by the CMS and are first-party cookies. I have made a distinction between CMS cookies for All Users, CMS cookies for Registered Users and CMS cookies for Administrative Users.
• CMS cookies: All Users – All Users cookies are those set for anyone who visits your website, unless they have changed their browser's settings to not accept cookies. All Users cookies are set whether or not users are logged in.
• CMS cookies: Registered Users – Most websites do not require general users to login to use the website. If your website requires users to register and login to access certain content or functionality, the cookies set Registered Users who are logged into your website relate to the actual logged in state itself and as such are not set for those who have not registered or logged in.
• CMS cookies: Administrative Users – Many CMS use cookies for website administration. The SilverStripe system sets cookies for Administrative Users in the same way it does for Registered Users. Other systems manage administrative interactions in many different ways, but most will use cookies.

Stage two: make a plan

In the same way that you would scope out a web design and development project, planning for implementation is vital. Step one is to identify what resources you have available – technical, legal, human and financial. Step two is to determine your approach, based on the results of your audit and the resources you have to deliver, with PECR compliance as the ultimate goal, but taking a staged approach.

In order for your users to have choice, they will need to be well informed about your website's use of cookies. More importantly, they will need to understand the implications of the choices they make.

Although the ultimate goal is for the use of cookies to be voluntary – opt-in and not op-out – most are operating on the basis of implied consent as opposed to prior consent.

However consent is achieved, the mechanisms put in place to achieve compliance must:

• Be accessible, intuitive and easy to use
• Not be intrusive
• Not compromise the overall UX
• Be secure and resilient
• Be interoperable
• Be transparent
• Be able to adapt to technological changes
• Be cost-effective
• Not restrict website owners and/or users from benefitting from technical innovation

Conflicts and considerations

Although cookies have been in the spotlight recently, this has shifted attention away from the essence of the legislation, which is to protect users' privacy. In a marketplace where digital marketing communications are designed to be interactive, with the ultimate goal of having one-to-one conversations with users, the PECR legislation places considerable restrictions on organisations being able to achieve these goals.

Of course you need to consider your users first and make sure that your approach is in line with their needs, but if you still want a job, you will need to make sure that the approach you take considers all the areas of your organisation that will be affected. There is no point in implementing a swanky technical solution that sends users running for the hills, or doing nothing and putting their privacy at risk.

Implementation

I'm not exactly throwing you to the wolves, but once you've got this far, you will have a good idea about what will work for your organisation.

There are plenty of different technology solutions on offer in order to obtain consent, but there are also ways to handle implementation internally, so don't start looking for software just yet.

The prominence of cookies information

The ICO Guidance recommends increasing the prominence of cookies information on web pages. However, most of the recommendations for increasing prominence are visual cues, such as:

• Changing the size of links
• Using different fonts
• Mouseover highlights, and
• Using a clickable image or icon

Moving the privacy policy link to a more prominent position, in conjunction with visual cues such as renaming your Privacy Policy to 'Privacy & Cookies' or similar, provides users with appropriate and transparent information about privacy and cookies, and is a really good start.

Educating users

Most users do not understand what cookies are and, as the law requires informed consent, website owners must provide users with quite detailed technical information about cookies prior to obtaining their consent.

It seems that providing the opportunity for internet users as a whole to be appropriately educated, with consultation and collaboration in the creation of a consolidated set of tools to be used industrywide, would be the ideal. However, without these – and as implementation is required on a site-by-site basis – it falls on individual website owners to educate users. There's nothing like reinventing the wheel.

The mechanics of obtaining consent

Approaches taken by some websites, such as intrusive banner and tick box combinations, are just fuelling negative perceptions among users. Trust has already been eroded by unscrupulous organisations that have nefariously and unlawfully used data collected from unsuspecting internet users. As such, putting a big banner up asking users if they want a website to collect their data may be pretty daunting, particularly if the user has never visited the site before. How do they know whether or not they trust a website if they have never used it?

• Browser and other user agent settings - Although users can amend or set controls on user agents, such as browsers, which enable users to make decisions about the cookies that website owners may or may not set on their devices, these are not deemed sophisticated enough to ensure that informed consent has been provided.
• Website terms and conditions for registered users - If your website requires users to register and/or login to use certain services or access specific content, and if the revised privacy policy forms part of the terms and conditions and the criteria for informing users are met, then for new registrants accepting your website's terms and conditions should pass muster. However, for users already registered with your website, you will have to find a mechanism to inform users of the changes to your privacy policy and obtain their consent to the use of cookies.
• Pop-ups – Although the ICO Guidance has identified the use of pop-ups as a mechanism to obtain consent, pop-ups are not best practice. They are intrusive and also exclude certain users, such as assistive technology or keyboard-only users. Moreover, the use of pop-ups generally impacts adversely on UX and, as users can block them by default, this method is not ideal.
• Pop-overs – The most commonly used pop-over is the modal dialogue box, such as Lightbox. Used for the purposes of obtaining consent, how these work will be dependent on the functionality of the system operating the website. Websites that use pop-overs with a CMS will be forced to restrict user interaction until users opt in, so this method will not allow users the time necessary to obtain, absorb and understand cookies information prior to consent.
• Overlays – For the purposes of consent, a status bar or warning bar is presented, with an overlay across the entire website that will disappear once user consent has been obtained. This is less intrusive than the pop-over and does not restrict the user from accessing the website's content.
• Privacy and Cookies button or link – Adding a Privacy and Cookies button or link as a site-wide feature is least obtrusive, but would require integration into web pages/templates. Such a feature would inform users while obtaining their consent.
• User preferences, settings and personalisation – Many websites use cookies to enable users to 'personalise' how they experience a website, allowing users to choose which features they want to use on a website and how they want to use them. This can be for both individual sessions and returning visits. Having a consent mechanism at the time of preference setting may be used, insofar as sufficient information about the use of cookies is provided.

Tips from the middle ground

With no best practices emerging, my bias towards UX and inclusive design has led me to a middle ground. This is, of course, a suggestion for those who have gone through the audit and planning process and, for whatever reason, feel that full compliance is too onerous and want to go the implied consent route. Here are some things to remember:

Ensure your Cookies Policy has been updated and give it some prominence. Having a site-wide Privacy & Cookies link in the header of your website should strike the right balance.

Provide users with enough information to make an informed decision, but don't frighten them with jargon.

Educate your users in a brand-appropriate manner. See it as an opportunity to communicate with your users and reinforce how important they are to you.

Provide helpful generic information about cookies and signpost them to AboutCookies.org.

Be transparent about what cookies you use, what they do and why you use them. Let users know how cookies benefit them and reassure them that you have their best interests at heart.

Management

With diverse, evolving and competing facets influencing what compliance will look like in the coming years, your plan will need to be managed and modified in order to remain in line with these factors. It is envisaged that what will emerge will be standardisation and generally accepted principles that are industry driven.

Google, Facebook, Twitter, Apple et al

As Google Analytics uses first-party cookies only, cookies set by Google Analytics for a specified domain send data only to the servers for that domain. This is currently understood to denote that Google Analytics cookies are the property of the owner of the website domain that is setting the cookie. As such, the data contained in Google Analytics cookies cannot be altered or retrieved by any service on another domain.

With this in mind, the ICO's relaxed approach to cookies used for analytical tracking purposes should be viewed in consideration of the CNIL's enquiry into Google's privacy policy changes, the possibility of Norway banning Google Analytics outright and the penalties levied on Google in the US for privacy infringements. Although Google Analytics are widely used, there has been industry concern regarding how Google Analytics data collected via organisations using its service is used, either alone or in conjunction with other data.

Facebook has also been making headlines over recent years, with concerns over its privacy policies and how it uses user data; at the time of writing, Germany's largest consumer protection group has accused Facebook of breaching German privacy laws. Earlier this year during SXSW, Facebook, Twitter, Yelp, Apple, Foursquare and 13 other social media organisations were sued, amid accusations of supplying mobile applications that invade users' privacy.

This brings the real issues that the cookie law is aiming to address to the fore. The global nature of the Internet, the rapid pace of technological advancement and the changing way digital natives use technology and view privacy and security, must be understood and considered by policymakers around the world. It is also clear that our industry remains in its infancy and I expect that industry regulation will only happen if legislation gives it the space to do so. In the interim, taking a staged, balanced and measured approach to the PECR will lead you in the right direction.