When to set cookies and how to write your cookie policy
Home » Activities » When to set cookies and how to write your cookie policy

Bud P. Bruegger (ULD)

This section provides help in deciding when it is ok for what to set cookies and how to document your decisions in a cookie policy that informs users.

Objective of these recommendations on cookies

The following provides recommendations targeted at a common ICT research and innovation project. They aim at being easy to understand, simple to implement, compliant with regulations and good taste. If your needs go beyond this and your web site uses additional cookies, you need to dive in deeper (see Further Reading below) and take responsibility for your solution’s compliance and good taste.

Am I really responsible for the cookies?

You might say that you just chosen an existing content management system or service and have never decided to set a single cookie. So why should you be responsible?

According to the GDPR, your organization is considered to be the controller[1] of your web site, and thus obliged to actually exercise control[2], and is held fully accountable[3] for what your web site does. So it is indeed your responsibility that only permissible cookies are set. Only then are you able to provide the mandatory information[4] to web site visitors about the data you collect and about third party recipients.

This means that if you use a service, you have to contractually oblige the service provider to support you in your obligations[5]; if you operate an existing content management system yourself, you need to find a technically skilled person to control the cookies. Even with limited technical skill, you can verify the cookies that your site sets by using a standard web browser[6].

Quick guide

The ground rule is to use only cookies that are strictly necessary to supply a service requested by the user. In more detail, this translates to the following DOs and DON’Ts:

DOs
  • Set cookies only if it is unavoidable.
  • Set an authentication cookie to handle the login session in the (optional) restricted part of your website. Under certain conditions, no consent dialog is required for this.
  • Create transparency to the user about cookies you set (see login example below)
  • Document what cookies you set in your cookie policy.
  • When you write project proposals, promise only performance indicators that do not require tracking of individual web site visitors.
DON’Ts
  • Avoid setting cookies on the publicly accessible part of your web site, in particular the home page.
  • Avoid meaningless cookie banners and consent to set non-essential cookies on your homepage.
  • Don’t integrate social media with solutions that set third party cookies without user awareness and explicit consent.
  • Avoid access statistics that require unique identification of visitors (and therefore tracking cookies).
  • Avoid using third-party analytics and third-party advertising.

Use only strictly necessary cookies

A key concept of data protection is to minimize the collected data and the impact on users to the minimum that is required by a legitimate purpose. Also good taste tells us to avoid any unnecessary intrusion of the user. Translated to cookies, this means we want only those that are strictly necessary for the technical functioning of services that a user requests.

In most web sites of research and innovation projects, only the part for project internal communications and collaboration, i.e., the part restricted to authorized project participants, requires an authentication cookie to handle login sessions. We recommend avoiding all other kinds of cookies.

Should your web site be so special that you feel that you absolutely need other kinds of cookies, then you have to document a legitimate purpose why this is necessary and also demonstrate that no technical solution with a lesser intrusion on the user is possible. This should be reflected in the site’s cookie policy.

But even if users consent?

Some people see user consent as a universal legal basis for setting all kinds of cookies. Unfortunately, this has even led to things such as plug-ins for content management systems that falsely claim to achieve compliance with privacy regulations (e.g., the EU General Data Protection Regulation–GDPR). They typically use cookie banner on the home page stating “We honor your privacy; click here to consent to any cookies and to continue to the content of the site”.

In Europe, according to applicable data protection law (the GDPR), this kind of consent lacks legal validity[7]. For example, the consent fails to be informed since users lack understanding of who tracks them, what kinds of profiles are compiled about them, and what purposes it serves. Also, the consent is not free since the user is not presented with a real choice, for example by an option to have reduced access when withholding consent.

Achieving legally valid consent for non-essential cookies is difficult and requires significant legal expertise. But even when successful, it is simply bad taste since it intrudes on users where it is not essential.

How to handle the authentication cookie

The restricted area of your site requires the use of an authentication cookie. This is strictly necessary for the service to which the user wants to log in to and therefore falls under the consent exception. This means that if your authentication cookie is a session cookie[8], a simple text next to the login button is sufficient to be compliant. The text informs that a cookie is being set when logging in.

Optionally, if you want to give users the option that the login is valid also after restarting the browser (or PC), then you need a persistent cookie. Since this is not strictly necessary, you now need to ask consent. This can for example be done with a check box “remember me”. Make sure the default is unchecked. Again inform the user with a text about the cookie. To keep your users informed, also state when the cookie expires and provide a link to information about how to log out.

An example for a login page following these recommendations is shown below.

Figure 6: Example of a compliant login page.

Avoid third party cookies

It is under your control and responsibility as a web site operator to decide whether to include elements (pixels, images, fonts, etc.) in your web pages that cause your users’ browsers to fetch resources from third party web sites. These can then set (tracking) cookies in your users’ browsers.

