WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 17 months 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, 2nd-opinion
Focuses: Cc:
PR Number:

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

Download all attachments as: .zip

Change History (19)

@TZ Media
20 months ago

Anonymize posts

#1 @TZ Media
20 months 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
20 months ago

  • Type changed from defect (bug) to enhancement

@TZ Media
20 months ago

Adds helper function from #43880 to anonymize the post_author.

#3 @TZ Media
20 months 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
20 months ago

  • Milestone changed from Awaiting Review to 4.9.6

#5 @desrosj
20 months ago

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

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


20 months ago

#8 @allendav
20 months 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
20 months ago

  • Milestone changed from 4.9.6 to 4.9.7

#10 @TZ Media
20 months 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.


20 months ago

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


20 months ago

#14 @desrosj
19 months 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
19 months ago

  • Component changed from General to Privacy

Moving to the new Privacy component.

#16 in reply to: ↑ 12 @dejliglama
18 months 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
17 months ago

  • Keywords gdpr removed

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

Note: See TracTickets for help on using tickets.