Cookie pop-ups: five reasons why they can't work

On many websites, visitors are annoyed by cookie pop-ups. Not only are they annoying, but they are also unreliable and thus generate masses of legal violations. This article proves that consent tools are unreliable in themselves.

Introduction

If a website embeds a service like Google Analytics, this service may only be loaded after consent from the visitor of the website has been given. The legal basis is the ePrivacy Directive, at least when it comes to cookies. Further reasons for a consent obligation are provided by Article 5 GDPR (data minimization) and Article 44ff GDPR (data transfer to insecure third countries).

A consent request on websites is often also referred to as a cookie pop-up, cookie blocker, consent tool or consent pop-up. Consent management platforms are also often referred to.

This article shows that the marketing promises of many providers of consent tools are unsustainable. In practice, consent tools often worsen websites. The result is numerous legal defects. I have shown this in my large Praxistest to Cookie Blockers.

In this article you will learn why Cookie Consent Tools can never be reliable if one trusts their automation or uses common tools from Google, Facebook, Vimeo etc. But there is also an inherent unreliability because cookies can enter a device in many ways (which is the subject of the ePrivacy Directive).

Reasons for the unreliability of cookie blockers

I will name five reasons that are objectively true and completely verifiable in general. It is important for you to understand this. The five reasons are based on hard, irrefutable facts.

1. The cookie blocker

The first reason, why Cookie Blocker cannot function reliably, is purely technical in nature. The working method of a Consent Script, as suggested by numerous manufacturers' advertising claims, is as follows:

1. The Consent Script is integrated on every page of a website so that it is loaded before all other scripts and files.
2. The consent script supposedly recognizes all processes that require consent and blocks them until the user has given their consent

The practice looks different. Modern browsers load multiple files almost simultaneously. This happens especially when the files are loaded from different servers. For example, if a webpage embeds Google Maps, Google Fonts, and a Consent Tool Script, something like this happens:

1. The loading process for the Consent Script begins
2. The loading process for the Google Maps Script begins
3. The loading process for Google Fonts begins
4. At some point before or after point 2 or 3, the Consent Script has finished loading. Only then can the Consent Script attempt to cancel the subsequent loading processes. This only works for loading processes that have not yet started

It is not possible to predict whether the Consent Script will load fast enough to be fully loaded and ready to work before Google Maps or Google Fonts start loading. In practice, it can be seen thousands of times that the desired interruptions of loading processes do not work.

I deliberately included Google fonts in the example because they probably do not set any cookies themselves. Obviously, the loading of Google fonts on websites is not prevented by Consent Tools. The reason for this is explained below.

2. The cookie scanner

How the name Cookie Blocker or Cookie Consent already suggests, many consent tools focus on blocking cookies. The functionality of such blockers works as follows:

1. A cookie scanner runs through a website
2. Every page found on the website is checked to see whether cookies are set
3. The loading processes to which cookies can be assigned are noted
4. If the website is accessed later, the integrated consent script now attempts to prevent all loading processes previously recognized as involving cookies until consent is given

Apparently this approach does not work for Google Fonts and also not for the embedded YouTube video with enhanced privacy settings. The latter means that no YouTube cookies are created at all. As I have shown in a separate contribution, the data processing operations of YouTube scripts are so extensive that alone they result in an obligation to obtain consent under Article 5 GDPR. In addition, one could still mention the data transfer to insecure third countries as an argument.

Another reason for the objectively ascertainable unreliability of Consent Tools is of a technical nature.

Imagine a website loads Google Maps. Let's assume that the map script does not set its own cookies, but loads files from the address google.com.

A Cookie Scanner now scans the website on which the map is embedded. To do this, the scanner simulates a browser. This browser corresponds to one that has been called up for the very first time ever. In the browser, therefore, no cookies have been stored yet. The browser is virgin. The scanner recognizes no cookies in this case.

In reality it looks different. Let's assume you call up the website google.com. In this case, cookies are set. This is a fact (as of 03.02.2021). Try it out yourself! Now call up a website that Google Maps embeds. It now loads files from google.com. At this point, the cookies stored on your device are transferred to the retrieval address (google.com) when loading the file from google.com. The map therefore loads cookies. The cookie scanner could not recognize these cookies!

