Cookie Consent Solutions

Since the introduction of the GDPR, cookie consent solutions (more commonly known as cookie banners) have been deployed to most websites. Browsing the web as a European nowadays means that every time you visit a website you are presented with some kind of banner explaining that the website uses cookies and that you should please accept all of them. This is necessary as according to the GDPR (Art. 6) in some cases consent is required if personal data is processed. One of those cases for example is when a website visitors behavior is tracked through cookies. Therefore if a website sets tracking cookies it needs to collect a valid consent from their visitors before setting the cookie that tracks them. For information on which cookies require consent, please get in touch with your data protection officer. Alternatively, we at Mondata have solutions to offer legal tech support.

The UX implications

Giving or denying your consent to tracking you on every website you visit is already a burden, as it often creates an additional step before being able to access the content of the website. While this is bothersome already, most cookie banner make it fairly difficult to only accept the “essential” cookies that do not require consent. Instead they try to nudge the users towards giving consent, hiding the deny option in complex settings or tiny text buttons, saying “Only essential cookies”.

The problem

The point where all this feels even more like a setback rather than an advancement for privacy is when even after jumping through hoops to only accept the essential cookies, you still notice a bunch of obvious tracking cookies being set in your browser by that website.

There are two main reasons for tracking cookies to be set without consent:

1. Bad intent: The website operator breaks the law to better get insights into their user base
2. Technical challenges while implementing the cookie consent solution.

The reason for those technical challenges lies in the way most cookie consent solutions work. For them to function correctly the website developer needs to move all code that sets cookies into a special function of the cookie consent solution. After the website visitor accepts the cookies, that function is then called and all the cookies are set. In a world where everyone builds their own website from scratch that might be an acceptable solution. In reality, however, most websites use content management systems like Wordpress with a ton of plugins and embedded content. In order to properly implement a consent solution on sites like that, the user would need to modify the plugins and the CMS to move all cookie setting code to the special function of the cookie banner. What happens in reality is, that the website owner installs a random Google-Analytics Plugin from the Wordpress store which injects the Google-Analytics snippet somewhere in the pages HTML code, well out of reach of any classical cookie consent plugin. As soon as the page is now loaded, the Google-Analytics snippet is executed and the tracking cookie is set, violating the GDPRs rule for processing personal data. This shows that:

Cookie consent solutions that require the website operator to move code somewhere, are doomed to fail!

How to fix cookies being set without consent?

In order to block cookies that need consent we need to focus on the different ways a cookie can be set:

1. Via the set-cookie header on a request
2. Via Javascript
3. Within IFrames

For each of those there is a specific way of preventing the cookie from being set. To be able to block all of them we need to not only have to embed some JavaScript into the website but also modify the HTML before it is send from the server to the website visitor. Therefore, effectively blocking cookies from being set before consent is given.

Blocking cookies set by requests

Here we have to differentiate whether the request is send by the domain, that our cookie consent solution is deployed on (first-party) and requests to third party services (third-party).

In case of a first-party request we simply need to prevent the set-cookie header from being send on the server side. This can not be done on the client side as cookies might be set as HTTP-only and are therefore not accessible through JavaScript.

In case of a third-party request we are not able to block the cookie on the server of the third-party. In that case we must prevent the request itself to block the cookie. Third-party requests can be executed in various ways (e.g. by <img> tags, scripts or through XMLHttpRequest). Due to optimizations of the web browsers some of the blocking has to be done server-side by modifying the HTML response body that is send to the website visitor.

Blocking cookies set via JavaScript

The main way of setting cookie via JavaScript is by using document.cookie. To block it we need to hook the setter function of document.cookie before it is accessed by other scripts. Therefore, the cookie consent script needs to be one of the first scripts that are executed when the website loads. To achieve this we place the cookie consent script as the first script tag in the website head.

Blocking cookies set in IFrames

If the IFrame shows third-party content it is usually not possible for us to access its content due to the Same-Origin-Policy (SOP), implemented in almost all browsers. We therefore need to block the IFrame entirely if tracking cookies are set within.

The scan

Given the various ways that cookies can be set, it is necessary to meticulously create a configuration for the cookie consent solution of which cookies, third-party requests and IFrames to block. Additionally, it is necessary to update that configuration every time new cookie-setting content is added. As it is unrealistic that such a task is properly completed by non tech savy website owners or even developers, it is necessary to automate the process. By analyzing the website from a visitors perspective it is possible to autonomously create a list of all the cookies and where and how they are set.

The database

Given the list of cookies on the website, it is still necessary to classify them whether they require previous consent or not. As most websites use similar libraries and services, we were able to create a large database of information about specific cookies. With the help of clever filter rules we are then able to automatically classify the cookies and their requirement for consent. Additionally, we are often able to map them to a specific service, allowing us to give detailed insights in their usage by third-parties. This is necessary as we need to inform website visitors about the third-parties that process their personal data.

Putting it all together

If we now combine the results of the scan with the information from the database and use it to configure our cookie consent plugin, we get a self-configuring cookie consent solution that automatically blocks cookies wherever they are set, allowing website owners to focus on their content.