DSGVO-/GDPR-compliant website with author fields using Kirby 3

In Germany, all websites must comply with the “Datenschutz-Grundverordnung” (DSGVO), the German version of the General Data Protection Regulation (GDPR), by 25 May 2018 at the latest.
Due to this legal requirement I have some technical problems with the upgrade of a Kirby 2 website of a German sport fishing club from Kirby 2 to 3, for which I hereby request the technical support of the Kirby team members and particularly @bastianallgeier.

Please do not discuss legal matters here!

Since this is not a security problem, its solution can be discussed publicly.

During the development of the previous website of the Sportanglerverein Barchfeld e.V., short: SAV or club or association, four years ago I followed everything from the beginning on the basis of Kirby 2, which still today fulfils the regulations of the current (new) DSGVO, as long as the website uses Kirby 2.

Unfortunately, I haven’t found a solution yet how this website under Kirby 3 can meet the requirements of the (new) DSGVO:

As you surely know, the e-mail address of every human being (like "John.Doe@example.com" in contrast to non-personalized e-mail addresses like "mail@getkirby.com" or "support@getkirby.com") is one of the information protected by the (new) DSGVO.
Is it really permissible (and otherwise wise) under the DSGVO to use this information as a unique key field for a Kirby user?
From several DSGVO training sessions of different German lawyers specialised in the (new) DSGVO, unfortunately I have to question the permissibility at least with regard to the DSGVO.

For each individual storage of such an e-mail address of a person (e.g. as author of a blog article) in the content files of the individual (blog article) web pages of a website, the website owner must be able to legally prove a DSGVO-compliant authorisation to store this e-mail address at this point instead of the (in Kirby 2 anonymous) user identification/user name of the same user. In practice, this means being able to prove this on paper with the author’s physical signature with reference to each individual blog article and its author. Many German judges are not really open-minded about EDP, so in case of doubt you need a paper-based permit with a physical signature for every storage of such data, if you want to be sure if at some point the “peace” between the former club member who wrote the blog post and the club no longer exists.

Also nobody can be obligated to disclose his possibly existing e-mail address, since there is no legally constructible necessity in the life of an association (club) that every member of the association discloses his e-mail address, as far as it exists at all, to the association.
The use of fictitious e-mail addresses (an e-mail address is expected as the registration name of Kirby 3) does not lead to the goal from a practical point of view.

But this is only a small part of the same problem:

In addition, underage children, for example, as long as they are not yet subject to compulsory education in Germany, usually do not have their own e-mail address. How reads their e-mail address as Kirby user to the member administration, since they were registered as member partly already shortly after their birth by the proud parents with the association as members?
In Kirby 3, the e-mail address of every Kirby user must be unique, so we cannot use the family e-mail for all family members under Kirby 3 as opposed to Kirby 2, or leave this field empty! It is not specified in any German law that the communication with a user must take place via his e-mail!

Very old association members have, even if younger humans can hardly imagine that, partly no e-mail address. They are also not legally obliged to maintain such an e-mail address. What is their e-mail address in Kirby 3?

E-mail addresses as well as mobile phone numbers in Germany are not permanent contact data of a real living human being aggravating this problem. Some people change these with every new mobile phone, e.g. annually. The maintenance of these changes is disproportionate and was not necessary under Kirby 2.
So how can I or the club avoid in the future that the entire content has to be searched and changed in the affected fields (e.g. author of a blog article) just because its author has a changed e-mail address? In addition, the time of the content file of the affected web page(s) in the operating system of the web server changes without “really” changing the content.

But there are other points:

Under Kirby 2 the username, also called nickname, was the unique name of each Kirby user of a Kirby website, which was also stored by the Kirby panel in the content files for fields of the “type: user” e.g. in blog posts. When changing from Kirby 2 to 3, the content of all blog articles, for example, must also be changed once in the current Kirby 3 version, because in new posts of the same user, unlike websites created under Kirby 2, a different content (his e-mail address) is stored in the User/Users field.
There is a script on https://getkirby.com/docs/cookbook/setup/migrate-users#update-user-fields that can change the content regarding the user IDs after the change from Kirby 2 to 3. But I don’t think such a thing should be necessary to run a website while it is running if a user (e.g. as an author of blog articles) has changed his e-mail address.