To know this, one must be aware that every user worldwide has potentially stored other cookies on their device (PC, smartphone, notebook, tablet). It is impossible to know all of them. About Google Tag Manager, it is often explained that it is a cookie-free domain. That's bull. You will find a link below to an article from me called "Bullshit Basics" with proof to the contrary. On my device, there are probably cookies for the domain googletagmanager.com and they are transferred on every website that integrates the tag manager. This is a mandatory consent process.

For further information on cookies, see my Basic Article.

3. Lack of world knowledge

Assuming the previous point had been settled, a cookie scanner would know all the cookies in the world by name and content. This is of course not the case, as you will admit to me without having to think about it for long.

Now the Cookie Scanner must know the purpose of each cookie. Where does this knowledge come from? Let's assume you offer a newsletter. Except for you, nobody knows who wrote the last newsletter mail. Now the recipient of the newsletter mail should explain who wrote this mail. Apparently, it is not possible without your supporting statements.

It is exactly the same with cookies: if the provider of a tool that uses certain cookies does not reveal anything about the purposes of the cookies, it is not possible for a third party to make a statement about the purposes of these cookies.

Article 13 of the GDPR forces an explanation of the purposes of cookies, however. This is not possible for anyone except the provider of the cookies themselves. For Google Tools it is often noticeable that the provider, namely the Google conglomerate, makes no or no accurate statements about the purpose of the Google-Cookies.

Almost all the explanations you find about third-party cookies in privacy policies or on consent forms are invented or conjectural. Google explains the NID cookie, for example:

The NID cookie contains a unique ID that we use to store your preferred settings and other information, such as your preferred language, how many search results should be displayed per page (e.g. 10 or 20) and whether the Google SafeSearch filter should be activated.

Source of information: https://policies.google.com/technologies/cookies?hl=de

The NID-Cookie is primarily used, according to my investigation, to identify users uniquely. For example, a unique identification is assigned after you have logged in on google.de, so that you do not have to confirm the data protection regulations every time anew. In the aforementioned explanation, there is also talk of other information. This statement is hardly to be surpassed in vagueness and does not meet the requirements of Article 12 GDPR at all for transparent and comprehensive information.

For many other cookies, Google does not provide any information, yet statements from third parties can be found here. The statement mentioned in the title of this article is often repeated. I what unable to find it on Google's corporate websites. Regardless of that, the statement is unclear and therefore invalid.

Everything that has been said about cookies also applies to Services (Tools). Cookies are generated and managed by services and do not simply exist. The purpose of a service must also be explained. Only the provider of a service knows the exact data processing, locations of data collection, and recipients of the data.

In addition to the purposes, further statements are to be made about cookies. This includes the provider statement. Do you know if "Google" means "Google" when it speaks of "Google" in numerous privacy notices and terms of use from "Google"? Please tell me. Under this post is a comment field. Of course, the responsible person on a website must be able to provide this information for all services used.

4. Cookies as a central motif

Not for nothing are many consent tools referred to as cookie blockers or similar. Cookies are only one of several reasons why user consent must be obtained. The legal basis for this is the ePrivacy Directive, more specifically, Article 5 Section 3 of this directive. ([1])

Another reason for consent is the principle of Data Minimization. Practically, this means: If a website binds Google Fonts in such a way that the fonts are loaded from a Google server, consent is required. In fact, the font could then not be used. The solution would be simple: Save the font locally and load it from your own server. As far as I know, you cannot conclude a valid DPA with the Google consortium that justifies embedding external Google fonts without consent.

It becomes even more plastic when loading YouTube videos:

• Numerous files are being loaded from domains youtube-nocookie.com, ytimg.com, and ggpht.com.
• Google fonts are loaded from the domain gstatic.com.
• The DoubleClick ad tracker is loaded from the domain doubleclick.net.
• Youtube sends data to a Google-server after loading the page.
• DoubleClick sends data at irregular intervals to a Google server.

