Featuring GDPR tools to help you comply with the regulation, WordPress is one of the few CMS’ out there providing these tools prior to 25th of May.

While the tools are only back-end oriented, for now, the plan is to add more functionality in the coming releases.

This blog will discontinue its focus on the core GDPR tools, and you should head over to make.wordpress.org to read up on how to implement the GDPR hooks and filters in your plugins.

If you are concerned about logging GDPR related requests – which you should be – then stay tuned. We will shift our focus towards the next big hurdle; Logging of any GDPR related activity, that is when a user requests access to data, askes for data to be exported, asks for changes or deletion/anonymization of data.

These changes need to be stored outside of your current WP database and filesystem to allow you to re-run any past activity if you ever need to introduce a backup of your data.

By being able to re-run deletion requests, you can make sure that you stay compliant.¬† – More on this later. For now, let’s celebrate WordPress ūüôā

WordPress 4.9.6 Privacy and Maintenance Release

I’m happy to announce that the team behind GDPR compliance in WordPress core has gotten the first version of GDPR tools into the upcoming version of WordPress.

Download and test please – and if you’re a plugin developer, it’s time to start implementing the exporter into your plugin.

Website admins – you get the tools, but that does NOT mean your site is compliant by default. Since we still haven’t got a unified way to check if a plugin implements the new tools, it’s your job to make sure that any personal data handling plugins you have, does so within the regulatory rules.

Also, you need to manually setup a way for users to contact you. You then manually validate the users identity and then – via admin – send out a validation link to the user in question.

Then, wait for the user to confirm, and then manually click, to do an export that is then sent to the user.

Yes, we’re not 100% automatic about the flow – this is a crucial first step and we should be happy that it’s in place before 25th of May

WordPress 4.9.6 Beta

GDPR tools in WordPress core is well underway, and it’s time for you to start working with them.

@allendav has put together a guide on how you connect your plugin to WP core’s Personal Data Exporter.

The Personal Data Exporter is the function that you need to feed with the personal data information your plugin handles. That way, you help website admins collect personal data from across the plugins installed.

Enough talk, it’s time for action:

https://github.com/allendav/wp-privacy-requests/blob/master/EXPORT.md

It’s great to see how WordPress teams work together and choose to dedicate time to contribute to the common good instead of going their own way.

WooCommerce was some of the first to respond to our cry for help on GDPR for WP, and I’m impressed with the results coming – not only from Woo, but the entire team.

Mike Jolley has put together a great article on how they have tackeled GDPR and the current status of the overall GDPR-Compliance work being done in WordPress core.

Read on: https://woocommerce.wordpress.com/2018/04/10/how-were-tackling-gdpr-in-woocommerce-core/

In case you missed the newsletter, read up on our current status of the GDPR for WordPress project in this blog post

Much has happened since Peter Suhm and I started out on the GDPR for WordPress project.

Our initial idea has morphed from a PHP Object Interface, that could serve as a general rule for any PHP based system, to comply with GDPR, to a WordPress specific solution that, with the help of the Community is now being actively adapted to fit into WordPress Core – hopefully in time for launch prior to May 25th when the General Data Protection Regulation goes into effect.

How awesome is that !! ūüôā

The Process has been exciting – and still is! On a personal level, reading the text of the regulation has made me aware of how we handle data in a more general sense, and I see the ideas behind GDPR to be much more widespread than just that of the current focus on EU citizens.

I’m happy that we have my colleague Jesper V. Nielsen from¬†Peytz&Co¬†working on the code going into WP core, and I’m happy that our idea has taken such a turn, that it now fits into WordPress instead of living in a plugin.

The GDPR tools we’re providing requires a widespread adoption, and having this in a plugin was not the way to ensure that.

Status
Every Wednesday at 17:00 CET there is a meeting in the official WordPress.Slack.com channel called: #GDPR-Compliance

