Provide a way to check whether a user's data has been erased

[dennis_f]

There should be some way for plugins to check for completed personal data erasures, so they won't store any personal data afterwards for those users.

Consider the following scenario:

1. Plugin X saves user IP address when they sign in
2. User requests personal data erasure
3. Administrator completes the request and Plugin X deletes the user's IP by using the "wp_privacy_personal_data_erasers" hook
4. Administrator removes the request
5. The same user signs in again later. The plugin saves the user's IP address again since there is no way for the plugin to know that this user had requested a personal data erasure.

Right now, when you click on the "Remove Request" button, the request (post) is completely deleted from the database and there is no record of the erasure.
So, if the requests were not completely deleted from the database after clicking on the "Remove Request" button, but for example stored with a custom status such as "completed-removed", this would allow us check if a particular user has requested data erasure and therefore not store any personal data about this user anymore. Or alternatively there could be a flag stored in user meta upon erasure.

[azaozz]

Yes, this is an edge case that would need more consideration: what happens in cases where "new" data is added after an "erasure request" has been fulfilled.

For the technical part of it thinking that requests should not be removable, just like post revisions are not removable. They provide an important "audit trail" that is needed on all websites and can be used as information for privacy audits.

We are talking about implementing persistent logging for user privacy actions, but at the same time let admins delete the main part of them...

[TZ Media]

I'd like to raise the question if the "right to be forgotten" can and/or must be applied to future events, or includes a "right to be ignored" in some way.

Consequently a person (defined as email address) who did a removal request in the past should not be able to comment using the same email address if the removal by definition includes the request that in the future no data associated to that email address must be saved.

I can't believe that GDPR or any other privacy law would demand that no further data can be saved from a person that used the "right to be forgotten".

From my understanding (and ianal) a RTBF request only covers past data, and if I don't want that site to store any new data on my person, I should simply not enter any personal data on that site, or better, don't access it at all if it stores personal data by just visiting it.

[subrataemfluence]

@TZ Media has raised quite an interesting point!

I can't believe that GDPR or any other privacy law would demand that no further data can be saved from a person that used the "right to be forgotten".

The question is if I chose "right to be forgotten" and erase all my "existing" data from a site at a given point of time, does this mean this is a Permanent Rule has set by the site for that email address?

There is every chance that I come back, use the site and allow it to "store" my personal data at a later point. I only removed personal data for the time being! How GDPR law deals with such a situation?

And if this is not Permanent, how long a site remembers my "right to be forgotten" settings?

[dejliglama]

Given that you have to actively request consent from a user before collecting data, when you reach:

"5.
The same user signs in again later. The plugin saves the user's IP address again since there is no way for the plugin to know that this user had requested a personal data erasure."

You don't have "the same user" details, and that user would be asked to re-confirm the collection of data.

But you are right that an off-site log of any GDPR related activity would need to be in place in order for plugins and core to see if any actions have previously been applied to a user (known entity via e-mail)

[desrosj]

Moving to the new Privacy component.

[garrett-eclipse]

Thanks @dennis_f I appreciate you sparking a lively discussion here. I've closed this ticket as invalid which I'll elaborate on, if you feel there's outstanding requirements that need to be addressed in core feel free to re-open with additional information.

I'm specifically closing this ticket as the right to be ignored isn't actually part of any existing or proposed laws.

The right to be forgotten on the other hand is part of the GDPR legislation ([Article # 17](​https://gdpr-info.eu/art-17-gdpr/)) and covers erasure and archive retention. WP core provides the erasure request interface to Admins to assist in erasure requests from site users.

While core wouldn't implement an ignore list as it's not part of regulations and could pose issues with user experience especially in cases where an IP is shared (such as an networked office) I would lean towards more that this type of feature would land in plugin territory if anywhere. That being said in core there will be logging implementations specifically for auditing so the functionality they provide may be useful for a ignore list plugin.
Logging Tickets; #43797, #44043

As well I agree with your points on the requests shouldn't be removable for audit/security reasons and the good news is that there is already tickets to cover that;
Archive Tickets; #44222, #43912
So potentially, with them being retained you could build a plugin for your desire to create an ignore list.

With all that being said I would caution that implementing such an ignore list will essentially block users from returning to consent to the collection of their data if they change their minds. Also if IPs are used for the ignore list you would also be blocking any other users residing at that IP location, this would be without their previous knowledge which could leave them confused.