Let’s write a friendly privacy policy [ENG 🇬🇧]

Przejdź do polskiej wersji tego wpisu / Go to polish version of this post

I must admit that the popularity of this blog has exceeded my wildest expectations. At first, I thought I wouldn’t gain many readers and I would be writing to an empty audience. As a result, I never even thought about writing a privacy policy. However, with such growth, it’s embarrassing that I still don’t have such a document, so I decided to do something about it. In this post, I will describe the entire process of writing a privacy policy for this blog.

Right from the start, I want to emphasize that I am not an expert in this field, and the regulations like GDPR are like black magic to me. I will simply write based on the information I have gathered from the Internet and rely on common sense. I hope no lawyer will crucify me for what I write below. However, I am more than open to constructive criticism!

Initial assumptions

Based on my own example, I see a reluctance towards any kind of topics related to GDPR. I think this is due to the form used to create privacy policy statements, terms of service, and other regulations. In most cases, they are simply massive blocks of text divided into paragraphs, which are supposed to look super professional in that form. I believe my attitude is not unique, and more people (if not the majority) have the same thoughts. Reading anything in this form can be an enjoyable experience only for lawyers and hardcore enthusiasts. But is that really the point? To write something in the most convoluted and incomprehensible way possible? Perhaps it makes sense for someone who wants to hide something or smuggle it within a stream of clever and intimidating words. In practice, GDPR is a great thing, whose fundamental assumption should be to protect privacy and ensure the security of ordinary people, citizens, and service users. Everyone should have the right to ensure the security of their data and have the tools to enforce this right.

Can a privacy policy be created fulfilling its role without unnecessary hassle? In my opinion, yes! It is enough to consider the purpose of writing such a document, ask the right questions, and conscientiously answer them while maintaining a coherent form, focusing only on the substance.

What are these questions?

Contrary to appearances, the task of a privacy policy is very simple. As the owner (Administrator) of a website/service/application, we need to provide the user with all the information regarding his/her data. I have divided this into 6 questions that need to be asked:

1. Who is the Administrator (responsible person) of the data collected on this blog?
2. What data is collected?
3. Why are these data collected?
4. Where are these data stored?
5. To whom, besides the Administrator, are these data disclosed?
6. What control does the user have over his/her data?

Let’s start writing!

1. Who

I am the Administrator for the data collected on my blog. Since I am an individual and not a company, and I don’t have any registered business activity related to this blog, the amount of data I need to provide is limited to just the first name, last name, mailing address, and email address, which fulfill the legal requirement of providing a communication channel for users to contact me. In this case, I offer the option of contact through standard postal correspondence or electronically via email.

2. What

At this point, we need to list the types of collected (and processed) data. I must admit that I had a hard time with it myself because WordPress is not like an open book to me, which I fully understand and know where to find specific things. In the case of other scripts that I’ve written from scratch, I have no problem at all. Then I can confidently state that my tools don’t use cookies and don’t collect any data about the people using them, which I usually confirm by making them open-source. However, with a blog, we have external actors such as plugins or even themes that I didn’t write myself, and it’s harder to maintain 100% control over them.

Extension for the Firefox browser called Rentgen proved to be very helpful in handling this matter. It was created by the team Internet. Czas działać!. It allows scanning your own (or someone else’s) website and generating a report focused on whether the page meets all the legal requirements of RODO/GDPR and how it generally takes care (or not) of the privacy of its users. Based on that, I defined what I needed to improve on my website.

Firstly, I dealt with Google Fonts, which are external fonts downloaded from Google servers. It’s a very interesting tactic used by the behemoth, which involves hosting fonts used by many websites on their own servers. Usually, this is done through the gstatic.com domain. But what’s clever about it? Well, every person who visits a website using Google Fonts connects to Google’s servers and downloads those fonts as an external resource while loading the webpage. This way, Google can effectively monitor internet traffic, profile people, and analyze their online activities. All of this is done to know as much as possible about you and serve you content (mostly ads) that will have the strongest impact on you. However, these practices carry many other privacy risks for users. Alright, but how did I protect my readers from this? In a very simple way. All the fonts used on this blog have been downloaded by me and hosted on the server where this blog is hosted. This means that when a user enters here for the first time, he/she has to download the fonts just like before, but does it without contacting Google’s servers. There are many different ways to achieve this, but in my opinion, the simplest one is to use a plugin dedicated to this purpose with a not-so-serious name, called OMGF | GDPR/DSGVO Compliant, Faster Google Fonts. Easy. The simplicity of this plugin makes it a solution that anyone can handle.

Another topic that was problematic on my blog was the Jetpack plugin, specifically its Stats module used for collecting blog visit statistics. Jetpack is a plugin made by Automattic, the creators of WordPress itself. This provides a certain level of peace of mind regarding user data processing because it is a fairly trusted company that values the privacy of its users, judging by the documentation they provide. However, I didn’t like the idea of my readers’ data being sent outside the server on which the blog is hosted, so I decided to find an alternative. After a brief market research, I decided to use the Independent Analytics plugin, which convinced me because it does not use cookies, does not store any data that can identify specific individuals, and stores all statistics on the blog owner’s server.

After appropriate trimming (removing unnecessary functions), Jetpack will still remain on my blog as a plugin because it offers several really useful tools such as a nice and convenient gallery block in the form of a slideshow, which I often use, a Firewall module to secure the blog, and an Akismet module that helps me fight waves of spam attacks that have targeted my blog. These are tools that do not collect any data from my readers, which is confirmed by the documentation provided by the creators of Jetpack, who must be commended for placing a significant emphasis on privacy transparency, with each module of their plugin listing whether it collects data and, if so, what kind. All this information are available here.