There are a bunch of people, a few of the noteworthy mentioned in the slide deck below, working actively on bringing the hooks and filters into WP core, so that YOU as a plugin developer, can start providing info on where your plugins store personal data. Doing so will make WP core able to fetch this data and output it Рin a first version, on a backend screen designed to help WordPress admins find, send and anonymize data on request from a
user of their services.

Will we make it in time? – I hope so. With the current WP 4.9, and the next major release probably being that of Gutenberg, we find ourselves with two major improvements with each their massive impact on the lives of WordPress admins competing for your attention. My personal hope is that all will be ready for May 25th ūüėČ

Watch the Slide deck presentation on the current status here:
https://www.slideshare.net/dejliglama/gdpr-for-wp-status

The Road Ahead
The roadmap is evolving even as we speak, and although the Implementation isn’t released into WP core yet, it’s vital that Plugin developers that work with code, used for storing or handling of Personal Data, should start implementing the hooks and filters of the solution.

Only with your implementation of the GDPR tools within Plugins, will we as a community be able to deliver the administrative solutions that are required for website owners to comply with the user-centric parts of the regulation

  • yes, you guessed it, The right to be forgotten, Data portability and Policy texts among other things.Call to action

So, what’s next for you? Go to our #GDPR-Compliance slack channel, and get involved.

Go read the open GDPR Trac tickets: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr

And please do reach out and ask any questions you’d like!

Our open source GDPR Interface has finally seen its first release

If you can’t wait to get your hands on it, go check it out on our GitHub account where the magic happens.¬†https://github.com/GDPRWP/standard

 

114 days to go, and still lots to do

It’s early days still, but we managed to settle on two main functions on this first release, and a couple of helper functions.

The main functions

Main functions are the foundation for the functionality, website owners will need to comply with GDPR when a user of a website want to request, obtain or transfer data.

The two main functions are read and anonymize.

read_userdata( $user_email);

The General Data Protection Regulation states that users have the right to request, obtain and transfer data. That means we need to find and list any Personal Identifiable Information that our collected WordPress installation holds – across plugins!

read_userdata requires an e-mail. We know this might not be ideal in the long run, but e-mails are unique in standard WordPress user behaviour, and something you will get from a user, requesting the data you hold on them – A userID isn’t usually something a user has knowledge about, and thus we need to go with data the user can actually provide.

It’s up to you – as a plugin developer, to return any Personal Identifiable Information (PII) that your plugin stores on the provided e-mail. The format of the returned data should be in the form of an array. We will offer code examples shortly!

anonymize_userdata( $user_email);

Although you do also find a delete_userdata(); function, we believe that the correct term should be “anonymize”.

With this function, you directly tie into the GDPR compliance of “The Right To Be Forgotten” (TRTBF).

We can’t view deleting of data only from the point of view, of one single plugin, but need to consider the ramifications of a deletion across multiple plugins, and in WP core. Our belief is that some plugins might be able to delete all PII when asked to anonymize, and they should do so if it does not affect the functionality of the plugin.

For others, deleting data is not an option, since statistics or other data can be¬†tied into the PII data. Example: If my website keeps statistics on how many male users we have, living in northern Europe. I can’t simply delete the fields where I store the PII male and location. I would need to anonymize it so that it isn’t tied to any specific e-mail (or other PII).

The helper functions

To allow GDPR plugins to use the information you provide by implementing the GDPR Interface into your plugin, we need to set some metadata on that PII. For this, version 1.0.0 of the GDPR interface has two helper functions.

get_gdpr_version();

We know that we won’t get everything right on the first try, and for that, you shouldn’t be punished for implementing an early version of the interface, to start complying with the “simplest” elements of the regulation. Therefore we need a version number, to know which elements you DO comply with. Plugins that are yet to be created by the community at large, will be able to use the version number, to know which functions you have implemented.

policy();

