WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 3 months ago

#43437 new enhancement

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

Reported by: azaozz Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords: dev-feedback needs-refresh has-patch needs-testing
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

43437.diff (3.1 KB) - added by norcross 14 months ago.

Download all attachments as: .zip

Change History (32)

#1 @mikejolley
20 months ago

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.

#2 @mnelson4
20 months ago

@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.)

#3 follow-up: @mikejolley
20 months ago

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

#4 in reply to: ↑ 3 @azaozz
20 months ago

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?

  1. 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.

#5 follow-ups: @mikejolley
20 months ago

@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?

#6 @xkon
20 months ago

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.

#7 @mikejolley
20 months ago

@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 :)

#8 @xkon
20 months ago

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.

Last edited 20 months ago by xkon (previous) (diff)

#9 in reply to: ↑ 5 @tarkan
20 months ago

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).

#10 follow-up: @mikejolley
20 months ago

@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.

#11 in reply to: ↑ 10 @tarkan
20 months ago

@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.

#12 in reply to: ↑ 5 @azaozz
20 months ago

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.

The alternative of storing all possible types of private data in core and the user has to enable/disable them per plugin is even less attractive. Imagine a page full of checkboxes that will need to be updated when a new plugin is installed or a plugin is updated :)

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.

Last edited 20 months ago by azaozz (previous) (diff)

#13 follow-up: @dejliglama
19 months ago

@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...

#14 in reply to: ↑ 13 @allendav
19 months ago

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

This ticket was mentioned in Slack in #gdpr-compliance by jeffr0. View the logs.


18 months ago

This ticket was mentioned in Slack in #gdpr-compliance by tz-media. View the logs.


18 months ago

#17 @asadkn
18 months ago

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."

Last edited 18 months ago by asadkn (previous) (diff)

#18 @edwardsgs
18 months ago

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/

#19 @desrosj
17 months ago

  • Component changed from General to Privacy

Moving to the new Privacy component.

This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.


17 months ago

#21 @azaozz
16 months ago

  • Keywords gdpr removed

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.

#23 in reply to: ↑ 22 @azaozz
15 months ago

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
14 months ago

#24 @norcross
14 months ago

  • Keywords has-patch needs-testing dev-feedback added; needs-patch removed

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.

#25 @xkon
13 months ago

  • Keywords needs-refresh added

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 )

#26 @pento
13 months ago

  • Milestone changed from 5.0 to 5.1

#27 @desrosj
10 months ago

  • Milestone changed from 5.1 to 5.2

This still needs testing and feedback.

This ticket was mentioned in Slack in #core-privacy by desrosj. View the logs.


9 months ago

This ticket was mentioned in Slack in #core-privacy by desrosj. View the logs.


9 months ago

#30 @garrett-eclipse
9 months ago

  • Milestone changed from 5.2 to Future Release
  • Version set to 4.9.6

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

This ticket was mentioned in Slack in #core-privacy by azaozz. View the logs.


3 months ago

Note: See TracTickets for help on using tickets.