Abiding by GDPR laws and regulations

I got scared

I recently came across this website which reported that blog website owners and operators were being asked to pay 100 euros in damages and 90 euros for lawyer costs in relation to their website containing Google Fonts on their blog website.

The EU GDPR laws are very strict and as a law abiding citizen I need to make sure that because this blog is in the public domain that I make every effort to ensure that the public are not misinformed. Certain elements in the website do use some Google services for the functionality, such as the contact me form which uses the I’m not a robot captcha to prevent against spam.

From my understanding, the GDPR laws are basically there to protect individuals rights and freedoms to privacy. Therefore, it is within my role as the website operator to ensure that the users of this blog site are informed when a Google service may be used. As a user of the blog you have every right to decline using this as a service.

Now, luckily the blog does not and will never rely on using the Google Fonts api. However, previously the blog was made using Quarto (here’s an in-depth blog post about why I switched from Quarto), which by default uses Google Fonts. Of course, this seems really only minor, but the problem here is that a user should know if when accessing a website, third-party services are being used. Who knows exactly what third-parties are doing with the data? Quarto using Google Fonts by default is one of the reasons why blog owners were being unknowingly sued. Unbeknownst to the owners that they were using Google as a third-party service.

What does it mean for this blog?

It means that on the pages that I use a captcha, there has to be a notice to the user that this is in fact a Google service and by agreeing you will be verified that you are not a robot. In this process of verification, captcha services, send some data to Google to check that the user isn’t a robot e.g. mouse movements. Aside from this it really doesn’t change much for the blog.

Captcha isn’t fool proof though

Of course, there is still some automated spamming bots that will be able to bypass the captcha. There have been significant improvements though to captcha in version 3. This version is hidden from the user and the user practically doesn’t have to do anything to prove that they are not a robot. However, I do not like this. This to me seems like a glorified way in which Google is able to collect larger amounts of user data all while being hidden in plain sight. Additionally, also hidden being the facade of being able to “prevent spam”. Even if the method, captcha version 2, utilised on this site isn’t completely fool proof, it still prevents some form misuse.

I recently came across a paper that speaks against using captcha’s entirely (at least the ones offered by Google) ¹. In this paper, they suggest Google profits from this service in the order of billions, it is succestible to bots and that it is negatively perceived by users.

So now I am wondering about alternative solutions

The number 1 recommeded solution I have seen is to stop using these Google recpatcha services entirely. But then there is the question about how is it possible to prevent against spam?

1. Use cloudflare turnstile

Cloudflare Turnstile appears to be a better solution. Here it seems that the GDPR compliance is much better overall, but of course will still need approval by the user that the website is using a third-party for spam/ bot protection. Since GDPR explicitly allows using technical information where reasonably necessary, it means that using a service like cloudflare would already be a better alternative compared to using Google.

2. Honeypot

A Honeypot is a term used to describe a hidden element on a HTML page that traps bots. Essentially a spam bot would interact with this hidden element but a human would not. This means you can have a hidden form field, if this field is filled in then the form can be rejected.

3. Time constraints

Another form of protection against spam is a time constraint method. In this method, a visitor to the site has to be on the page for x amount of time before it is possible to send the form. For example, spam bots are able to fill in forms with superhuman speed, something like this would prevent a bot from spamming a form or even submitting a form if they have filled in the form far too quickly.

Conclusion

I am now looking into alternatives that will make the user experience of this blog website better. I don’t want to have to rely on Google services for basic spam protection when there are other methods out there that are either much more GDPR-compliant, more user-friendly and are much more effective at preventing spam.

As a user of this blog site, I still believe in the importance of letting you guys know exactly when a third-party service is being used. Even if cloudflare turnstile is much more GDPR-compliant I still think its a good idea for this to be an opt-in service. Here this isn’t just about saving myself from the law but also about making sure that you know what is going on and how.

Update

In the past 2 hours, I have moved the contact form onto my own dedicated server. What this means is that I am able to have full control over what is being stored. I am also testing out cloudflare turnstile. So far in my testing it has worked well. I suspect to write a blog post about these new changes and how it fits better with GDPR-compliance.