Wider Gravity Forms Stop Entries is a new plugin that helps website owners protect the privacy of form submissions by preventing entries from being stored in the database. The plugin was created by UK-based web developer Jonny Allbut for internal use at Wider, a company he set up for handling WordPress clients’ needs.
One aspect of complying with the EU’s General Data Protection Regulation (GDPR) is ensuring that contact forms do not store any personally identifiable data on the server. The regulation becomes enforceable in May 2018 and sites that serve EU citizens are preparing for the deadline with audits and changes to how they handle privacy.
Gravity Forms doesn’t offer a built-in option to stop entries from being stored on the server but GF co-founder Carl Hancock says there are a variety of ways to accomplish this.
“If all you want to do is simply email the contents of the form and not store the data in the database as part of the route you’d like to take for GDPR compliance, this plugin would be one method of doing so,” Hancock said. He also referenced Gravity Wiz’s commercial Disable Entry Creation plugin. Developers can also delete entry data after submission via a hook.
“However, the GDPR doesn’t preclude storing form entries in a database and is entirely dependent on the type of data you are storing and the other safeguards and functionality you have put in place,” Hancock said. “It’s a complex issue and I’m not entirely sure the EU fully understands the burden and implications that may come with it.”
Ultimately, the requirement of compliance falls upon website administrators who are the ones collecting the data. It is their responsibility to select tools that will protect their users’ privacy.
“While it won’t provide GDPR compliance on its own, Jonny’s extension is a much-needed step in the right direction,” digital law specialist Heather Burns said. Burns consults with companies that need assistance in getting their sites GDPR compliant. “GDPR requires adherence to the principles of privacy by design and part of that is data minimization and deletion.”
WordPress has dozens of popular contact form plugins, both free and commercial. Many of them store entries in the database in case the recipient’s email has problems, preventing the communication from becoming lost. Site administrators who are concerned about GDPR compliance will want to examine the solution they have selected for forms. Burns advised that contact form plugins need to do the following three things:
- Ensure that personal and sensitive personal data from form entries is not stored in the database;
- Provide configuration options to allow contact form entries to be automatically deleted after a certain period of time;
- Ensure that all contact form data is deleted when the plugin is deactivated or deleted.
“Unfortunately the direction of travel has been the exact opposite: contact form entries tend to be stored in perpetuity on the database regardless of content or necessity,” Burns said. “Contact form plugins with options to automatically delete form submissions after a certain period of time are rare. I’ve even seen contact form extensions which duplicate entries to a separate table, which, all things considered, is madness. We need to be developing towards data minimization and deletion, not retention and duplication.”
Last month JJ Jay published an analysis of how and where popular WordPress contact forms plugins store data. This is a useful reference for site administrators who are not sure how their chosen solution handles data collection and storage. She suggested a few questions for users to ask when examining contact forms:
- Can the option to store data be turned on and off?
- At what granularity?
- Can the data be deleted when the plugin is deleted?
- What personally identifiable data, other than the data from each form, is stored? (i.e. a user’s IP address)
- Is it possible to delete the submissions on an ad-hoc or scheduled basis?
If you’re not sure what could be leftover in your database from other plugins, Jay has also created a “What’s in my database?” plugin that administrators can install and access under the Tools menu. It is read-only and lists every table and its columns, so users can see if there are any surprises.
British Pregnancy Advice Service (BPAS) Hack Highlights the Danger of Storing Contact Form Entries in the Database
In educating website owners about the dangers of storing sensitive personal data, Heather Burns often cites the 2012 British Pregnancy Advice Service (BPAS) hack as one of the worst examples of the consequences of storing contact form entries in databases. The hacker, who was later jailed, stole thousands of records from the charity, which was running on an unknown outdated CMS with weak passwords. The site had not undergone a privacy impact assessment on its personal data collection and storage methods.
“One of the services BPAS offers is access to abortions,” Burns said. “Many of their service users come over from Ireland, where abortion is banned under nearly all circumstances. The site had a contact form where women could enquire about abortions. BPAS thought that messages were merely passing through the site; no one within the organization had any clue that a copy of each contact form submission was stored on the database. Somewhat inevitably, the site was easily hacked by an anti-abortion activist who downloaded the database. He found himself in possession over 5,000 contact form submissions going back over five years containing women’s names, email addresses, phone numbers, and the fact that they were enquiring about abortions. He then announced his intention to publish the womens’ data on an anti-abortion forum.”
The hacker was caught and arrested before he had the opportunity to publish the list. He received 32 months of jail time and BPAS was fined £200k for the data protection breaches.
“As well as criticizing the charity for their technical failures, the regulator called attention to the fact that no one on the staff had thought to ask the proper questions about the tools they were using; they were also angry that the site had a legalistic privacy policy which was clearly not worth the pixels it was printed on,” Burns said. “All of these failures were deemed inadmissible and inexcusable by the data protection regulator. It is no exaggeration to say that women could have been killed because of a contact form.”
Auditing contact forms is just one piece of the puzzle for those working towards GDPR compliance. Burns recommends that site administrators conduct a privacy impact assessment of personal and sensitive data that is submitted through forms. Privacy notices should also be clear about how this data is handled and how long it is retained before it is deleted.
The GDPR was written to be extraterritorial and states that the regulations apply to any site or service that has European users. These sites are expected to protect EU users’ data according to European regulations. Many American company owners are not yet convinced that this is enforceable outside of EU borders and have not invested in getting their online entities to be compliant.
“GDPR provides a very useful framework for user protection, which is now more important than ever,” Burns said. “I’m encouraging Americans to work to GDPR because it’s a constructive accountable framework that’s a hell of a lot better than nothing.”
Wider Gravity Forms Stop Entries is currently the only plugin in the official WordPress directory that addresses GDPR concerns for a specific contact form plugin. Others may become available as the May 2018 deadline approaches. Jonny Allbut warns users in the FAQ to test the plugin with third-party GF extensions before adding it to a live site, as some extensions may rely on referencing data entries stored in form submissions.
I asked Carl Hancock if Gravity Forms might make storing form entries in the database an optional feature and he confirmed they are considering it.
“Yes, this is certainly possible,” Hancock said. “We try to avoid conflicts with available 3rd party add-ons for Gravity Forms to encourage their development,” Hancock said. “But unfortunately it is not always avoidable. It is a feature that has been requested numerous times in the past and I suspect with the GDPR it will be a feature that will be requested even more going forward.”
Assuming content is stored in the database for only a limited period of time, the advice to delete on deactivation is madness, because people frequently deactivate plugin when trying to diagnose a problem. In that case, the person trying to figure out why a page would not format correctly, for example, would cause the site owner to loose all their recent submissions!