WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 5 weeks ago

#43437 new enhancement

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

Reported by: azaozz Owned by:
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Privacy Keywords: gdpr needs-patch
Focuses: Cc:

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.

Change History (20)

#1 @mikejolley
4 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
3 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
3 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
3 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
3 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
3 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
3 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
3 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 3 months ago by xkon (previous) (diff)

#9 in reply to: ↑ 5 @tarkan
3 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
3 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
3 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
3 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 3 months ago by azaozz (previous) (diff)

#13 follow-up: @dejliglama
3 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
3 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.


6 weeks ago

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


5 weeks ago

#17 @asadkn
5 weeks 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 5 weeks ago by asadkn (previous) (diff)

#18 @edwardsgs
5 weeks 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
5 weeks 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.


5 weeks ago

Note: See TracTickets for help on using tickets.