[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
stuff.
----
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"
feature
* 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