Cookiebot: Website Operators Are Liable Because Cookiebot Is Often Not GDPR-Compliant and Offers No DPA

Many websites use Cookiebot, even though in practice this consent tool regularly leads to legal defects on websites. To limit liability, a data processing agreement (DPA) should be concluded with the provider of Cookiebot (Cybot). However, that is apparently neither possible nor wanted by Cybot.

Introduction

Cookiebot is a so-called consent tool from the Danish company Cybot. This article aims to show why it is important for operators of websites that use Cookiebot to have concluded a data processing agreement (DPA) with Cybot. It also shows that Cybot seems to have no interest in offering a DPA, let alone concluding one. Otherwise Cybot would have to fulfil obligations that have to do with data protection. In reality, Cookiebot does not seem to be a data protection product at all but merely a product, in my opinion, based on statements by Cybot, facts and practical tests.

Here is an advertisement by Cybot that appears when you search for the term Cookiebot on Google:

So Cookiebot is supposedly fully GDPR-compliant. It took me a while before I could continue writing this text, because after reading these advertising claims I was overcome by a certain amusement, which was then replaced by sadness and emptiness.

Almost everything stated in the first two sentences of the advertisement does not correspond to the facts. I call something like this a knowingly false statement. Evidence can be found in this article, but also in the articles in the last section “Also interesting”, above all in the practical test. A look at the German-language website of Cookiebot (cookiebot.com/de) shows right away that data protection violations are present there. Apparently Cookiebot cannot or does not want to comply with binding data protection rules.

One piece of evidence for why Cookiebot is not GDPR-compliant: the Cookiebot help page (https://www.cookiebot.com/de/help/) pretends that you can simply choose whichever you prefer: “You can deactivate automatic cookie blocking and instead implement Cookiebot CMP manually by following our manual implementation guide.”

This is wrong, because:

1. Automatic cookie blocking cannot work reliably, as can be demonstrated at any time.
2. When it comes to consent, it is not only about cookies. Cookiebot apparently does not know this or does not want to reveal what is correct. You can find more information in the text of the GDPR or on my website.

Cookiebot problems are therefore inevitable.

How does Cookiebot work?

Consent tools such as Cookiebot mostly work in the same way. Roughly speaking, the following happens:

1. A cookie scanner examines a website
2. It tries to find the processes that require consent because of cookies
3. For this, the consent tool creates a script that tries to suppress the critical processes until the user has given consent
4. When someone visits a website that uses a consent tool such as Cookiebot, a popup is displayed
5. The popup asks for consent
6. If the user consents,

a) the processes consented to are enabled,
b) the consent is stored.

So much for the theory. In practice this does not work, which I have proven several times. That is not the topic here, though. Please take note of this fact nonetheless: with tools such as Cookiebot, the attempt to make a website GDPR-compliant fails in most cases. Cybot itself does not comply with data protection laws on its own website. Why should a tool from Cybot be suitable for making other websites GDPR-compliant?

The question here is whether Cookiebot is or can be a processor for the website operator. Instead of operator, it would be more exact to speak of the controller, who, however, is often identical to the operator.

What is a processor?

The term processor is defined in Art. 4 No. 8 GDPR. A processor is “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”.

I examined the question of what a controller is and where data processing already begins in more detail in an investigation of the concept of data collection.

When visiting a website, personal data is potentially always generated. Reasons:

1. The internet protocol TCP requires the transmission of the user’s IP address when a website is requested
2. The IP address is personal data (the CJEU and the German Federal Court of Justice have established this)
3. The data processing already takes place when the IP address is received by the server that delivers the website

If a website now embeds a Cookiebot script, the user’s IP address is necessarily passed on from the website to Cookiebot due to the internet protocol TCP and is processed there within the meaning of the GDPR.

Furthermore, a user’s so-called “key” is managed by Cookiebot. This key is used to be able to prove a previously given consent if a data subject requests it (cf. Art. 7 (1) GDPR). The key is always transmitted together with the IP address and is therefore personal data for that reason alone. Akamai explains that the end user’s IP address is stored in server logs.

Moreover, the key is unique and is therefore ideally suited to identifying individual users (cf. Art. 4 No. 1 GDPR). The EU’s Article 29 Working Party, the predecessor of the European Data Protection Board EDPB, states in its Opinion 4/2007 that natural persons are considered identifiable if they can be distinguished from other members of a group. This is obviously possible with a Cookiebot key.

The website operator, as the controller for the website, is therefore responsible for Cookiebot receiving the user’s personal data. The website operator engages Cookiebot to implement a consent request.

Do you need a DPA for Cookiebot?

No, you do not. But if you do not conclude a DPA with Cybot as the provider of Cookiebot, your liability expands unnecessarily. So you are liable more without a DPA than with one. A DPA is concluded in your favour and not because it is mandatory.

Anyone who does not hold Cookiebot to account as a processor is therefore initially solely responsible for what happens to website visitors’ data at Cookiebot. Cybot as the provider of Cookiebot only benefits if you do not conclude a DPA with Cybot!

If you conclude a DPA with Cybot, it has advantages for you and disadvantages for Cybot. Apparently Cybot does not want these disadvantages. That is why, to my knowledge, Cybot does not offer a DPA for Cookiebot. That is your problem, not Cybot’s. The only way to eliminate this problem is to do without Cookiebot. For this one reason alone I advise not using Cookiebot.

Obligations of a processor

For once I will spare myself the research and rely on the information from the Saxon State Ministry of the Interior, which lists the obligations of a processor as follows:

