This roadmap contains plans for the privacy component in the near future. It is a work in progress and will be revised as changes are needed.

With the GDPR WordPress core compliance project effectively completed, the Privacy component will continue to work on privacy and data protection issues, not merely as a legal obligation, but as a means of protecting both site owners and user privacy.

The areas of focus will include (but not be limited to) this range of common international privacy conventions and standards:

  • Data minimization
  • Data integrity
  • Purpose minimization
  • Lifecycle limitation
  • Human and technical security
  • Transparency and notice
  • User participation and rights
  • Accountability, enforcement, and redress
  • Choice, control, and consent
  • Special categories of data
  • Legal compliance

All work will be performed using a Privacy by Design (PbD) approach, which seeks to identify and mitigate privacy issues before they happen. All improvements should also be performed with the goal of contributing to a shared best practice definition of privacy in open source software outside specific regulations and laws.

All tickets which are part of the roadmap can easily be looked up by using the keyword privacy-roadmap.

General Improvements

While this roadmap clarifies the main privacy objectives for the next several releases, it is by no means exclusive. Bugs and small enhancements can be addressed as needed. Larger efforts and features should be discussed during weekly office hours and may be added to the roadmap.

Some areas where general improvements are needed in the immediate short term are:

Core Feature Privacy

While the GDPR compliance work focused on adding new features to core, the privacy component aims to continue looking at issues within core to provide a better “out of the box” experience.

Gravatar Privacy Controls

Site owners and users should have greater control over integrations with Gravatar. Gravatars can potentially expose user activity across the web. Hashes can be subject to brute force attacks to reveal the user’s email address or can be found in rainbow tables, exposing the user’s identity.

Related tickets: #44067, #14682

Embed Privacy Controls

Some embeds may utilize cookies and/or collect personal data. For this reason, site owners should have control over which embeds are enabled on their site, potentially limiting what they may need to disclose in their privacy policy.

Related tickets: #43713, #44001

Plugin & Theme Privacy

Plugins and themes are vital parts of the WordPress experience. Administrators, developers, and users should be able to easily understand the way a plugin or theme utilizes their personal data. Plugin and theme authors should be empowered with tools to communicate uses of personal data, allow users to remove or anonymize their personal data, and provide an at-a-glance understanding of data policies.

Administrators

Before installing or activating a plugin or theme, an administrator should be fully aware of any implications those actions will have on any personal data stored on their site. The administrator should be aware of:

  • Which WordPress core privacy tools the plugin does or does not use.
  • What privacy data it collects and how it is used.
  • Any effects the plugin or theme may have on their site.

Support for privacy-related plugin and theme header metadata should be added that allows developers to specify potential effects on data privacy, and which WordPress core features are integrated with to provide user control of data.

Related tickets: #43750, #43938

Developers

At this stage, privacy enhancements are essentially retrospective, meaning they are applied to existing work. A healthier approach would integrate privacy at an earlier stage. To achieve this, developers would benefit from clearer guidance on privacy on the plugin and theme guidelines level (e.g. how to plan and structure a plugin or theme) as well as on the development level (e.g. how to code a plugin or theme). Guidance would be grounded on a best practice, protecting users and their data, approach first (e.g. the Privacy by Design) principles and a legal compliance approach second; developers will begin to understand what data collection and/or usage is truly necessary for the functioning of a site, plugin or theme (e.g. authentication) and what data usage the user can and should have control over (e.g. sharing location data)

Users

While using a site with active plugins, users should be able to use WordPress core privacy features to manage how their data is used during their experience on a site with full control, choice, and consent over that data usage. This will largely be impacted by the consent and logging work explained in more detail below.

Consent and Logging

A standard way for WordPress core, plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds. This initiative will likely require long-term research (especially since it will be heavily influenced by pending regulations, such as the ePrivacy Directive) and iteration to ensure a positive experience for all while preventing “consent fatigue”.

Some key aspects of this initiative are as follows:

  • Users should be able to edit their consent at any time through easily accessible means (front-end forms, etc.).
  • Administrators should be able to review a user’s consent history and the current status of that consent to help them with compliance inquiries.
  • Developers should be able to easily query by a specific type of consent or a specific user’s consent.
  • One central location for viewing all consent to help provide an all-inclusive view of consent across the site for WordPress core and all plugins/themes.

Existing consent and logging projects should be evaluated and utilized where possible. Creating an open source pattern library of designs for consent and choice while collaborating with other projects and organizations should be considered. Some existing pattern libraries have been developed for IAAP (International Association of Administrative Professionals) and by IF London.

Although this work is independent of any specific regulation or law, it should be done with a mindfulness of the upcoming revision of the EU ePrivacy Regulation (colloquially and somewhat inaccurately known as the “cookie law”), which is anticipated to be finalized sometime in autumn or early winter. This “head start” will allow an effective solution to be deployed well in advance of the eventual compliance deadline.

Consent Capture

Consent capture refers to the wide variety of user-facing means of capturing user’s consent (and letting them change their opt-in or opt-out status at any time). This includes things like form inputs, banners, walls and the like.

Consent Logging

Consent logging refers to creating a means to collect a history of how users have opted in or out of various means of processing their data and making that history (and present state) available to administrators (and plugins).

Thought should be given to how users are prompted for consent, how they change consent, how plugins can query consent, how admins can see a user’s consent status, etc..

Related tickets: #44043, #43797, #44012

Front End User Initiated Requests

In 4.9.6, the ability for an administrator to initiate a data export or data erasure for a user by email address was added. While this provided sites with the tools to be compliant with new laws and regulations, site owners are still left to find a way to accommodate those requests. Adding a way for users to initiate this request on their own would prove a more “out of the box” experience and decrease the burden on site administrators to initiate these requests themselves.

Related tickets: #44013

WP-CLI Support

To encourage more developers to utilize core privacy tools, full WP-CLI support should be added. This would allow larger and more complex data export requests (possibly involving 3rd party services or external systems) to be created through the command line.

Multisite Support

At the time of this document’s publishing, data export and erasure requests are only supported on a per-site basis. Organizations that have multisite or multi-network WordPress installs should be able to perform core privacy tasks across the entirety of their network.

Careful consideration should be given to different types of multisite installs, scalability, and user experience. An all-inclusive solution may not be realistic for WordPress core, but a general foundation of support should be established with the appropriate action and filter hooks that allow developers to meet the needs of different types of multisite setups.

Related tickets: #43738, #43821, #43822