Feature plugin proposal: Privacy Data Request Form

As part of the core-privacy team’s 2019 roadmap, the team has begun a discussion on the possibility of creating a front-end forms feature to handle Privacy Data Requests introduced in WordPress 4.9.6, most likely as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress Slack.

Introducing this feature plugin proposal

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.

Source: Core Privacy Team Roadmap

Creating a privacy front-end form mechanism –first as a feature plugin– presents an opportunity for the project to make a positive impact across privacy areas. It will empower administrators within the ecosystem to better comply with privacy-related requirements, while contributing to a better standard of protecting user privacy across the open web.

Integrated in the Privacy Policy page, this feature would help big websites administrators to automatize privacy requests management (exactly as in WordPress.org related page).

This feature would also help regulation organisms to directly verify the conformity of WordPress powered websites by creating privacy requests and checking the result directly.

Last but not least, using the feature in websites privacy policy pages would eventually made visitors more confident about the website owner as they could request their data by themselves.

Technical scope of the feature plugin

The feature plugin should at least handle the following scope:

  • PHP functions to generate privacy data requests front-end forms
  • PHP filters to handle forms customizations like editing wording and choosing either to use data removal action, data export action, or both
  • Privacy Request Widget
  • Privacy Request Shortcode
  • Privacy Request Gutenberg Block
  • PHP documentation for both functions and filters
  • CSS classes documentation

Introducing the existing base plugin

During previous meetings, the #core-privacy team discussed about an existing plugin reported by @garrett-eclipse and @xkon.

This existing plugin is already managing some parts of the feature:

  • PHP functions to generate front-end Privacy Requests Forms
  • PHP filters to handle forms customizations (like choosing either to show remove request, export request, or both)
  • Privacy Request Widget
  • Privacy Request Shortcode
  • Privacy Request Gutenberg Block

It has 5000+ active installs and the idea is to use this plugin to prepare and test a potential core merge of the Privacy Data Request Form feature in WordPress Core.

As the initial author of the plugin, I already made some changes:

  • The plugin’s SVN repository is open for core privacy team contributions (current contributors: @xkon and @audrasjb).
  • The plugin’s GitHub repository is open for contributions as well.
  • The plugin is not displaying anymore my employer’s logo.

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To change the display name of the plugin from “GDPR Data Request Form” to “Privacy Data Request Form” (though we must keep the actual slug, I guess we could edit the plugin Display Name).
    – Plugin Review team validation needed on that point.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To keep an eye on the feature plugin’s support questions and ratings.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • wording/copywriting
    • accessibility
    • design/theme compliance
    • security
    • coding-standards and documentation
  • To create a Trac ticket to handle a potential future merge proposal – if the feature plugin deserves it.
    Note: I already created a GitHub repo and generated a core diff file to test the feature directly against WordPress trunk (though it doesn’t contains the Gutenberg block nor AJAX validation)