WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 10 days ago

#43879 assigned enhancement

Add tools for anonymizing of post authors

Reported by: TZ Media Owned by: tz-media
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Privacy Keywords: has-patch needs-testing needs-unit-tests gdpr 2nd-opinion
Focuses: Cc:

Description

Logged-in users that post content can request the removal of their personal data.

So we should add functionality to add the posts to the erasure infrastructure that is already committed to trunk.

See #43442 for reference (anonymize commenters).

Attachments (2)

43879.patch (4.5 KB) - added by TZ Media 4 weeks ago.
Anonymize posts
43879.1.patch (4.5 KB) - added by TZ Media 4 weeks ago.
Adds helper function from #43880 to anonymize the post_author.

Download all attachments as: .zip

Change History (17)

@TZ Media
4 weeks ago

Anonymize posts

#1 @TZ Media
4 weeks ago

Here's my first shot on a posts anonymizer.

I'm currently setting the post_author to the non-existing ID 0 (same ID the comments anonymized uses). And I'm not changing anything else, because when non attached to a user anymore, I believe the post does not contain anything that might be considered personal data (if the content is clean, but we don't check that for comments, either).

As the post itself does not store the author name in some form, I can't set it to __( 'Anonymous' ) or something else.

#2 @TZ Media
4 weeks ago

  • Type changed from defect (bug) to enhancement

@TZ Media
4 weeks ago

Adds helper function from #43880 to anonymize the post_author.

#3 @TZ Media
4 weeks ago

#43880 provides a helper function to get an actual user ID to anonymize the post_author.

43879.1.patch needs the patch from #43880 applied to be tested.

#4 @desrosj
4 weeks ago

  • Milestone changed from Awaiting Review to 4.9.6

#5 @desrosj
4 weeks ago

  • Owner set to tz-media
  • Status changed from new to assigned

#6 @allendav
4 weeks ago

As part of an overall erasure flow, wouldn't that include at some point deleting the user's account too? And then wouldn't that unassign their posts (or reassign them to someone else)

Do we need this in that case?

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


4 weeks ago

#8 @allendav
4 weeks ago

Also worth considering - if we anonymize a user's posts away and then remove that user (not unlikely for a right to erasure request), wouldn't we lose the existing core ability to reassign that user's posts to an existing user?

This probably bears further consideration before adopting.

#9 @desrosj
4 weeks ago

  • Milestone changed from 4.9.6 to 4.9.7

#10 @TZ Media
4 weeks ago

I wanted to automate the process of reassigning all posts to the same "Anonymous" user for all such requests. Manual reassignment would allow assigning the posts for each post to a different user, which bears the risk of having the posts still distinguishable, at least to the admin if he takes notes of which user's posts were assigned to which other user.

Also, manual account deletion bears the risk of human failure.

It is right that the automated process of reassigning the posts does not allow for later deletion of "all posts by that user". Bit do we need to delete them anyway?

We might need to inform the user that when he confirmed the gdpr delete request, that his posts will be anonymized, and if he wants any of them deleted, he must do so before confirming the request.

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


4 weeks ago

#12 @iandunn
4 weeks ago

I'm leery of actually deleting a user from the database, or reassigning anything to a single "Anonymous" user. I think that will likely break some integrations, automated workflows, etc.

I think it'd be much safe to simply anonymize the user's personal info, and leave the user in the database with the same ID, etc.

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


4 weeks ago

#14 @desrosj
10 days ago

  • Milestone changed from 4.9.7 to Future Release

Moving gdpr tickets that are not bugs to Future Release until the next steps can be properly evaluated.

#15 @desrosj
10 days ago

  • Component changed from General to Privacy

Moving to the new Privacy component.

Note: See TracTickets for help on using tickets.