This roadmap (v2) contains plans for the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-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 An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and/or Github GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. 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 A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. will be closed with ‘feature-plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’ tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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 Is an acronym for Globally Recognized Avatar. It is the avatar system managed by WordPress.com, and used within the WordPress software. https://gravatar.com/. 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 WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/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 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 Support (Feature Plugin)
Data export and erasure requests are currently only supported on a per-site basis. Organizations which have multisite or multi-network (versus site, blog) 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 Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. that allow developers to meet the needs of different types of multisite setups.
Related tickets: #43738, #43821, #43822
Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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 Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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.
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 The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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, #48486, #49272
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)
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.
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 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 Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. 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 Launching code from a local development environment to the production web server, so that it's available to visitors. 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
Feature Plugin:
Plugin Page – https://wordpress.org/plugins/wp-consent-api/
Github Page – https://github.com/rlankhorst/wp-consent-level-api
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
Feature Plugin:
Make Post – https://make.wordpress.org/core/2019/09/04/feature-plugin-proposal-privacy-data-request-form/
Plugin Page – https://wordpress.org/plugins/gdpr-data-request-form/
GitHub Repo – https://github.com/audrasjb/gdpr-data-request-form/blob/master/README.MD
Core Diff File – https://github.com/audrasjb/wp-core-privacy-data-request-form/blob/master/privacy-request-form.1.diff