This roadmap (v2) contains plans for the core-privacy component for 2019.  The roadmap is a work in progress and will be revised as changes are needed.

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

The core-privacy component will aspire to be promoted to a full component from its current position as a core sub-component, reflecting its expanded work and scope. Component maintainers of the core-privacy group are also participating in the new cross-CMS privacy working group with members of the Drupal, Joomla, Umbraco, and Typo3 privacy teams, and will benefit from the projects and workflows that the group is developing together.

Privacy areas of focus, working outside any specific legal obligation, will include (but not be limited to) this range of common international privacy conventions and standards:

  • Personal data minimization: collect only the data you need and no more
  • Personal data integrity: ensure that the data is true and up to date
  • Purpose minimization: only use the data for the purpose for which it was collected
  • Lifecycle limitation: do not keep the data longer than is needed or share with others for purposes beyond the original intention
  • Human and technical security measures: take adequate measures to protect the data from misuse and its subjects from harm
  • Transparency and notice: be clear about what data is captured, why it is captured, and what is done with it
  • User participation and rights: give people rights to access, control, and delete their data
  • Accountability, enforcement, and redress: Provide a means to correct errors and right wrongs
  • Choice, control, and consent: Give people choices and options over the use of their data at any time
  • Special categories of sensitive personal data: taking extra care with data which could result in personal risks to the subjects
  • Legal compliance: work proactively and in cooperation with privacy law obligations

The team works to a Privacy by Design (PbD) approach, which seeks to identify and mitigate privacy issues before they happen.

Bug scrubs are 1600 UTC on Mondays, and office hours are 1900 UTC on Wednesdays.

Structure of work

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.

All current open privacy tickets can be viewed here.

For each of the areas mentioned below, a link to its development area is provided in Trac and/or Github. Only milestone tickets that are ready to commit, or have a level of effort remaining that is realistic based on the next release’s proposed timeline, are listed.

Feature requests made via Trac for the Privacy component that should be vetted initially as a feature plugin will be closed with ‘feature-plugin’ tag and moved to a dedicated Github project under the Core Privacy organization.

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 and further the adoption of core tool in plugins and themes.

General Improvements (features already in core)

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

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: #16020, #44067, #14682

Embed Privacy Controls (Feature Plugin)

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.

Other embed issues of concern include CDNs, fonts, and emoji.

Related tickets: #43713, #44001

WP-CLI Support (Feature Plugin)

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.

Tickets to be created.

Multisite Support (Feature Plugin)

Data export and erasure requests are currently only supported on a per-site basis. Organizations which 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

Gutenberg Blocks (Feature Plugin) (related to Front end user initiated Requests)

To integrate the Privacy components more intuitively with WordPress 5.0 (Gutenberg) the ability to add content from the Privacy Policy Guide as a block would be very helpful. The Privacy Policy Guide block would inject the suggested content.

Other blocks could include data request and data removal. (Front end user initiated requests)

Related tickets: #44013

Upcoming privacy compliance requirements (from mid-year onwards)

The two pieces of privacy legislation which will create the most obligations for WordPress site administrators in 2019 are the US California Consumer Privacy Act (CCPA) and the EU ePrivacy Directive overhaul. The shape of any potential future US Federal-level privacy law will also become clear as the year progresses.

The core-privacy team will monitor each law carefully, via regular updates and research from members participating in the cross-CMS privacy working group initiative. Once the specific requirements are announced by each respective government, we will hold a discussion of what functionality may need to be created to allow site administrators to meet their requirements well ahead of compliance deadlines.

Related tickets: #43713, #44001

Plugin & Theme Privacy

Plugins and themes are vital parts of the WordPress experience. Administrators should be able to easily understand the way a plugin or theme collects and processes users’ personal data. Plugin and theme developers 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.


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. This 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


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)

Several plugin developers have expressed interest in learning what improvements can be made to their plugins’ privacy standards, both front and back end. This indicates an interest in privacy audits as a service the privacy team could offer.

The cross-CMS privacy working group is developing a template workflow which can be used to evaluate plugins for healthy privacy practice from both design and data perspectives. The first iteration is here. The core-privacy team will adapt this template to reflect WordPress plugin and coding standards.

To make the privacy review work accessible to WordPress developers, tags for “needs-privacy-review” and “has-privacy-review” have already been added to the Trac system.


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 long-term consent and logging work explained in more detail below.

Consent and Logging (Feature Plugin)

Consent capture refers to creating a means for users to express their consent to data capture and usage, and to change their opt-in or opt-out status at any time, through easily accessible means such as front-end user settings or account information areas.

Consent logging refers to creating a means for administrators to collect a history of how users have opted in or out of various means of processing their data across core and plugins, to view the current status of that consent, and to make that history (and present state) available to users.

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 revamp, as well as user testing to ensure a positive experience for all while preventing “consent fatigue” or dark patterns. Existing consent and logging projects, such as Joomla’s consent system, will be studied and emulated where possible, for both functionality as well as potential applicability as a plugin rather than a core feature.

Work on consent and logging is a considerable opportunity, and a challenge, for frontend and UX design. Thought should be given to how users are prompted for consent, how and where they change consent, and how this experience could be consistent across WordPress sites regardless of plugins or themes. 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 IAPP (International Association of Privacy Professionals) and by IF London, working with Open Rights Group (whom Automattic sponsors).

Although this work is independent of any specific regulation or law, it should be done with mindfulness of the new privacy laws coming into play later this year. Making a “head start” will allow an effective solution to be deployed well in advance of the eventual compliance deadline.

A technical challenge lies in logging data in the same database as the data that is being “watched,” e.g. what if the database is restored? Then logs are restored as well.

Related tickets:
#44043, #43797, #44012

Front End User Initiated Requests (Feature Plugin)

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