The cookie banner - common issues and solutions
Bob MitroA cookie banner, which allows website visitors to consent to selected technologies/services, is an essential part of most websites, but actually implementing it can turn into more of a headache than it would first appear. Often, common cookie banner solutions can cause issues when not applied correctly, so in this article we will be covering some important elements that you should keep in mind when setting up your banner.
Keep an eye on your cache
One of the things that can be a major hinderance when implementing consent handling is the cache; if your website uses it, be aware that it may negatively impact consent handling functionality. This is usually an issue when consent detection is applied server-side; it may lead to a situation where the scripts that utilise cookies are loaded by the user on the browser side of things, despite the fact that they have not yet given consent.
Thus, if you want to be as safe as possible, you should verify consent on the browser side; then we can be more certain of the consent given by the user.
But this implementation, while solving the issue of consent, can introduce its own inconveniences. We often want to load certain scripts that require consent (e.g. a GTM container) as quickly as possible once consent is given. In such a situation, we can create a simple consent verification mechanism in the <head> section of our website, which we can then use to quickly load the scripts that need consent first.
An example of this type of code can be seen below:
<head>
<script>
window.consentAPI = {
checkConsent: function (consentType) {/ * code used to check if user gave consent for a specific type of functionality * /},
loadScript: function (scriptID ) {/ * code used to inject script with a specific ID * /}
};
</script>
<! -. . . ->
<script id = "consent-gtm" data-consent-required-src = "PATH_TO_SCRIPT"> </script>
<script>
if (window.consentAPI.checkConsent ('gtm')) {
window.consentAPI.loadScript ('consent-gtm');
}
</script>
</head>What is this code doing? In short:
- We create a simple API that allows us to verify whether the user has consented to certain cookies / use of the selected technology.
- To block scripts that need the user's consent first, we change the src attribute to data-consent-required-src (if you're dropping a script directly into your code you can use a custom attribute type e.g. consent-required / GTM).
- Under the script that needs consent before it can run, we embed another script that checks whether consent was granted for that script type or not; if so, the function is called by this script.
With this approach, our scripts that require user-consent can be executed as quickly as possible; in addition, we avoid the risk that the cache mechanism that we use will inadvertently, and without consent, send the script with the src attribute instead of the data-consent-required-src attribute.
Attention! Some cache solutions offer us the ability to specify which cookies disable the cache mechanism, so there may be a temptation to specify the cookie file used to store the consents expressed by the user. However, we should remember that the vast majority of users visiting our website will make a decision with regards to whether or not to use cookies, and for them in this situation the cache will stop working, negating any benefit from faster loading.
Tracking Users Without JavaScript Enabled
Most analytics solutions other than scripts also include a code snippet with the <noscript> tag in their embed code. And this causes a big problem - theoretically, such code is dedicated only to users that don't have scripts enabled. But…most cookie banners require JavaScript to function. Therefore, the person visiting our website is not able to give consent.
The only option to mitigate this is to use server-side solutions, but then we have to be very careful with the cache.
If we have a cookie banner that requires JavaScript to work and our website uses cache, the safest option is to delete the <noscript> fragments to avoid data processing from people who have JavaScript turned off in their browser and have not consented to data processing; when in doubt, it is best to avoid collecting data to prevent any violation of the GDPR or other data collection regulations.
Analytical pixels
The <noscript> tags described in the previous section usually use images or <iframe> tags to query a given company's analytical infrastructure. Sometimes, however, such solutions are applied to all users - for example, the subscription forms MailerLite newsletter contain a 1x1 pixel image, which is used to collect analytical data.
In such situations, we should block these elements until the user agrees to data collection; we can do this by, for example, renaming the src attributes to data-consent-required-src.
Vimeo and "Do Not Track" mode
If you embed Vimeo videos on your website, you should consider using the "Do Not Track" mode since, as Vimeo declares, no analytical / statistical data about the user should be collected.
To enable this mode, we only need to add the following parameter to the Vimeo video URL: dnt= 1.
YouTube and the "nocookie" mode
YouTube also offers a solution for embedding videos in a way that better protects the privacy of users. To enable this, when embedding the video you should modify the embed URL to use the youtube-nocookie.com domain, e.g:
https://www.youtube-nocookie.com/embed/XXXXXXXXXXXX
Unfortunately, it seems that even when using this method, some information may still be collected (This topic has been analysed in more detail here: https://axbom.com/embed-youtube-videos-without-cookies/ ). Since we want to avoid any data collection without explicit consent, we should consider whether it is worth requesting consent via our user privacy protection model before allowing the video to load.
Withdrawal of consent by the user
If a user agrees to the use of individual tracking technologies / services, the matter is simple - after giving consent, we simply load the scripts that the user has consented to via the cookie banner interface.
However, a user may decide to withdraw consent to one or more elements. In such a situation, the only viable solution is to refresh the page; without the refresh we have no guarantee that the user's data will be collected (in conflict with the user's preferences) through scripts that were already loaded when consent was first given.
Storing consent configuration: cookies or localStorage?
When analysing our methods for requesting and obtaining consent, we should also consider where the configuration data for the cookie banner will be stored. Usually, this decision boils down to two options; cookies, or localStorage.
At first glance, localStorage may seem easier to implement thanks to the convenient API. However, by storing the information in cookies we gain access to a number of advantages due to the way cookies work:
- We should, as a rule, periodically ask the user to reaffirm their consent to data collection. Since it's possible to specify an expiry date for cookies, we can use this functionality to set when consent should be sought again.
- localStorage is only accessible via browser-level scripts, which means that consent cannot be handled from the server-side since it lacks access to the necessary data (in a situation where the cache isn't causing any issues). But cookies can be accessed from both browser and server-side scripts, making them much more flexible in practice.
- We can easily limit cookies to particular subdirectories, or make them available across all subdomains; a functionality that isn't available when using localStorage.
In summary
Implementing consent management on a website is an often complicated task that, depending on the amount of elements that require a user's consent, can grow into quite a challenging project rather than a quick and easy fix. To ensure that you are operating in a lawful, user-friendly way, it pays to take into account the various issues that may arise, many of which are not immediately obvious such as with the cache or analytical files
There are, of course, plenty of ready-made scripts and solutions that could be used to reduce your workload, but in my opinion, if we want to implement a solid system for consent, we need to commit to an in-depth analysis and verification process. We should approach consent in the same way that we approach website accessibility for people with disabilities; it's difficult to automate a 'one-size-fits-all' approach, and instead there must be some degree of corrections and additions by the programmer, as the situation requires. Ultimately, by taking the time to do things right, we provide a safer, more user-friendly experience for our visitors, and also protect ourselves from inadvertently breaching any data protection regulations.