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

[buddypress-trac]

#7698: GDPR
--------------------------+---------------------------------
 Reporter:  DJPaul        |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Under Consideration
Component:  Core          |    Version:
 Severity:  normal        |   Keywords:
--------------------------+---------------------------------
 It's my view that WordPress and plugins and themes provide tools that a
 site owner choose to use to run a site with, and as owner and data
 controller for that site, are responsible for GDPR compliance. I think our
 contribution to that, can and should be, making sure our little piece of
 that stack helps those people comply with GDPR obligations.

 We also don't want BuddyPress to not be used because we make it hard for
 people to comply with GDPR.

 I think a lot of the ideas behind the GDPR complement our own project's
 history and values, such as owning your own data, and being able to set on
 your terms on service on that data; not relying on large monolithic
 networks; and, importantly, not becoming the product yourself (selling or
 giving away your data).

 I spent some time thinking about what the key areas for our efforts in
 this area could be. We need to facilitate:

 * 1. Deletion of user account and all data (by the user, or an admin).
 * 2. Explain what types of data are collected, and how it is used.
 * 3. Data portability.

 == User account deletion ==

 We already offer this as an option to users and admin. We're ahead of
 WordPress. We just need to verify that all data is removed, or anonymised.

 Anonymising the data is de-personalising it, basically making it
 impossible to match a piece of content to its original author. For us, the
 easiest solution is probably to delete the entire content. Otherwise -- an
 example is a message chain, where a user is removed and their messages are
 stripped of identifiers, but because of the context (perhaps a second
 user's subsequent message uses an at-mention), it might make it possible
 to understand who the modified message was written by.

 == Explain types of data collected ==

 We need to add a page to our wp-admin screens, explaining everything. Or
 on our codex. Either way, this will be a useful resource for site
 owners/data controllers to help explain to their users why/what is
 collected.

 We also need to explain we send data to Automattic's Akismet (their
 content, IP, etc) and Gravatar services (MD5'd email address, IP, etc). We
 should consider whether enabling these by default remains a good idea.
 Either way, we need to provide a simple way for site owners to disable
 these. Perhaps, we link out to simple plugins that turn these on/off.

 == Data portability ==

 Some of this involves being able to export user data in a readable and
 reusable format. This is probably the biggest area we are lacking. The
 site owner would currently have to do several database queries and export
 as CSV. Not impossible, but not easy. Maybe as a short-term aid, we
 document a query that does all of this, and look to build user-facing
 export options in the future.  (I know years ago we were very keen on
 importing and exporting user data from one BuddyPress to another.)


 I'd love to get interested people's thoughts on this, so we can agree
 smaller action points, and get things made better.

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