According to my understanding of the DSGVO, every user has the right to access websites under a nickname/pseudonym. According to my tests, Kirby 3 does not currently allow this, every user must have an unique e-mail address.
Unfortunately, the current Kirby 3 version does not (any longer) prevent two different users from using the same username. So I cannot use this field as a key field.
Can you please make this field “Username” (possibly as config-option for DSGVO-compliant websites) unique again and a mandatory field? From my point of view this would be a solution to make Kirby 3 DSGVO compliant.
I would then only have to adapt or replace the login mask and, if (really?) necessary, reintroduce fictitious e-mail addresses. Even if I will probably need the support of the Kirby forum for the implementation of this code.


I’m looking for a solution with which Kirby 3 can be used under the listed boundary conditions, e.g. using Kirby options or suitable Kirby 3 plugins:
How can I use a (possibly different) author field in Kirby 3 that doesn’t store the e-mail address and how can I change the Kirby default settings to the Kirby 2 settings for the users in the panel including the corresponding login in the panel and frontend?

Thank you in advance for solving or supporting this complex problem!

If an issue on Github is required to solve my problem, please create it for me. DSGVO-/GDPR-compliant I also pursue the goal of not maintaining avoidable access of websites (such as Github) to my e-mail (in DSGVO-German this is called “data economy”, because I would have to leave my personal e-mail address there; fake addresses are no solution to this either).
Thank you for supporting me also in this DSGVO-compliant way.

Unfortunately I did not find a hint on https://forum.getkirby.com/ or on https://github.com/getkirby/kirby which enabled me to avoid this request. Issues that have not been resolved do not help me, especially if they are not assigned to a solution point in version planning.

1 Like

thank you @HeinerEF. being from germany myself i sincerly appreciate the detailed explanation of this issue.

in early k3 versions the account folder name of the user did match the email but that changed and an unique id is used. the emails is stored in the account metadata file.

the user field still uses the email as reference but with dsgvo in mind an option could be added to use the unique id or any other custom user blueprint field (like nickname). the issue with the nickname being unique or required on registration would not be solved by core but under your resposibility (hooks etc).

another solution could be to abstract the validation of the user id reference (aka the email). the default would be the email validator but it could be any other regex. this should be possible in php and vue without major changes.
further more the name of the field could be made an option so it could be „nickname“ and a user blueprint could still have an email field (but not used as reference).

1 Like

A custom Panel login screen with a user nickname field and validation to make sure it is unique could probably solve this problem.

I agree that storing the ID rather than the email address in the user field would be better and there is already an issue for this on GitHub. However, instead of a users field, a select field could be an alternative (where you can already store what you want) or a custom users field. If you store the ID instead of a nickname, you wouldn’t even need the custom Panel login.

There is now a PR:


The users field issue will be solved in 3.3.0. Here’s the PR that stores the ID instead of the email address: https://github.com/getkirby/kirby/pull/2154


A short addition to this: The #GDPR (German: #DSGVO) does implicit this, although it’s not that clear. In Germany it’s a clearly stated legal requirement due to its mention in the German law called Telemediengesetz (§ 13 TMG).

I really appreciated the time you took to explain this situation in detail :slight_smile: .

1 Like

I fully agree with the content of your remark.
That is why I have written:

and not:

“Datenschutz-Grundverordnung” (DSGVO), the German translation of the General Data Protection Regulation (GDPR),

[Added 2019-09-30 21:45]
As you wrote, there are more German laws besides the DSGVO that complete the content of the underlying GDPR. I want to add particularly the NEW version of the "Bundesdatenschutzgesetz ( BDSG)". An English summary can be found at https://en.wikipedia.org/wiki/Bundesdatenschutzgesetz.

That is, why I used “DSGVO” instead of “GDPR”. Please take this difference into account when reading my top article.

[Added 2019-09-30 23:00]
For me as an civil engineer, look at HowTo: Start Kirby development on a PC:
In many areas I am not able to conduct a legal discussion on my own. Of course, I have to advise my friends or the company I work for at my professional borders so that they do not have problems later due to mistakes and possibly stand in court or cannot successfully assert their legitimate interests legally. In this respect, it is my understanding that one of my tasks is to be able to think outside the box even at these knowledge limits.
This is why I wrote in the introductory article:


I am curious to see how this second part (“and”) of my abstract will be implemented.

1 Like

I have translated an excerpt from the German Telemediengesetz (“TMG”, in English: “Telemedia Act”), thankfully linked by @warg, which also applies to the owner (called “service provider”) of German websites (called “telemedia”) for readers who do not speak German:

Ҥ 13 Obligations of the Service Provider
(6) The service provider shall enable the use of telemedia and their payment anonymously or under a pseudonym as far as this is technically possible and reasonable. The user has to be informed about this possibility.

1 Like

Thanks for the integration into the development branch.

May I ask you how the solution of my second problem is?