• the obligation to keep a record of processing activities (Art. 30 (2) GDPR),
• the obligation to cooperate with the supervisory authority (Art. 31 GDPR),
• taking technical and organisational measures for data security (Art. 32 (1) GDPR),
• the obligation to appoint a company data protection officer (Art. 37 (1) GDPR) and
• the restrictions on data transfers to third countries (Art. 44 GDPR),
• the obligation to inform the controller if, in the processor’s opinion, instructions infringe the General Data Protection Regulation or other data protection provisions (Art. 28 (3) third sentence GDPR),
• the obligation to notify the controller of personal data breaches (Art. 33 (2) GDPR).

That is quite a few obligations. Now you can perhaps imagine why Cybot would like to evade responsibility, as I show further below.

If the processor wants to engage another processor, it must ask the controller for written permission (Art. 28 (2) GDPR) and agree at least equivalent data protection standards with the sub-processor.

If a processor itself determines the means and purposes of processing in breach of the General Data Protection Regulation, it thereby becomes a controller itself (Art. 28 (10) GDPR) and is then no longer a processor.

Proof of a user’s consent

Proof of a user’s consent with the help of Cookiebot is not directly a topic with regard to the DPA, but it is also important if, despite the numerous reasons not to use a consent tool, you are still attached to Cookiebot.

If someone on your website has given consent for all data processing operations with the help of Cookiebot, you must be able to prove this if in doubt (for example in court or at the user’s request).

This proof can only succeed if Cookiebot stores the user’s IP address together with the consent. But that is exactly what Cookiebot supposedly does not do! I have a written statement from Cybot on this:

According to Cookiebot, proof by a website operator that a user has given consent therefore requires the cooperation of the user, who, incidentally, is the one who asked for the proof.

According to Cookiebot, the user is supposed to determine the consent ID, which is stored in the cookie on the user’s device, themselves. The consent ID is supposedly information decoupled from personal data, with which consent is supposed to be provable in the event of a dispute.

Cookiebot has misunderstood something here: it is not the user who has to provide proof of a consent they supposedly gave; ideally Cookiebot should do that for the client!

As far as I know, it is not forbidden for a user to delete the cookies on their device. If that happens, there is no longer a consent ID that the user could communicate, even if they wanted to. Because Cookiebot supposedly does not store IP addresses either, Cookiebot unfortunately cannot provide the proof either. Too bad. Regrettable, but only for the controller of the website, not for Cookiebot. After all, there is no DPA that would relieve the controller and burden Cybot.

The right approach would be: Cookiebot stores the user’s consent together with their IP address. If the user wants proof, one looks at what the user’s IP address is or was at the time of the consent to be proven. There are ways and means for this, and also the user’s duty to cooperate. In doing so, silly me forgets, however, that Cookiebot supposedly does not want to collect IP addresses at all. That is why Cookiebot cannot provide even halfway legally secure proof that a user has given consent.

The operator of a website cannot provide proof of consent received either. After all, that is why they used Cookiebot, a supposed consent management platform (CMP), which apparently is not one and does not want to be one. Managing always means having to fulfil some annoying obligations. That is apparently not for Cookiebot.

Cookiebot states in its privacy policy that IP addresses are anonymised directly upon receipt in the main memory by truncating three digits. That seems nonsensical, because IPv4 addresses consist of four bytes. If you strike three digits, one byte remains. This byte has no use; you could just as well delete the IP address completely.

Furthermore, in a letter I have, Cookiebot writes that 16 bits are truncated for IPv4 addresses and 96 bits for IPv6 addresses. This corresponds to truncating IPv4 addresses by two bytes (leaving two bytes) and IPv6 addresses by 12 bytes (leaving two bytes). As a whole, this statement completely contradicts what is found in the privacy policy.

Conclusion

Cookiebot supposedly does not want to have collected any personal data and supposedly does not do so now either. That is bullshit. Cookiebot apparently does not want to conclude a DPA because it would give Cybot some obligations that seem to stand in the way of running a profitable business.

Should it now be possible to conclude a data processing agreement with Cybot, I would be grateful for a hint. Even if something above should be presented incorrectly, I ask for feedback. I will gladly correct this article if something needs correcting.

Addendum July 2021

As I learned, a website operator received a cease-and-desist letter because they used Cookiebot. Data was exchanged with servers of the company Akamai (USA). This is a problem under Art. 44 et seq. GDPR. The website operator signed a cease-and-desist declaration and has not used Cookiebot since.

That Akamai servers are used can be shown by the following facts and statements by Cookiebot itself:

• IP addresses that are called to retrieve Cookiebot scripts embedded in websites are registered to Akamai (USA).
• The responses returned when retrieving such scripts contain the value AkamaiNetStorage in the HEADER field called Server
• When the scripts are retrieved, Akamai servers are addressed directly, says Cookiebot. There is no redirection via servers of other providers, says Cookiebot.

Also interesting

Do you want a GDPR-compliant website? Then avoid using a consent tool if possible. You should definitely not use Cookiebot. Here you will find more information on why.

• Cookies and consent: the overview
• Cookiebot unlawful according to the Wiesbaden Administrative Court
• Overview article: all possible reasons, practical tests and evidence summarised
• Practical test of popular cookie tools (incl. Cookiebot and other GDPR failures)
• Reasons why consent tools fail
• Checklist for consent requests

Anyone looking for privacy-friendly solutions will find some of them on Dr. DSGVO. If you cannot find such a solution for a common problem, feel free to write to me. A few things are in development, others first need your input.