Everyone will have to admit that this is an avoidable data transfer. The legitimate interest is therefore ruled out here.

Following the ECJ ruling on Privacy Shield, it should have become known that data transfer to the US and other unsecure third countries cannot be secured even with the help of standard contract clauses or Corporate Binding Rules.

Cookie-centric consent solutions apparently often only ask for a consent for cookies. However, the user should actually agree to serve. Google Analytics for example sets three cookies in many configurations. It doesn't make sense to ask for consent for these three cookies. What would be right is to ask for consent for the use of Google Analytics. Then it's explained that this service uses three cookies. This detailed information can occur at a later level.

The image shows three cookies that are assigned to Google Tag Manager. This assignment is incorrect. The tag manager is mentioned here as a provider, not as a service. The actual provider designation is missing obviously. The assignment is incorrect because the tag manager tunnels other services and thus also their managed cookies.

In any case, nowhere is a query made as to whether the user accepts Google Analytics or not. For this tool, the purpose is not given in the consent query. Informed consent is therefore not possible. The error in cookie-centricity is particularly evident in embedded YouTube videos. Anyone who explains the cookies that are set when the associated YouTube script is integrated has not explained the purpose of the YouTube script. This can be demonstrated very well by the fact that the YouTube script can also be loaded without cookies.

5. The lack of a data protection approach

Many are aware that, in addition to the consent query, also the data protection declaration is important. Many think of the SSL certificate as well, since it is often included in the web hosting tariff. Some forget the forwarding when calling a website without https to the SSL version.

The link to the privacy policy is not available on every page of the homepage on a considerable number of websites, I estimate it is 75%.

Many still embed YouTube videos in such a way that cookies come into play. This does not have to be the case, because the remedy is simple.

All these points and more are not taken into account by Consent Tools, but are important for legal reasons.

Extra: 5+1: Revocation often not possible

Technical third-party cookies are cookies that exist in a domain of a tool provider that is not the same as the website visited. The website operator has no technical control over the third-party domain. This means that cookies in this domain can only be deleted (revocation by the visitor to a website!) if the tool provider offers an interface for this. This interface often does not exist. Revocation is therefore objectively not possible. If, exceptionally, the revocation interface is offered by the tool provider, it would have to be explicitly called up by the controller (website operator). Unfortunately, this happens so rarely in the few possible cases that it hardly needs to be discussed.

Example: YouTube Video Plugin (allegedly without cookies with the domain youtube-nocookie.com). The plugin sets a cookie named CONSENT, despite the domain name. This cookie can only be removed by the provider of YouTube itself. As far as I know, YouTube does not provide an interface for this. Therefore, the YouTube Video Plugin cannot be used in compliance with the law because the revocation is not possible according to Article 7 (3) GDPR. That the YouTube Player requires consent has reasons other than the cookie. ([1])

Conclusion

As announced at the beginning, I what able to show and prove the following:

• The loading process of tools requiring consent cannot be reliably prevented
• Tools that do not use cookies cannot be reliably recognized by an automatic system. None of the consent tools I know of make any significant attempt here, probably for fear of blocking a file that is functionally important for the website
• Each of you has different cookies stored on your end device. None of the widely used cookie scanners can find out which ones they areCookies cannot be reliably recognized and therefore cannot be handled in a legally secure manner
• The purposes of services and cookies are not legally known for most popular tools
• A focus on cookies in the consent query is wrong
• There are numerous other regulations for websites in addition to the issue of consent

My Recommendation: Avoid consent requests as much as possible. Here's a brief help (it is described more precisely in my other contributions):

• Omitting tools that are not really needed
• Replacing tools such as Google Maps with alternatives
  • Google Maps: Button "Route planen
  • Google Analytics: Matomo
  • YouTube or Vimeo video: local video or preview image with jump to video platform
  • Google reCAPTCHA: Other solution, such as WordPress plugin for Contact Form 7

Also interesting

• Checklist for cookie popups
• Cookiegeddon: Practice test of popular consent solutions
• Alternative for Google Tools
• Cookies are not text files ([1])
• Bullshit Basics: The Google Tag Manager uses cookies itself ([1])