Another GDPR compliance issue is that you need to provide a clear text description of how the data is used. We figure you would need some place to detail this in a plain and easily understandable text. As it’s you, as a plugin developer who knows why for how long and for what purpose you collect this data, this is where you can detail this for each of the PII you collect.
Check out the Interface on GitHub
Thank you so much for supporting this project. I’d be happy to hook up on WordPress.slack.com to discuss any issues or ideas you might have.

A crazy first couple of weeks

We’re stoked with the level of positive response and id√©as from the development community. The GDPR regulation to many is something that comes from a foreign authority, but the core principles of the legislation have pointed in a direction the whole of the web community know it needs to go – no matter the name of the regulation.

The WPTavern article got a great deal of exposure and helped us get in touch with community people sitting in various interesting places. Much work has already gone into thoughts, legal texts and actual solutions in regards to GDPR compliance. Since GDPR can have a huge impact on the likes of Jetpack, Redux, and various form-builder plugins, it’s only natural that the focus for those companies is inward at the moment.

Our talks with Paul Sieminski from Automattic, and Dovy Paukstys from the Redux options framework have reassured us that we still do have a need for a GDPR structure which can help the community establish a basis for handling GDPR compliance.

We are aware that this is not a walk in the park, and legislation can have a massive impact on website owners, and developers alike. Our proposed interface is not one that you would be able to hold accountable, but to some extent, you might be able to build accountable systems on top of it.

 

Community feedback

40 plugin authors have answered our survey. 72,5% of which have a rough idea about the GDPR implications, and luckily only 7.5% don’t know what EU GDPR is ūüėČ

That is contrasted by a whopping 43,9% answering that they do not currently have a plan against 4,9% that do have one.

(24,4% have plugins not handling user information in any way)

So you could say there is a need for some kind of solution.

With 90% answering, Yes, or I would consider implementing a GDPR “file” type solution into their plugins, I take that as thumbs up from the community in our proposed direction.

Where we’re at with the code

With the input we’ve gotten, we have been able to further develop our idea into the current state – one we are now open sourcing on GitHub (no real code just yet).

Check out the Github repo

Our proposal is an Object interface which you can choose to implement in your plugin code (or theme). Doing so will require you to actively develop a set of methods that work specifically with your plugin code.

The output of those interface functions is first and foremost a unified way for us as a community, to identify information on personal data, no matter the format of your plugin.

The nature of such an interface, puts some responsibility in the hands of the developer, to identify any place, personal data is stored. What kind of data it is, and for what purpose as well as how it should be handled upon deletion.

The Interface approach will allow a community-wide adoption, without setting limitations on how plugin developers choose to work with their data – something we obviously can’t control.

The specific functions of the interface will directly correspond to the requirements in the GDPR.
That means we will – in time – have functions that will give you the ability to handle: requests to access userdata, the right to be forgotten, report data breaches, delete and anonymise data, a plain language description on how your plugin complies with GDPR, and a bunch of other very hands-on things you need to be able to do with the data your website collect.

Some of those functions will be required, others depend on the nature of the data you are handling.

With a set of ever-growing functions that tie into specifics of the GDPR, we will be able to allow the whole of the community to create GDPR-feature plugins that can handle the functions required by website owners(administrators) as well as the front-facing functions of allowing visitors to ask for information, delete or take their data with them.

 

Collaboration, the future, and funding

Our initial interface proposal (no real code) with the first couple of functions are now available on Github https://github.com/GDPRWP/standard.

Please remember that this is in no way ready for your dev.  environments, but please do send us any feedback you can come up with.

It’s opensource since we believe that the WP Community will be the best place in the world to dynamically build this interface.

At the moment we’re 2 guys leading up this initiative, and although we are an eager bunch, we do realize that this requires much more work, and a bit of funding for us to go the full approx. 200 days.

We appreciate the help offered by Automattic and Redux.

If you wish to help out, please do contact me: core@dejliglama.dk

 

With a standardized GDPR methodology, we see a future where it’s possible for multiple plugin and service providers¬†to target the specifics of the regulation, making it easier for website administrators accommodate¬†the users’ needs.

Read More