Should you decide to involve third party web sites in this manner, you disclose to them which of your web pages the user is visiting on your site[9]. Together with the third party cookie that assigns a (pseudonymous) identity to your user, the third party can compile profiles of your users’ behavior. Third parties, such as social media, advertisement or analytics providers, who handle users from many other sites in addition to yours, can gain insight into a large portion of your users’ Internet behavior.

It is under your control to enable such third party profiling. Also disclosure is legally considered processing[10] for which you need a legitimate purpose and a legal basis. Since this is a legally complex area, we recommend that research and innovation project stay away and simply avoid any third party cookies. This is also consistent with good taste that avoids exposing your users to potential privacy risks that are unnecessary for the mission of your project.

Careful with social media

Many projects will decide to interface their site with social media. The common plug-ins that are available for this purpose typically set third party cookies, however. This is particularly a problem for users who refrain from having an account for the concerned social media or users who have logged out from their social media account. For these users, a third party cookie can only be set based on consent.

But don’t despair; there are data protection compliant solutions available that are valid alternatives to the common plug-ins. One example is the open source solution Shariff[11]. It supports all major social media and has already been integrated in a variety of content management systems including WordPress, Joomla, Type3, Drupal, MediaWiki, and several more.

Site access analytics

Analytics tools based on third party cookies are very popular among web site operators. Unfortunately, they represent a major data protection issue and should therefore be avoided. We strongly recommend to avoid cookies for analytics altogether and base your statistics on the locally stored access log of your web server instead.

Even such access logs need some attention to be compliant: You need to limit the storage time (for example with suited configuration of your log rotation) and you should anonymize IP numbers before storage[12]. Details for how to do this are available in “Anonymization” section of the “Main Concepts” in Part II of these Guidelines.

Cookies to support advertisements

Just say no! You are a (possibly publicly funded) research project. You don’t need to create a revenue by selling your web site visitor’s personal data.

A sample cookie policy

To make the use of cookies on the site transparent, it is a good practice to offer your users a cookie policy. Here is an example that fits the above recommendations.

Cookie Policy
Overview

  • We refrain from setting cookies for the public part of the site.
  • We refrain from setting third party cookies.
  • We set an authentication cookie to manage your login session on the restricted part of the site.  This cookie is deleted when you stop your browser. Optionally, you can choose to be remembered, in which case we set a cookie that expires after <…> days or is deleted when you log out.

What is an Authentication Cookie?

An authentication cookie is sent to your browser by the web site after you log in.  It tells the browser to store a unique session identifier in your browser.  The browser then sends this identifier at every access (every web page) so that the web site can recognize who you and verify that you have indeed successfully logged in and are thus authorized to access the restricted area.

When is the Authentication Cookie set?

The authentication cookie is set on your browser after you press the login button on the login page and the web site has successfully verified your password.

When is the Session Cookie Deleted?

If you have left the “remember me” checkbox unchecked, the cookie will be deleted when you stop your web browser. If you checked to be remembered, the authentication cookie expires after <…> days and is then deleted. You can delete the cookie any time before its expiration by logging out. You find the logout button at the URL <…>.

Further Detail

For further information about the processing of your personal information by this web site, please consult the [privacy policy (link)].  The information there will also inform you about how to delete your account for the restricted area of this site.

Summary

Checklist
  • If you don’t have the necessary skills, do I have support from a technical person or my service provider?
  • Do you only set cookies that are really necessary for the functioning of my website?
  • Is the public part of the web site cookie-free?
  • Do you always make users aware before cookies are set?
  • Do you always give users the option to withhold consent to set a cookie?
  • Do you always give users the option to withdraw such consent and “unset” the cookie? (see logout button above)

Further reading

  • Article 5.3 of Directive 2002/58/EC, as amended by Directive 2009/136/EC.
  • National ratifications of the above Directive.
  • Article 29 Data Protection Working Party, WP 194, 7 June 2012, Opinion 04/2012 on Cookie Consent Exemption, https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf (last visited 08/03/2019).
  • Article 29 Data Protection Working Party, WP 208, 2 October 2013, Working Document 02/2013 providing guidance on obtaining consent for cookies, https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp208_en.pdf (last visited 08/03/2019).

 

 

References


1See Art. 4(7) GDPR.

2See for example Art. 28(1), 28(3), and 29 GDPR.

3See Art. 5(2) GDPR.

4See Art. 14(1)(d) and (e) GDPR.

5See Art. 28(3) GDPR.

6See for example https://www.cookieyes.com/how-to-check-cookies-on-your-website-manually/ (last visited 8/5/2020).

7See https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp208_en.pdf a detailed discussion.

8A session cookie is a cookie which is deleted when you close the browser. It is thus different from a persistent cookie which remains stored in the browser until the expiration date is reached.

9Technically, this is achieved by the HTTP header “Referer”.

10See Art 4(2) GDPR.

11https://github.com/heiseonline/shariff

12See for example, https://www.supertechcrew.com/anonymizing-logs-nginx-apache/, https://github.com/letorbi/mod_anonip (last visited 17/02/2020).

Skip to content