[buddypress-trac] [BuddyPress Trac] #7698: GDPR

buddypress-trac noreply at wordpress.org
Tue Feb 20 15:14:58 UTC 2018

#7698: GDPR
 Reporter:  DJPaul        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Under Consideration
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |

Comment (by johnjamesjacoby):

 A have voiced some opinions in the various chats & meetings that have
 happened since the GDPR Slack channel was created, but I'll recite them
 here post coverage sake:

 * Site owners have an obligation to allow a user to request account
 deletion, but may not have a responsibility to actually delete the records
 themselves based on a number of factors (financial records, government
 open-records, and even cases where deleting the data would cause a severe
 detriment to the overall operation of the site seem to be cases where
 permanent deletion is not a requirement.)
 * I do not like the idea of allowing users to permanently delete
 themselves or their content from the database. I know we've provided this
 in BuddyPress for years, but it's never been a focal point; now that it
 is, it's good we have it, but bad it's going to start being used because
 it's going to wreak some havoc. We have an infinite number of corner-cases
 to consider exactly how deleting all user content echoes through-out the
 conversations they are having. We've started discussing this about Private
 Messages specifically in a different ticket, but my feelings on the matter
 span every BuddyPress component, bbPress, many other plugins, and even
 WordPress core itself with posts and comments.
 * For example, when I delete my email address from Gmail, the emails I've
 sent you are not deleted from your inbox. Your inbox is yours. Your
 contact list is yours. You deleting your account shouldn't (in my opinion)
 permanently delete my history of you. That's some Men in Black type stuff.
 * I do like the idea of having an adequate `user_status` column in the
 `wp_users` database table that enables a first-class "this user chose to
 delete themselves" indicator, without resorting to expensive meta data
 checks in places like list tables and member directories. I've created a
 ticket and approach in WordPress core Trac to tackle this, though I
 haven't patched it as thoroughly as I'd described.
 * The "Privacy" tab in BuddyPress Settings is where any new GDPR/Privacy
 related functionality should live, including the ability to view meta-data
 associated with their account, export that data (in whatever format(s) we
 provide), request account deletion, and the existing account deletion


 Specific BuddyPress Action Items (as I see them):

 * Change our current "Allow users to delete themselves" checkbox into a
 `select` or `radio` options to add the "allow users to request deletion"
 * Decide how to mark users as "deleted" in the database (status, special
 roles, unique user-meta key, etc...)
 * Create a data-export feature, which will likely need to leverage some
 kind of cron or deferment API to scale for potentially large amounts of
 data, generating zip files on the server for downloading, supported
 emails, etc...
 * Decide exactly what to do with related (threaded) user data when it's
 permanently deleted, and likely leverage the same cron/deferment API idea
 above to do this over potentially tens of thousands of records (imagine
 deleting yourself from WordPress.org, across several connected systems)
 * Introduce ability to flag-content feature, for
 ToS/CoC/harassing/violations/threatening/harmful/bullying/spam, etc...
 This should be built to scale across multiple sites/networks/installations
 similar to the rest of BuddyPress, so it can be leveraged on something
 like WordPress.org in the connected forums.
 * Stretch goal: consider (finally) building some type of user-to-user
 relationship type API, so users can block one-another as a front-line
 remediation to avoid community members feeling like deleting their entire
 account is their only recourse to protect themselves from harassment. (If
 we do this, I believe our Friends component should be refactored to use
 this with "Friendship" as a relationship type. Note: this may be easier
 than we think?)


 On the whole, we are ahead of WordPress but simultaneously behind schedule
 and resource constrained. We will need help. This is all a huge amount of
 effort for our small team. I believe if these are needs across
 WordPress.org, BuddyPress is in the position to be _the way_ member
 privacy (and GDPR specifically) is addressed for ourselves and possibly
 the many others in search of compliance.

 If we are outwardly asking the community for help, a BuddyPress.org
 redesign would certainly help reinvigorate the community and inspire
 others to commit their time to helping be a part of all of this.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7698#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list