GDPR

[DJPaul]

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.

[netweb]

WordPress has created a ​##gdpr-compliance Slack channel to discuss GDPR compliance

Some of the topics up for discussion:

• What does Core need to add for GDPR compliance
• What can Core do to help plugin and theme authors

You can also follow the make/core P2 GDPR posts: ​https://make.wordpress.org/core/tag/gdpr-compliance/

At the time of writing this, there have been 3 posts:

• ​https://make.wordpress.org/core/2018/02/13/gdpr-compliance-agenda-february-14/
• ​https://make.wordpress.org/core/2018/02/16/gdpr-compliance-chat-recap-february-14th/
• ​https://make.wordpress.org/core/2018/02/19/proposed-roadmap-tools-for-gdpr-compliance/

[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 for full-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.

[DJPaul]

Useful feedback there, thanks @johnjamesjacoby! Lots of items to ponder.

Do you think we need to consider writing any sort of documentation explaining why/how we store data, in order to help site owners explain to their users (if they want to, I guess) why/how they store data? Is it necessary? Or would it be a nice-to-have, vs. spending the time on something more important/more useful (i.e. the items you've suggested, particularly around exporting data)?

[johnjamesjacoby]

Do you think we need to consider writing any sort of documentation explaining why/how we store data, in order to help site owners explain to their users (if they want to, I guess) why/how they store data?

I think so? Probably both on the website for site owners, and potentially in a page in the settings component for users?

Is it necessary?

Again, I think it is necessary, but I'm less confident about the exact verbiage we'd want to ship in BuddyPress itself if/when we start doing user-facing things.

would it be a nice-to-have, vs. spending the time on something more important/more useful

Good question, and for our small team it usually means scratching whatever itches we have at the time. Breaking this down into actionable tasks (via separate tickets) should happen next; that will help us prioritize & scope the work.

[wdfee]

hey guys, thanks for investigating in this topic. I'm from Germany, we already have strict privacy laws, that were largely adapted by the GDPR. A lot of good points in this thread already. One thought on @johnjamesjacoby's list:
To be GDPR compliant user data really has to be deleted completely if requested by the user. Especially sensitive data has to be deleted (name, email ...). I think it would be possible to keep the content of updates and replace user name by "former user" or something like that. Otherwise nobody knows how much sensitive information the user offered inside updates or other profile fields. So I think, to be sure all data of this user should be deleted completely, including updates and profile fields.

[DJPaul]

WordPress seems to be doing interesting work in this area, such as user data export. We might be able to piggy-back onto some of those new screens once it becomes clearer which changes exactly are going to be merged.

[DJPaul]

I think the release after 3.0 could be a short/quick once wherein we add whatever improvements we do in time to help site owners comply.

[HDcms]

Hi,
My minimum wish for the next version 3.0!

a checkbox field at registration (with a link to a GDPR information page)

After as an admin, I disabled automatic suppression.
We made an account deletion form, manual that allows us to optionally know the reason for departure. On this same page, there is a link to suspend his account, which is enough for several members: ​https://buddydev.com/plugins/bp-deactivate-account/.
Perhaps interesting to integrate this method?
Regards

[boonebgorges]

I've created tickets and started patches for data export. They're listed below. I've left Notifications data off the list, because it's not really data created by or even about a user; it's just transient data that's used to display information to a user, and always duplicates the "primary" data elsewhere in the system. Not sure 100% sure that reasoning is correct.

XProfile: #7817 (initial pass committed in [12110])
Activity: #7818 (initial pass committed in [12112])
Messages: #7819 (has patch)
Groups: #7820 (has patch)
Friends: #7821 (has patch)
Settings: #7823 (has patch)
Notifications: #7827 (has patch)

The first two already have patches that show how the export works technically, and include some judgment calls about how the data should be represented. If we can settle on an approach in one or two patches, we should be able to crunch out the other ones, and handle content-specific questions in their respective tickets.

[Edit: Added Notifications after discussion with @johnjamesjacoby.]
[Edit 2018-05-22: Added info about patches]

[r-a-y]

Thanks for your work on this! FWIW, here's the ticket where WP implemented their data exporter - ​#WP43438.

Can we only load this code when the WP data exporter functionality runs, which is on the admin AJAX action?

eg:

<?php
add_action( 'wp_ajax_wp_privacy_export_personal_data', function() {
        require SOME_BP_COMPONENT_PATH . '/data-export.php';
} );
add_action( 'wp_ajax_wp_privacy_erase_personal_data', function() {
        require SOME_BP_COMPONENT_PATH . '/data-erase.php';
} );

I've tested how WordPress does the data export and this functionality is restricted to the site admin. Meaning only the site admin can initialize a data export or erase for a user under the "Tools" admin dashboard page.

For our purposes, would we we want to let users manage their own data requests on a new BP frontend page like "Settings > Data"?

As far as the actual exported data itself, WordPress adds the basic profile information, post comments and links to media URLs at the moment. Interesting to note that blog posts are not included.

[johnjamesjacoby]

this functionality is restricted to the site admin

👎

would we we want to let users manage their own data requests on a new BP frontend page

👍

[boonebgorges]

Can we only load this code when the WP data exporter functionality runs, which is on the admin AJAX action?

Oh, you. Yes.

For our purposes, would we we want to let users manage their own data requests on a new BP frontend page like "Settings > Data"?

Cool idea. Someone should build it. First priority is getting it to work for the admin, because that's the minimum required to allow sites to comply with regulations. Offering it on the front end has potential to introduce more complications (ensuring privacy of exports, etc) so should probably be tackled as a separate project.

[boonebgorges]

Replying to r-a-y:

Can we only load this code when the WP data exporter functionality runs, which is on the admin AJAX action?

Thinking about it more, I don't think we should do this. There are non-AJAX places where WordPress calls the wp_privacy_personal_data_exporters hook, so the part I've currently got in bp-*-filters.php can't be loaded in the way you suggest. As for the exporter callbacks themselves, loading them only on a specific AJAX action means we lose the flexibility of building a front-end self-service request tool, at least without having additional logic for loading the necessary callbacks. I don't have a problem with optimizing, but let's avoid getting overly clever until we figure out the more general shape of things: what the callbacks should look like, how data should be chunked and represented, how it'll be fetched through the interface and by whom, etc.

[r-a-y]

Cool idea. Someone should build it.

See #7826.

Can we only load this code when the WP data exporter functionality runs, which is on the admin AJAX action?

.

Thinking about it more, I don't think we should do this.

Yeah, at the time I didn't study the new code that was written for WordPress. If we wanted to lazyload, you'd also need to run the code on the "Tools > Export Personal Data" admin page and on the BP frontend page. So forget I said anything!

[DJPaul]

Milestone renamed

[boonebgorges]

A pre-release set of data exporters is available via plugin at ​https://github.com/buddypress/buddypress-data-exporters

[boonebgorges]

Marking resolved, in favor of separate tickets. Thanks for your feedback and help, all.