[wp-trac] [WordPress Trac] #43443: Add a method for confirmation of requests for deleting or anonymizing of personal data

[WordPress Trac]

#43443: Add a method for confirmation of requests for deleting or anonymizing of
personal data
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  mikejolley
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.0
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gdpr has-patch dev-feedback needs-   |     Focuses:
  testing                                        |
-------------------------------------------------+-------------------------

Comment (by mikejolley):

 > All the WP_Error messages should end with a full stop.

 @ocean90 See check_password_reset_key. If it needs adding it should be
 added to all strings. I don't want to introduce another localisation
 string just to add a ., and want to avoid touching other code for the
 moment :)

 > Why are none of the functions prefixed with wp_?

 Can add - none of the other functions in that file were so I assumed there
 was no standard.

 Addressed the other items of feedback, and renamed some functions with
 what I think is more logical naming.

 @azaozz

 > Consider how this can be used through the REST API and add an endpoint.

 I think this would be separate. Consider these to be helper functions than
 an endpoint could utlize to perform a user action.

 > Perhaps add garbage collection function to delete expired requests.
 > Log confirmed requests and perhaps show them on the dashboard? Typically
 an admin will have to perform the requested action. When a site has more
 than one admin, would be good if all can see pending requests.
 > Prevent "flood" of requests. If a request is made and it hasn't expired,
 perhaps limit how many new requests can be made for the same email.
 Something like 10 should be plenty to cover legitimate user cases.

 These points would be better addressed by a custom table as I suggested.
 It would be difficult to scale garbage collection with the current
 meta/options because it would need to load all and compare the values
 inside the serialized array.

 Which leads on to @allendav's point:

 > I like the idea of a privacy actions log, but since that may lead us to
 having to have a separate db table, I recommend we break that out into a
 separate issue and implement this issue as a priority without that sub-
 feature.

 I agree separate issue but this is the same idea. The generic user action
 confirmations/requests table I'd like to introduce would not only store
 the generated key, date of request, action name, UID, it would also store
 dates of confirmation which serves as a log and could be exposed via a UI.
 e.g. list table showing all rows for action "delete_account".

 Should that be moved out of this issue?

 > Maybe for V1 we just leave request tracking to the administrator(s) and
 their email inbox :)

 I also agree with this. If we just agreed users would contact site
 administrator to request details or anonomize, this system is probably not
 needed. If we want to support form's, the confirmation step is still
 required to verify requests are genuine.

 Sidenote; I am in favour of emailing requests to admin for account
 deletion/details instead of showing new list tables in core. The UI side
 could be let for plugins. For our use, an email with the details of the
 request and some shortcuts to the new export/anonymize tools would be
 sufficient.

 Flow without confirmation:
 1. User contacts admin via email.
 2. Admin generates export via new tools.
 3. Admin sends export to user.

 Flow with confirmation:
 1. User requests export via form or link on site.
 2. System emails user.
 3. User clicks confirm link.
 4. Admin gets email with request and tool links.

 Can we discuss this further? If thats an option we should prioritize the
 new tools over the processes, including this issue.

 ---

 Anyhow, new code is here in my fork here
 https://github.com/WordPress/WordPress/compare/master...mikejolley:update/43443?expand=1

 Functions:

 - wp_send_account_verification_key
 - wp_get_account_verification_key
 - wp_check_account_verification_key

 wp-login action:

 - verifyaccount

 Hooks:

 - account_verification_email_content
 - account_verification_expiration

 @azaozz will send a diff too.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43443#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform