Add way for registered users to request deletion or anonymization of their private data

[azaozz]

All registered users can edit or delete most of their data in WordPress like name, nickname, email, site, etc. The only exception is they cannot delete or anonymize their own account.

Generally a registered user can contact an admin and request this, but it would be better to have a standard "procedure" to do that. It will need to be confirmed to avoid misuse.

A good way to do that would be to have a simple button on the user profile screen where the user can request anonymization. Clicking it will email the user a confirmation link, similar to the password reset link. When clicked, it will load wp-admin again and will send email to the site admin.

[mikejolley]

The 'confirm' action part of this is being worked on in https://core.trac.wordpress.org/ticket/43443

This issue is for using that, then taking action based on the confirmed link.

[mnelson4]

@idea15 's article ​https://www.connected-uk.com/gdpr-for-business-owners-senior-executives/ makes me understand that users DON'T universally have the right to erasure, so site administrator approval should be given before erasing their data.

Specifically, she said

The RTBF (Right-to-be-forgotten) is not a get-out-of-jail card, nor is it means of censoring difficult or embarrassing information. The RTBF can only be invoked if: The personal data is no longer necessary;...there is no legitimate processing need which overrides their request...
Even then, the right to erasure is not automatic. A company may continue to hold and processing data about an individual if they still have a legal basis for doing so and can continue processing that data for its original purpose. (In other words, you can’t RTBF your credit card bill.)

[mikejolley]

So thinking about solutions to this. Some notes:

1. Plugins need a way (hook?) to delete their own data for a user as well as core.
2. Registered users are not the only people who need to delete data; visitors have the same rights, so this should be done by email.
3. Some data needs to be preserved if there is a business need to hold it. E.g. Holding order data for tax purposes.

With that in mind, the admin needs to be able to control what does and does not get deleted when dealing with a request. In order do to that, plugins and core need to expose what personal data they hold.

My idea is that we:

1. Agree on a schema which plugins may register to describe the personal data they hold for a user.
2. Core loads in these schemas and presents a table to the admin user which shows what data is available to delete, and offers a checkbox/select to:
   • Delete/remove
   • Anonymize
   • Keep
3. Admin selections are then passed to a hook for the delete event and each plugin takes care of it's data based on those preferences.

Anything not exposed in this way would be up to the plugin to handle.

Would a tool like I described about be suitable? Am I missing anything?

cc @allendav

[azaozz]

Replying to mikejolley:

1. Agree on a schema which plugins may register to describe the personal data they hold for a user.

Not sure I understand "register to describe" for plugins. Wouldn't that be the suggested text for the Privacy Policy page?

2. Core loads in these schemas and presents a table to the admin user which shows what data is available to delete...

Not sure if there is a need to select what gets deleted every time a user request deletion. If the plugin holds many different types of data, I rather see this as a setting for the plugin (on the plugin's settings screen). This will make it easier for the admin and be better UX in general. Then when a request for deletion is received and confirmed (when the core hook runs), the plugin will delete the data according to its own settings.

[mikejolley]

@azaozz

Not sure I understand "register to describe" for plugins. Wouldn't that be the suggested text for the Privacy Policy page?

Let me give an example.

In WooCommerce I provide something along the lines of:

Order Billing Address - Used for X
Customer IP Address - Used for y
Customer phone number - Used for Z

This could be in JSON format for example.

WP gathers all of these schemas and presents them to the admin when handling a deletion:

xxx@…

Anonymize | Data
[x] | Comments
[x] | Posts
[ ] | Order Billing Address | Used for X
[x] | Customer IP Address | Used for Y
[x] | Customer phone number | Used for Z

Then they have a way to choose what is kept and what is not.

This was just an idea. It could be handled per plugin but if other plugins have the same use case, this could lead to lots of different UIs doing the same thing :)

Preference?

[xkon]

If we could have permanent selections so the admin doesn't have to select the same things every time it would be a treat to pack this in the core in my opinion. It could easily save you from plugins accidentally deleting something.

I can't imagine though somebody having to check 30 options every time a delete happens, that could be overkill as we don't know how many deletions might actually happen on a website.

If there's no way of keeping what the admins want 'pre-checked' then better leave it to the plugins fully so they can manage it as an option group or something.

[mikejolley]

@xkon We could save the selections as either user option or site option. My only concern is yes, it's another UI. But from our side we need one either way it seems :)

[xkon]

