Proposed roadmap: Tools for GDPR compliance

This is a proposed roadmap for adding privacy tools to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The plan is to finalize it at the next #gdpr-compliance chat in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Main goal

Add tools to help sitesite (versus network, blog) owners comply with the GDPR and other privacy laws and requirements.

Add notices for both registered users and commenters on what data is collected in core by default, and why.

  • Shorter texts in core with links to more information. Needs text.
  • Create these “more information” pages on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Needs text.

Create some guidelines for plugins on how to get compliant.

A page (or several pages) on WordPress.org. Needs text.

Add tools to core to facilitate compliance, and privacy in general.

There are few plugins that have started implementing these tools, so we have a nice head start.

The requests to see, download and delete/anonymize private data have to be with a confirmation (double opt-in) to avoid misuse. One possible solution would be to send a token by email when a user or a commenter has requested access to or deletion/anonymization of their private data. Then they will have to submit that token as a confirmation of their request.

TBD: shall we makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). this process automatic or should a site owner perform the action upon receiving the confirmed request?

  • For commenters. The stored private data is emails and IP addresses, the rest is public.
    1. Dialog for requesting to see and download their private data.
      TBD: should that data also contain the public portion?
    2. Dialog for requesting deletion/anonymization of the data.
      TBD: Deletion or anonymization? Or both and let the site owner decide?
    3. Ask for consensus for storing commenter cookies. This can be a (checked) checkbox under the comments form, something like “Save my name, email and site URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in my browser for next time I post a comment. More information”.
  • For registered users. All of the data stored by default is already visible in the user profile (except IP addresses if they have commented on the site), and most can be edited or deleted from there.
    1. Button for downloading their private data, including IP addresses if they have commented. Again, should that also contain the public data?
    2. Button for requesting deletion/anonymization of their account.

Add documentation/help for site owners on how to use these tools.

This should probably be another page under the Tools menu and contain short explanation of what privacy tools are available and how to use them. It could also contain the actual tools, for example an input field for anonymizing commenters by email address.

There are a few things that need clarification:

  • IP addresses may be considered personal data so they need to be deleted or anonymized. However do they need to be sent to the user when requesting to see or download their personal data? They are essentially third-party tokens used temporarily to access the Internet and the users have no control over them. Do other websites make them available?
  • Who are considered “controllers”? All admins on single install and all superadmins on multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site? Are admins on multisite controllers for their own site?

Please post your suggestions in comments so we can finalize the roadmap at the next #gdpr-compliance chat on Wednesday. Thanks @casiepa for helping with this!

#roadmaps