Bud P. Bruegger (ULD)
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 of your web site, and thus obliged to actually exercise control, and is held fully accountable 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 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; 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.
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:
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.
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. 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, 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. 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 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. 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. 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.
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 <…>.
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. ↑
12See for example, https://www.supertechcrew.com/anonymizing-logs-nginx-apache/, https://github.com/letorbi/mod_anonip (last visited 17/02/2020). ↑