Make WordPress Core

Opened 6 years ago

Last modified 4 years ago

#43879 assigned enhancement

Add tools for anonymizing of post authors

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


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 6 years ago.
Anonymize posts
43879.1.patch (4.5 KB) - added by TZ Media 6 years ago.
Adds helper function from #43880 to anonymize the post_author.

Download all attachments as: .zip

Change History (20)

@TZ Media
6 years ago

Anonymize posts

#1 @TZ Media
6 years 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
6 years ago

  • Type changed from defect (bug) to enhancement

@TZ Media
6 years ago

Adds helper function from #43880 to anonymize the post_author.

#3 @TZ Media
6 years 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
6 years ago

  • Milestone changed from Awaiting Review to 4.9.6

#5 @desrosj
6 years ago

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

#6 @allendav
6 years 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.

6 years ago

#8 @allendav
6 years 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
6 years ago

  • Milestone changed from 4.9.6 to 4.9.7

#10 @TZ Media
6 years 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.

6 years ago

#12 follow-up: @iandunn
6 years 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.

6 years ago

#14 @desrosj
6 years 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
6 years ago

  • Component changed from General to Privacy

Moving to the new Privacy component.

#16 in reply to: ↑ 12 @dejliglama
6 years ago

I Agree with @iandunn on this, putting published posts to a non existing user seems odd.
And as @allendav also mentions earlier, wouldn't it be possible to use the functions we already have for when you delete a user - posts etc. get's reassigned to another user - or deleted ?

#17 @desrosj
6 years ago

  • Keywords gdpr removed

Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.

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

4 years ago

Note: See TracTickets for help on using tickets.