Yes so since we can save it the difference comes to:

1] Give 1 interface with options and a save button to select anything from all the plugins hooked.

2] The admin has to go on each plugin and select what he wants.

That's why if I look at it as a user I'd prefer no.1 instead of having to go on each plugin.

If you throw in the case of multiple plugins writing the same stuff ( i.e. address and even on the same table sometimes as it happens ). It would be even easier if you had a unified list to just keep 1 for example. If you had to go through each plugin separately you might even forget what you have selected 2 mins ago :D.

From an 'experience' and ease perspective, having 1 unified UI/list to mark what you want to keep is way better in my mind.

[tarkan]

Replying to mikejolley:

@azaozz

Anonymize | Data
[x] | Comments
[x] | Posts
[ ] | Order Billing Address | Used for X
[x] | Customer IP Address | Used for Y
[x] | Customer phone number | Used for Z

Then they have a way to choose what is kept and what is not.

This was just an idea. It could be handled per plugin but if other plugins have the same use case, this could lead to lots of different UIs doing the same thing :)

Preference?

I would be happy with a selection basis noted above and a more hands off automated email event driven data deletion, but as mentioned over on github I very much doubt any business will want to (and to stay legal) delete order data - hence I suggest order data should only have one checkbox.

That selection should cover all data obtained for that particular order (billing/shipping address/names/ip/products/emails/invoices/receipts/etc).

[mikejolley]

@tarkan It really depends what you need to preserve though? Example: The address might be needed for tax reasons, but the phone number is no longer needed.

[tarkan]

@mikejolley That is the thing, in our own example the phone number is part of the sales contract, e.g. shipping address and phone number are used to ship the goods (certain couriers require phone number).

From our point of view the phone number is integral for us in performance of the contract the customer has entered into with us.

Hence why any data that the customers has given us in connection with that order, needs to be retained and any Right to Erasure mechanism has to allow us to do that.

I know it has not been mentioned yet !! - but for example our VAT record keeping rules stipulate that we keep order notes and related information - like quotes or exchanges from the customer.

Examples we have been given is emails, customer notes or comments - to show and satisfy the tax authority that a particular transaction has occurred and the circumstances for it, if demanded (for 6 years).

Bottom line for us Order Data is hands off - and I would imagine it is the same for any EU based VAT registered business.

[azaozz]

Replying to mikejolley:

I understand, thanks.

Still thinking the selection of what is deleted (or anonymized) should be in the plugin. Then the admin/site owner doesn't have to repeat the same thing every time (and remember which fields to select), and the plugin is in "full control" of the deletion/anonymization.

Also chances are that other plugins that store the same data may or may not need the same data fields. Each case is different.

In case of plugins with extensions, IMHO best would be if that data selection is done in the main plugin and all extensions share/use it.

[dejliglama]

@azaozz and cc @allendav
I think this ticket is outdated, and now covered by

https://core.trac.wordpress.org/ticket/43443 > @mikejolley

And
https://core.trac.wordpress.org/ticket/43438 > @allendav (This is the core functionality behind the exporter)

https://core.trac.wordpress.org/ticket/43546 > is the UX behind the Exporter...

[allendav]

Replying to dejliglama:

@azaozz and cc @allendav
I think this ticket is outdated...

not quite - @azaozz is proposing a user (front side, not wp-admin) facing form here for them to make a request - the tickets you cite are all wp-admin

[asadkn]

If this is to be done in core centrally it would be great to have a common interface to select what to delete. This wouldn't mean the plugin cannot extend the interface and have their own extended logic to process at the deletion hook.

For example, "Delete Invoices" for a plugin can be a central setting but the plugin may have its own extended settings where it defines rules on when an invoice may be deleted (time duration/tax year, type of invoice). The plugin may also use WP-Cron to schedule a future deletion.

To add to it, it would be helpful if each plugin can add an optional info/message when the request is processed. For instance, "Invoices 100, 99 will be retained for [legal basis] for [time duration]". Or "IP Address logs retained in PluginName for [legal basis] for 30 days."

[edwardsgs]

Beyond Wordpress core, to address GDPR with Wordpress.org specifically (is this the right place to address that?), has the concept of "delete my Wordpress.org account" been addressed? As I understand this isn't currently supported.
​https://wordpress.org/support/topic/how-to-delete-my-wordpress-org-account/

[desrosj]

Moving to the new Privacy component.

[azaozz]

