WordPress.org

Make WordPress Core

Opened 23 months ago

Last modified 2 months ago

#44222 assigned enhancement

Add Archive state to privacy requests

Reported by: garrett-eclipse Owned by: garrett-eclipse
Milestone: 5.5 Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords: needs-patch
Focuses: administration Cc:

Description

Hello,

A suggestion for v2 of GDPR is to add an archive/trash state and list view to erasure requests.

Currently, the last state/phase in the erasure process is 'Completed' with the 'Next Steps' action being 'Remove request'.

This automatically prompts the admin to remove and clear the deck. In many if not most cases though the site holds backups which upon site failure will be used to restore the site/content and thus the users PII data. Under GDPR my understanding is the admin is required to re-remove the users data.

Backups are partially safe with GDPR because they are required for site security/integrity, but under retention can only be kept for a reasonable timeframe.

So I was thinking a way to safeguard admins would be to introduce a trash/archive which would have the action for Completed be 'Archive' instead of 'Remove'. This would place the request in the trash and remove from the 'All' view to reduce the clutter. On a new Trash view you're find these requests with the ability to delete permanently.

And I think I heard something about privacy settings at some point in slack which could allow a retention period setting for these archives be set and a cron to auto-remove. So admins would be able to have their database retention and erasure archive retention periods basically match. This would enable them to use the archive list, export it possible, and use it to re-remove users upon database restore.

Most of it is up to the admin to disclose their backup policy and how they'll re-remove users but would definitely help safeguard them from losing requests by running through the workflow too quickly.

Hope that mostly makes sense, mainly just wanted the idea out there.

All the best,
*Note: Most of this is to 'my understanding' so I defer to those more versed in the new regulations.

Change History (9)

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


23 months ago

#2 @desrosj
23 months ago

Possibly related: #43912.

#3 @desrosj
22 months ago

  • Keywords needs-patch added
  • Summary changed from GDPR - Add Archive state to erasure requests to Add Archive state to data erasure requests
  • Version trunk deleted

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


20 months ago

#5 @desrosj
20 months ago

Related: #44707.

#6 @garrett-eclipse
20 months ago

As #44674 is being committed as just 'Delete' wanted to flag that if this moves forward then the verbiage mentioned in that ticket will need to be revisited if an Archive state is implemented.

#7 @xkon
3 months ago

  • Keywords close added; needs-patch removed

I'm a little confused here @garrett-eclipse.

You're mentioning that "Trash" / "Archive" would help on a case of database restoration, how would that be of help though if the database is restored? You're restoring a list that should already contain any "up to that point" requests but any newer than those would've been lost. That includes most likely a full database so everything "after that point" is lost.

The only way to be up to point in case of a backup restoration is by having an extra way of keeping all requests externally as their own backup system and this leads to a different option of being able to import/export your current requests for safekeeping if you wish to.

Am I missing anything on how a Trash action would be of help in this case? We already have all the needed statuses in my opinion for the list to keep itself "clean" as it is, an extra Trash status wouldn't make much of a difference in my opinion.

We can talk about an exporter/importer for the Requests in office hours if that's needed but that's a totally different solution. There have been previous discussions for a logging mechanism (similar to import/export solution) for this as mentioned in #43912, but that hasn't been moved forward either. I'd be more than happy to start discussions on that again though!

I'm marking this with a "close" tag for now but do tell me if I didn't understand something so we can discuss further :).

#8 @garrett-eclipse
2 months ago

  • Keywords needs-patch added; close removed
  • Milestone changed from Awaiting Review to Future Release
  • Owner set to garrett-eclipse
  • Status changed from new to assigned

Hi @xkon

The concept of introducing an archive state to the requests workflow was one that went around quite a bit on Slack and some Trac ticket mentions. Primarily @desrosj and @allendav were contributors who I've discussed the concept with.

With the current workflow one issue flagged early one was the fact users were trigger happy and would click the remove request button as soon as it became available deleting the request. In many cases these requests should be kept for some period of time for auditing and logging purposes.

The idea of database restoration here was mostly to integrate the archived requests with a plugin such as the one you built here;
https://github.com/mrxkon/personal-data-request-backups
This way users could retain in archive their complete requests, export externally and in the case of database restoration they could pull in their exported requests to re-erase needed requests.

Even if users don't opt for the security of an external export the archive state is beneficial in that it cleans up the requests table of completed requests without fully removing them from the system which in some legislations will assist with audits and proving requests have been completed.

Trac references to mentions of this functionality;
https://core.trac.wordpress.org/ticket/44674
https://core.trac.wordpress.org/ticket/44707
https://core.trac.wordpress.org/ticket/44500#comment:3
https://core.trac.wordpress.org/ticket/44266#comment:2
https://core.trac.wordpress.org/ticket/44068#comment:7
https://core.trac.wordpress.org/ticket/43912#comment:4

Slack references;
https://wordpress.slack.com/archives/C9695RJBW/p1527615516000016
https://wordpress.slack.com/archives/C9695RJBW/p1527615406000355

Happy to discuss further here or on Slack but do believe this would be beneficial to users so am removing the close tag.

#9 @garrett-eclipse
2 months ago

  • Milestone changed from Future Release to 5.5
  • Summary changed from Add Archive state to data erasure requests to Add Archive state to privacy requests
  • Version set to 4.9.6

Updated title as this should be implemented for both exports and erasures.

Note: See TracTickets for help on using tickets.