Change (or not) the user's data deletion policy

(Stéphane de Labrusse) #1

The GDPR protects the data of users on your systems, you must for example remove all the data of users if asked and you must do a lot of stuffs more of course(thank GDPR). But when you are an enterprise, the data of your employee might be owned by the company, and even if the employee left the company, you could need some of his email, files in his home, addresses of his customers, his agendas…

Actually when you delete a user in the server-manager, you remove all the data owned by this user.

Hence we could have two ways to protect the data of a possible erasure, one conservative, one active

  • We could only state in the documentation, if you want to keep the data of a user, please deactivate the account in the server-manager…simple and efficient, but I must add too the @giacomo’s sentence : Less code, less bug :smiley:

  • We could make a global property in the esmith database and do not remove the data when the event user-delete is launched. This way might be better for me because in a real environment, you are several admin and an error could occur…damn I removed the user. Of course backup are for this situation, restore data removed.

(Mark Verlinde) #2

Up front, I am not a system administrator; my insight can be completely wrong :sunglasses: ; and am curious about the opinion of experienced sys-admins

(As said in one sentence before @gitbub)
I think deleting the user (primary key) and keeping the data (records) in the live environment on disk and in the databases of the applications seems to me as a bad thing to do.

Ideally the user-data of the removed user would be retained on a more static place. To make it even more complex ( sorry @giacomo) : do this asynchronous by a “garbage collector”. A cron job querying the account provider for non-existing users and moving the user-data to this static place…(This would make it work with all variants of account-providers)

But let’s take some distance and try to describe the behavior of the solution with the simple keywords:
{ shall , shall-not , may }

my 2ct:

The solution shall :

  • make it possible to remove all user-data immediately
  • make it possible to retain user-data
  • make it possible to delete all user date any given time after retention

The solution shall-not :

  • Orphan user-data, making it very hard to delete all user-data any given time after retention.

The solution may :

  • Keep retained user-data in the live environment.
(Davide Principi) #3

Really nice idea Mark! An original way of considering the remote accounts provider use case…

Could you make an example?

(Mark Verlinde) #4

do not want to rule out:

(Davide Principi) #5

Thank you for clarifying!

What are you thinking about?

(Mark Verlinde) #6

Do not have a clear vision. :grinning:

In my mind is the project-data archiving after finishing it I encountered a lot, move the (static) project data to a “cheap” storage.
Do not bother cleaning it up, just move it out of the (expensive) live environment. You may argue user-data is so limited this is not really a issue… But carrying it around forever does not appeal to me.

(Davide Principi) #7

I like the garbage collector approach because it allows to decide how long data is to be retained.

However we have to think about an easy implementation :thinking:

(Mark Verlinde) #8

You are right, did not think of this. You may retain the user-data for x period of time before the “garbage collector” kicks in.

May be not easy, but it can be simple (that are the most rewarding ones)

However still curious about the 2’ct of experienced sys-admins :grinning:

(Michael Träumner) #9

In my opinion the admin should choose to delete all data by deleting a user or to save the data. To save the data I like the way of @mark_nl

It should be possible to delete all the data after a time is “one click”.

(HF) #10

I believe there are some more legal considerations to make.

Employee data is always owned by the company. Data of a consumer must be GDPR compliant and to be wiped in an instance on first request.

I myself am using Nethserver in commercial environments, where the data is always owned fully by the client. I do not even know what they store, but still I am ‘processing’ personal data, or at least that could be the case so with that possibility, my company serving clients based on Nethserver, has to be fully GDPR compliant.

It is a legal issue that, in my opinion, should be discussed first. For a US customer (not an employee) must have choices, where a EU customer can demand…

My 2cents