To clear things up a bit: this ticket is about adding two buttons to the user profile screen:

• Delete my account.
• Export my data.

These buttons will trigger the confirmation email directly without an admin needing to do it (we will use the registered user's email for that). As the buttons won't be on the front-end, don't think we will need to care much about misuse, perhaps only reject duplicate requests.

[norcross]

Is this what you had in mind @azaozz ?

​https://www.dropbox.com/s/xq0yuypkn2pc2tb/data-manage-buttons.png?dl=0

[azaozz]

Replying to norcross:

Yes, something like that. Don't think we need one of the buttons to be "primary" (blue). It clashes with the main "Update Profile" button. Also, perhaps can add a short explanation especially for "Export my data", but otherwise this looks right.

[norcross]

This is very much a first pass at this. There are two changes:

• _wp_personal_data_handle_profile_actions added to wp-admin/includes/user.php
• buttons and reply added to added to wp-admin/user-edit.php

it currently is not using an Ajax call, but it could be converted to that easily if that is the route y'all think is better.

[xkon]

Hi @norcross , thanks for the patches!

For the Ajax calls, I guess we either go that way and add a span/p informing that a mail has been sent near the buttons, or simply add an extra notice replacing the "Profile Updated" with a privacy action message to show on refresh instead. But we could grab some UI thoughts on this.

As for the buttons I think that the "Delete My Account" is somewhat misleading as well since it goes into the Erasure requests that are not a complete deletion ( except if I'm missing something here since I was away for some time ). I'd personally stick with what we use in general already i.e. 'Data Export' / 'Data Erasure'.

Any thoughts before going for a patch refresh? ( cc @azaozz )

[desrosj]

This still needs testing and feedback.

[garrett-eclipse]

Moving this off the milestone until it's owned, tested and refreshed.

[paaljoachim]

Profile screen Privacy controls.

[paaljoachim]

The above is a suggestion in regards to Privacy Controls in the profile page.

Text used (as it is a bit hard to read it from the image).

Permissions

Your privacy choices while logged in are saved in the database and will persist until you change them.
You may be prompted to update your consent from time to time.

Your privacy choices while logged out are saved in a cookie and will only persist until the cookie expires, or is deleted.
Your choices will be automatically synchronized once you log in again, but the website defaults will apply until that time.

-Checkboxes-

You have not made any privacy choices yet. For now the site defaults apply. Please update your choices now.

My Data

Enable Privacy Actions -checkbox-
Export my Data -button-
Erase my Data -button-

Your data is handled according to this website's Privacy Policy [link]. It is possible that not all data will be deleted,
but that some data may be pseudo-anonymized instead, or retained if there is another legitimate basis for processing.

[carike]

Related to #51110.
Thanks, Paal! :hero:

[carike]

There was a discussion about this ticket in the #core-privacy channel on Slack and I'd just like to record a summary here so it does not get lost:

1. Clicking the export or erasure buttons should send an e-mail to the user, in a similar way to how password changes from the user profile screen are handled (this means that we can remove the "enable privacy checkbox" on the UI ticket);

2. We were discussing if the user should still be required to re-authenticate (log in again), since that is included in the Regulations for users that have password protected accounts.

While I agree that needing to click on the link in the e-mail is a measure that confirms the user's identity, it is easy to require with the specific minimum requirement in the Regulations. On the other hand, it can sometimes be hard / time-consuming to explain to regulatory authorities that your measures are as good or better. I believe that we should consider doing both.

There has been some concern on Slack during bug scrubs regarding the implication this ticket may have on larger sites.

The scope of this ticket is just to expose the data export and erasure functions, which are already available in WordPress, to registered users on the user's profile page.
We do not anticipate any breaking changes within this scope.

There is a need for a simplified process for sites that do not have data from other sources that they need to collate and for which an automated process (no manual admin approval) would be appropriate.
However, that is not within the scope of this ticket and could be handled through a constant or other such approach to allow for backwards-compatibility.

There has also been discussion about bringing more attention to erasure during user deletion (a separate process which exists separate from data export and erasure). However, that is also not within the scope of this ticket.

[hellofromTonya]

Latest patch applies cleanly.

[garrett-eclipse]

Thanks for applying the patch @hellofromTonya but it is old and refresh was added to flag there's work needed here with the new design and to account for items flagged in comments.

[garrett-eclipse]

I haven't had a chance to get a well rounded patch together going to bump to future release.