As the Administrator of this blog, am I not collecting and processing any data from my readers? I do so through the comment system and contact form, for example.

Let’s start with the simpler case, which is the contact form. Users are required to fill in two fields (email address and message content), while the other two (name and message subject) are optional. All these fields are stored in the database, thus constituting the data I collect. However, it must be acknowledged that none of this information can be considered critical personal data. At most, it could be the email address and/or if someone provides their full name. I would like to point out that these fields can be filled with any information, and the email will still be delivered to me, although I may not be able to reply if the provided address is fictitious. Nevertheless, it is necessary to inform users that this data is being collected in your privacy policy.

In the case of the comment system, the situation is similar, and seemingly even easier since users provide less information – comment content, name, and email address. I intentionally used the word seemingly because, in practice, it is much more complex. This is due to the fact that by default, after a user provides his/her email address, it is sent to the WordPress server, which then passes it to Gravatar, another tool by Automattic (the creators of WordPress). The user-provided email address is forwarded for the purpose of retrieving the user’s profile picture, which will be displayed after adding the comment, provided that the email address is associated with a Gravatar account. Thus, we have two options. The first is to include in your privacy policy that the email address is subject to processing and is transferred to third parties, specifically Automattic, namely WordPress and Gravatar. However, I chose the second option, which may detract from the charm but is definitely better for the privacy of those who comment on my blog. I have completely disabled the Gravatar support, so I do not forward the email address anywhere instead, I only store it in my database as an integral part of the comment. WordPress automatically also retains the commenter’s IP address, so that should be mentioned as well.

After performing the above actions, I used the Rentgen plugin again, and this time, I achieved the ideal state that I would like to see on all websites on the Internet, not just my own.

Now I can say with a clear conscience that my website does not use cookies and does not transmit any data to third-party domains. However, this does not end the matter because data is still stored and processed on my server. Let’s summarize this chapter. My blog collects the following data from readers:

• email address (when using the contact form or commenting),
• name (when using the contact form or commenting),
• IP address (when commenting),
• comment content,
• title of the contact form message,
• content of the contact form message,
• fully anonymized statistical information (number of page views, referring medium, time spent on the page).

I’m not sure if it’s necessary to mention the last one (anonymized statistical information), but it certainly won’t hurt to mention it for full transparency.

3. Why

In the previous chapter, we indicated what data is collected, and now we need to justify it. It is important to demonstrate, and here I quote the law, the legally justified interest of the Administrator. In the case of my blog, the matter is quite simple, and I have already explained why I collect data in the previous chapter. I collect data for the following purposes:

• Contact form – thus allowing readers to directly contact me,
• Comment system – thus allowing readers to publicly express their opinions about the content I create,
• Statistics – allowing me to analyze the popularity of posts in order to choose future topics effectively.

Finally, it is necessary to include a short statement, which I mostly took from the Internet, stating that the data is processed until the user withdraws consent and is processed lawfully, for the specified purposes, which are fully justified and no longer than necessary.

4. Where

In this section, it is important to indicate the specific location where the previously mentioned data is stored (and processed). Additionally, if there are any copies of the data (e.g., backups), it is good practice to indicate their storage location as well. It’s worth noting that often the company’s registered office (or the address under which it is registered) may be different from the data center that handles its infrastructure. This is the case with my blog.

The hosting provider for this blog is ABC Hosting Ltd. (known more by the domain name CBA.pl), but the entire infrastructure is hosted in the data center of LeaseWeb Netherlands B.V. located at Hessenbergweg 95, 1101 CX, Amsterdam, Netherlands, within the European Union. It is crucial for all data to be stored and processed within the EU because European GDPR regulations apply in such cases. While it would be optimal for a Polish website to have everything located in Poland, being within the EU is also acceptable since the regulations are the same.

5. To Whom

It is hard to find a simpler situation than mine because the data processed on this blog is not shared with third parties and does not leave the server on which it is stored. However, if in the case of your website, this data is indeed shared with third parties, it should be indicated here. For example, if I had not stopped using Gravatar, I would have to write in this section that data such as email addresses are transferred to Automattic through the wp.com domain and all its subdomains, which means that they are processed not only outside the server managed by the administrator but also outside the hosting provider’s infrastructure on which this blog is running.

6. What (control does the user have)

The last section in which a ready-made statement about the user’s rights should be included. The point is that the GDPR legally imposes three basic obligations on every administrator:

1. to provide each user, who requests it, with the possibility to access the content of the personal data collected about him/her,
2. to provide the possibility of rectifying the data,
3. to provide the possibility of erasing and consequently stopping further processing of the user’s personal data upon their request.

The above requests must be submitted through one of the given contact methods with the administrators indicated in the first chapter.

That’s it!

Now I suggest taking a look at the privacy policy that I have written for this blog. It is available here. Was it difficult? I don’t think so. Is this format more user-friendly than most privacy policies I have seen? Definitely. Is a privacy policy in this format less valuable? I don’t think so, as it contains all the key information.

I consider this a success. I’m glad I finally wrote a privacy policy for my blog. It also brought me joy to share the progress of this whole process. I also hope that content of this kind will interest someone, help and show that GDPR is not a bad thing at all. When the GDPR regulations came in, everyone rolled their eyes and said that it was just another set of dead regulations that would surely serve corporations. However, it turns out to be quite the opposite, as evidenced by the fines imposed on entities that do not respect (either negligently or intentionally) the privacy of their users. These regulations, as well as the entire system associated with them, are a weapon to fight for your right to privacy. In my opinion, it is worth knowing them, knowing how to use them, and not being afraid to do so.

If you liked this post then you can support me!