Auto Delete Users after a period of time

[David 279]

Principle 5 of the GDPR requires you to retain personal data no longer than is necessary for the purpose you obtained it for, ideally this means that after a period of time (determined by the admin) Users Data should be automatically deleted or annonymised there is currently no way to show the Admin when a user last visited the site so no way for them to know when to "Forget" Users let alone an automated way to do this.

What is required is

1. Some method of recording when a user last logged into the site
2. An automated way of "Forgetting" users after a period set by the site admin

A further option for sites where sales occur would possibly be to add an accounting delay so that accounting records could be kept. for the period required by different countries laws, after the last purchase by a particular user, but that might need to be added to relevant plugins such as woocommerce

[allendav]

Relevant: GDPR Article 5, Paragaph 1(e) ​https://gdpr-info.eu/art-5-gdpr/

Noteworthy: The wp_users table includes the registration datetime for the user but not the last time they logged in / had their credentials used to authenticate a request.

​https://codex.wordpress.org/Database_Description#Table:_wp_users

There are probably a few factors to be considered before auto-deleting an idle account, e.g. whether or not if the user has provided content (e.g. posts, attachments, comments).

If we do this, the solution should probably allow a plugin to block auto-deleting (e.g. if the user account needs to be retained for legal or contractual purposes.)

[David 279]

One more thing to consider is where a site may have a blog and a sales capacity, in this case a user might purchase something and need their data stored for say 7 years, but if they are only visiting the site then their data might need to only be stored for 18 months, the legal reason for storage must override the consent reason until the point where the consent reason extends the storage time.

To use the above example

Person A visits the site on 1st Jan 2018 - His data will not be "Forgotten" until 1st July 2019
He revisits the site March 3rd 2018 and makes a purchase - His data will now not be Forgotten until March 3rd 2025
He Returns August 17 2020 - His data will still remain until March 3rd 2025 due to his previous purchase
He returns Again 6th June 2024 this time he won't be forgotten until December 6th 2025

It may be that one needs two settings one for blogs and one for sales/legal reasons I'm not sure

[TZ Media]

As discussed on slack, here are my thoughts on how this should be applied to different types of user data:

• Transactional data: There are some legal requirements regarding how long transactional data must be kept. After this period, such data should be deleted ASAP. For data where no legal requirements exist, a period should be stated in the privacy notice, and the data should be deleted ASAP after this period ends.
• Tracking data: Should be kept only for a certain time, and then deleted or at least anonymized, if it is used for statistics afterwards.
• Data used only for statistics should be anonymized from the beginning if possible. I don't believe that there is any law requiring anonymized data to be deleted after a specific time.
• User generated content: Is intended to be published "'till the usiverse explodes", if not otherwise stated by the user or terms of use. At least this is the default functionality in WordPress. We should not delete or anonymize this as long as the user does not ask us to do so, or the content itself violates terms of use or law, in which case we'll edit it or take it down manually. Also we should not block user access to the content in any way.
• User accounts: If there is only transactional data connected to the account, it might be deleted or closed after a certain amount of time. If user generated content is linked to the account, we must keep it open to allow the user to access his content.

Also, we should make all deletion periods configurable, as legal requirements or terms of use may widely differ.

[David 279]

I think all of TZ Media's comments are probably correct save the last

User Accounts should be closed after a period of time according to GDPR, however for certain types of site simply deleting the user will not work, for instance a user with hundreds of posts on a set of forums, in this case there are a few possible solutions I can see.

1. Annonymise the user and delete the user account after a set period of inactivity (set by admin), the user posts would have the user name removed but the posts themselves would remain which may be important

2. Legal contract the user would agree to their account being active in perpetuity UNLESS they specifically request their account be deleted (then see annonymise above)

3. (and I'm not sure if this would be legal) Delete the users account after the determined period of time but leave the User Name attached to any posts they created, this might actually mean delete all account details other than user name

[iandunn]

I don't feel good about the idea of ever automatically deleting or anonymizing anything; there are too many situations where an admin will want to review the action and approve it before it happens.

We can't know how an admin is using their site, what laws apply to them, etc. It's great to give them tools that make it easy to comply with privacy best practices, but I don't think we should ever take away their control over their own site, especially for something as critical as the data it contains.

If WordPress starts automatically deleting people's data, you can bet we'll have some very, very angry users, and rightfully so.

As an alternative, the admin could be periodically presented with a report that shows inactive users, and given the chance to prune them, similar to how admins are shown that plugins need to be updated.

And of course, it'd be easy to add filters, etc, so that a plugin could change the default behavior and turn on automatic deletion/anonymization, if that's what the site owner wants.

[David 279]

Replying to iandunn:

As an alternative, the admin could be periodically presented with a report that shows inactive users, and given the chance to prune them, similar to how admins are shown that plugins need to be updated.

And of course, it'd be easy to add filters, etc, so that a plugin could change the default behavior and turn on automatic deletion/anonymization, if that's what the site owner wants.

That's a workable solution, so long as we have a way of

1. Recording when each user last logged into the site
2. Automatically notifying the Admin when users have not logged in after an admin determined period of time
3. The time period needs an over ride when sales are involved again this needs an admin defined setting in order to comply with different countries laws.

It may actually be better to instead set a notification date rather than a last recorded visit date, you just need a way of comparing dates and only changing the notification date when that date would be further away than is currently set.

If this were really useful the sales notification date would take the financial year into account, this is because the holding of accounting records is typically based on the financial year plus x number of years so as an example in the UK the Fiscal Year (for companies) runs from the 1st of April until the 31st of March, whilst for individuals tax purposes it runs from the 6th of April until the 5th of April the following year, UK Accounting law requires records to be kept for 6 years from the end of the tax year, so any company sales records between 1st April 2017 and 31st March 2018 can all be deleted on the 1st April 2024

Obviously this sales date setting would probably need the likes of woocommerce to write into their code but the ability for the notification date to be set via sales or login date needs to be within the core.

[desrosj]

I am also opposed to deleting any data automatically. I like @iandunn's suggestion for some sort of user flagging as inactive or abandoned, but for now this seems like plugin material. See the ​Slack discussion in the most recent Privacy component bug scrub.