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

Kirby 3 Solved ✅
1

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.

Abstract

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!

Note:
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.

P.S:
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
2

thank you @anon77445132. 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
3

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:

2 Likes
4

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

5 Likes
5

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
6

@warg:
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]

[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:

[/Added]

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

1 Like
7

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
8

Thanks for the integration into the development branch.

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

9

Can you clarify which point you refer to as the second problem? I’m not too certain here and it might be that it’s fixed, if I’m not mistaken. I might provide more information then.

10

My remaining problem is:

The username has to be unique and the email can be empty.

11

I see. This is what I suspected to be the problem left. As of Kirby 3.2.0, we got this:

Does this help? I hope!

12

I need a plugin or something else because I’m not able to program in vue.

13

For 3.3.0, the name has been removed from the registration mask.

A custom Panel login is indeed the solution, yes. The alternative is to use random email adresses, e.g. old username + @ + a random domain name. No coding required for the second option.

14

But a user has to remember this in the first line of the login screen of the panel.

15

If they all use something like @test.de or example.com, then that shouldn’t be too difficult to remember.

Using the email address instead of a user name has been a feature request for v3 that was very high on the list, so we implemented that.

16

But that was in front of the German DSGVO, where this information is protected.
But that I wrote in the top article of this thread.

17

Just a warning about this: This can cause legal issues and will cause issues with password reset processes via email or some kind of automated emails. There should never be an email address used whichs’ domain is indeed registered by someone else. I’m mentioning this because test.de is the domain of the very well known Stiftung Warentest.

1 Like
18

You can use “example.com” or “example.net”, but that is not what I want to use in an login!

They are registered in a RFC for testing and documentation. Every router ignores these addresses!

1 Like
19

Password reset via email however requires you to store the email, anyway.

20

@anon77445132

As far as I can tell, no one here is a lawyer, specialized in data protection laws, GDPR and DSGVO. That means that this entire discussion is based on assumptions. This field is way too complex for anyone of us to come to conclusions after going to a few trainings or reading paragraphs. Even experienced lawyers often have issues to give solid advice in this field.

Storing usernames brings the same problems as storing email addresses. They are by no means anonymous by default. They also count as a personal identifier and leave the site owner with the same responsibilities.

I also wonder about the cases where the site owner is legally required to store email addresses for their users. I.e. to clarify content ownership or reliabilities.

Kirby 3 offers multiple ways to circumvent this entire issue – as @texnixe already described above. This means you are free to setup your own solution that fits the requirements of your organisation, if our default way does not fit. Staying on Kirby 2 is another one. As pointed out, even giving away anonymous email addresses like random.number@yourclub.comfor each member of your club would be an option. This would in fact be even more reliable than hoping that none of your members uses firstname.lastname.birthday or their Twitter handle as their username.

With this, we already offer more ways to work around potential problems than the majority of systems out there – which most of the times even require email address ownership verification in order to create accounts.

I also don’t understand the argument that users change their email addresses more often than their usernames. I ran a bookmark service with 120.000 users for more than 7 years and I can definitely tell from personal experience that this is not true.

Saying that our account system prevents DSVGO-/GDPR-compliant websites without a qualified assessment from a legal expert in that field is not acceptable.

For example, you quote the Telemediengesetz and the requirement that every service can be used anonymously and you use this as an argument that Kirby must work without an email address in the first place. With this conclusion, you just declared pretty much any online service on this planet to be illegal under German law. I can’t even sign up for Elster Online or the online citizen service of my city without an email address. You should not make such conclusions and put them out here in a way that seems to be a fact. You commented that you cannot discuss legal matters, but you actually then do in a very extensive matter.

We take data privacy and security seriously and when an expert in either field tells us that there’s a problem and we must act, we do so very quickly. Countless projects are built with Kirby every day and bigger organisations run their own security and data privacy assessments regularly before they accept a new CMS.

Such threads in a public forum that mix facts with personal assumptions are very difficult for us. They actively hurt us as a company and thus also the product and the community. For new visitors, this discussion can easily be read in the wrong way and lead to the conclusion that you cannot build GDPR-compliant sites with Kirby, which is just not true.

We also fixed the initial issue with the field and presented a couple solutions to your second problem – without even having real evidence from a lawyer’s perspective that it is in fact a problem. You put yourself in the position that those solutions either don’t work for your project or you are not able to use Vue.js and that’s why you cannot fix it. You also don’t want to use the tools we provide to suggest new features or report issues on Github. That’s all your decision and that’s fine, but you cannot expect us to keep on supporting you even beyond that.

From countless conversations on Github and here, I think everyone can see how much we are interested to find solutions together with the community that work for everybody. In fact, switching to email addresses was a community decission. We got so much feedback for v2 to leave usernames behind that we finally made this step in v3. We didn’t pull this idea out of thin air.

We are happy to pick such discussions up in a more productive way and when the assumptions are gone. Until then I’d like to close this thread.

8 Likes