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