WordCamp Denmark organizer Kåre Mulvad Steffensen and WP Pusher creator Peter Suhm are working on a GDPR for WordPress project that aims to provide an industry standard for getting plugins compliant with EU General Data Protection Regulation (GDPR) legislation. The deadline for compliance is May 28, 2018, approximately 200 days from now. The Danish duo met at WordCamp Europe a few years ago and were inspired to work together on several projects, with GDPR compliance for WordPress sites being the most urgent item on their list.
“We want to create a standard for plugin creators to describe what kind of data they store and how to handle it,” Suhm said. “With a standard like this it will be possible to build tools to make WP sites compliant with GDPR. That basically means things like generating privacy policies, tools to export sensitive data, and tools to delete it completely. GDPR is pretty complex, so there will likely be a lot of tools around this. The first thing we need is a standard. It’s critical especially for EU based companies, and I can tell you that it’s something people discuss in every meetup and WordCamp over here.”
The GDPR for WordPress site includes a summary of website owners’ obligations in regards to collecting data related to EU citizens. It’s not comprehensive but gives an idea of what items the standard will need to cover:
- Tell the user: who you are, why you collect the data, for how long and who receives it.
- Get a clear consent, before collecting any data
- Let users access their data, and take it with them
- Let users delete their data
- Let users know if data breaches occur
Steffensen and Suhm’s first step is surveying WordPress plugin developers to gauge their awareness of the GDPR. They also want to know if developers would be interested in using a free, open source solution, like a simple file with a map of personal and sensitive data stored by their plugins. The GDPR for WordPress team would then use the tool as a foundation to build tools that can take care of compliance by parsing these files.
“When we have the survey data we will continue to work on the standard,” Suhm said. “It will be 100% open source, so everyone can use it to build whatever they see fit afterwards. So far it’s just a lot of ideas and we really want to collect as much input as possible so we can get everyone onboard.”
The team has created a roadmap that that they will update based on feedback from plugin developers. They plan to work on the following:
- Methodology to describe how a plugin collects, stores, and uses personal data
- Methodology file builder for plugin developers to use
- Provide a clear visual compliance indicator on every plugin installed
- Privacy policy text builder based on installed (compliant) plugins
- Provide an administrative overview on each users data being stored, across plugins
- Provide an administrative way to send user data to a specific user upon request
- Provide an administrative way to delete user data on a specific user upon request
- Add site wide Explicit consent checkbox, with detailed yet plain English on what data is stored, how it is used and how long. (This is a replacement for the cookie popup) – possible disablement of submitting actions until consent is given? The request to collect data should happen to every user before any data is collected, that might also mean cookies.
Despite the quickly approaching deadline, solutions aimed at helping WordPress sites to be compliant with the GDPR are virtually non-existent. There are currently only six plugins in the directory with descriptions that mention having been built with GDPR compliance and privacy in mind. Many site owners will be woefully unprepared to comply with the legislation.
A couple of months ago we looked the Wider Gravity Forms Stop Entries plugin, which helps site owners protect the privacy of form submissions by preventing them from being stored in the database. Since many plugins don’t have these options built in, other plugin developers have to extend them to suit their users’ needs. At the moment, there is no standard way of doing this because of the wide variance in how plugins store their data.
This solution the GDPR for WordPress team is proposing is different in that it aims to give plugin authors a standard for including a meta description of the personal and sensitive data that their plugins stores. The GDPR doesn’t prohibit plugins from storing personal identifiable data but it does require website owners to detail what, where, and for what purpose it is stored.
“The problem right now is that it is almost impossible to figure out what information a WordPress plugin stores and where it is stored,” Suhm said. “This will make it possible to build general solutions across plugins to ensure GDPR compliance. An example could be a tool to delete sensitive data from a WordPress site, including the data stored by plugins. That is only possible if plugin authors include some sort of description of their ‘data footprint.’”
The biggest challenge the team has is rallying plugin developers to get on board with following a new standard and updating their plugins to provide a data footprint. This is not an easy task as the burden of compliance falls to the website owners, not individual plugin developers. Even if site owners are motivated to educate themselves, the prospect of figuring out what data is being stored and where can be daunting. If the GDPR for WordPress team can successfully get the plugin developer community on board, they can work together to build a suite of tools that help end users get a broad overview of their sites’ GDPR compliance.
I think this is an important issue that impacts more than EU plug-in developers. It impacts site owners as well so people should get acquainted with the policy. Last I heard the regulation was 360 pages long and not done.
And if I understand correctly, it impacts site owners outside of the EU if they have EU customers. Which means, many of us also need to audit our plug-ins and 3rd party services to see what data they collect. The fines are substantial.
From a presentation I heard, it also impacts things like how we set up forms. For example, you shouldn’t have certain options checked by default (e.g. automatically subscribing them to a newsletter). You have to have the user explicitly check those items as opposed to having them turn them off.