Instalment number 4 of our Q&A with Pixel & Tonic focusses on Craft & everyone's favourite subject - GDPR. We discuss the impact GDPR has on Craft CMS, Craft Commerce, and developers who use it.
How do you feel about GDPR?
Leslie: In theory we like the idea behind it. We’re big advocates of privacy and protection of data, good security practices.
As most of you well know, it’s not a technical solution at all - so the GDPR specifications have no technical mandates that are standards to follow.
There will probably be some very minor updates to Craft in terms of getting user consent at installation and for technical support. That will be the first round of things.
We haven’t announced it but for anyone that asks we have a DPA available.
We’re working with a specialist and tried to have everything ready but the complication is the plugin store. So getting the T&Cs right for the plugin store because it’s not just us but we are sending personal data from a purchase to over 100 different vendors in many different countries.
So there’s a whole bunch of things to think through.
We’re looking at things like the EU Privacy Shield laws and getting certified. And [our specialist’s] advice is just to take it really slow because compliance, especially for small businesses, is about pointing yourself in the right direction.
What agencies need from us is an assurance that we’re treating your clients data appropriately when you contact us for support.
For example, in the Craft help widget you can send us your client database - the whole thing, right there! Maybe that’s got sensitive information in it, maybe it doesn’t - we have no way of knowing in advance - so a lot of those things are where do we even capture consent for that?
We can get consent at the Craft install but then what if the site has multiple admins? Ironically, we would have to lower our privacy standards to get inline with GDPR stuff there so want to make sure that our policy is separate from anything that you need to do for installations so the data is safe there.
In the short term the DPA solves that, which you can do automatically if you go to craftcms.com/dpa it’s all live and will get us an agreement so that you can send us information.
Any features to Craft itself we’re taking them slowly as any other feature request. Sam and I have talked about ways to do personal data exports to help solve some things but we don’t know what those tools will need to be in a standardised fashion that would be useful to a large installation base. It’s very easy to know what to do for a specific site but hard to generalise those into a tool set that would make sense versus what’s already available if there’s a developer involved.
But yeah, we’re for [GDPR] and are definitely heading in that direction.
In the blog post about GDPR you were explicit about existing sites not having a technical solution, does this mean that there could be one for new sites? Will you be working with developers in the community to roll out some form of first party GDPR checking feature?
Leslie: We don’t have anything specific that we’re working on. We’ve talked about it and would imagine that at some point it would make sense but our problem here is that we’re not working with any European end clients directly. So we don’t see the direct requests.
It’s really about people submitting GDPR specific feature requests, walking us through them, and figuring out what we can do at Craft’s core level to help support things like that.
You should submit feature requests, tag them as GDPR, walk us through how they would work, how we should think about these things, and the criticalness of it at scale versus the individual site needs.
What are the most common questions that you’ve been asked about GDPR?
Leslie: The 3 most common questions we got in order are…
“Do we have a DPA agreement?”, and everyone that asks us directly about GDPR asks us for that.
The second one is, “What are Craft’s default Cookies?” and we have an article on that.
The short version of that is we don’t collect any GDPR personal information and any default cookies, and that includes the IP address.
So there’s nothing that Craft does by default that collects any personal data in terms of its default installation since there’s no front end stuff that we install and the control panel is all session based and automatised data that does not collect someone's name or even email address; it uses username and password.
The next question has to do with personal data exports and how does someone know if a plugin phones home?
I think that is something that we will have to take a look at in terms of can plugin vendors self identify that their plugin does phone home or can we provide a short checklist to plugin vendors that is they meet this checklist then we can label their plugin as ‘GDPR Friendly’ in the store as a starting point.
So much of that is determined by the implementation and for us as a vendor it’s difficult to know what our responsibility is.
What is your understanding of GDPR when it comes to commerce, such as: if a customer asks for their data to be deleted and then later requests a refund or tries to return products to change them for a different size. If the data was removed or obfuscated is this something to be handled by T&Cs at the point of deletion or do they still have a right to returns and refunds after their data is removed?
Brandon: Yeah, so that’s a good technical thing and the simple answer needs to be that your refund policy is going to need to be adjusted to include a permission to say that if you’ve requested to be deleted then you’re also opting out of the option to get refunded because we won’t have any information about your order anymore.
Leslie: This is a good example of where your client needs to talk with a Solicitor about this because the right to have your data deleted actually has a big * next to it where the client can have a legitimate business interest in keeping the data. For us for example, in the terms and conditions, we will honour your request to delete all of your Craft ID data until you transfer the license.
The moment you transfer the license, we and other third-parties have a legitimate business interest in the personal data that you share with us to run a legal audit against the chain of ownership on that business license.
Once you make that transfer we cannot delete your data from that and a third-party will always have access to it. You transfer your license to the client and that client eventually transfers it again, every time that license is transferred, the name and email of the original purchaser will always be available because we need that to show legal transfer of the license between parties. It’s unique to us an our implementation, and that’s less a technical thing that we have to figure out and more of a, “oh, we need to have an attorney that understands GDPR, write up these T&Cs, and make sure we’re getting the proper consent to those T&Cs at the time of purchase or at the time of transfer.”
It would be the same thing for Commerce. The specifics of how that would work would depend on the type of commerce your client is doing and the T&Cs on that site. That’s an area where it would make sense that, since Commerce is capturing some of that for the transaction, that it would be good to have some sort of tool for an Admin on the site to be able to easily export that data, or delete that data, or make it available.
Are there any plans to add some form of encryption to the database (eg. an encrypted fieldtype), or certain database fields for data at rest (or in dump files)? What are other platforms doing around potential for personal data in the database? Is this level of encryption even feasible?
Brandon: There’s no specific plans for any of that.
People have requested that we store things in an encrypted way and there’s not really a good technical way to do this. You want to continue using the database for the things that the databases are good for, so we’re kind of dumbfounded with the encryption stuff to be honest; how we would go about that, what the benefit would be, and if you’re going to encrypt things the key for the encryption need to live on the same server that’s connected to the database so if someone is hacking in then they’re going to have access to both of those things so we’re not really sure what the security benefit is either.
But it has been brought up before.
Leslie: If it’s an EU IP to fork that data into a separate user database, so even if it wasn’t encrypted thar customer information could be siloed - the only CMSs we know are doing that are at the enterprise level and that type of feature is a legitimate request but it comes back to, we have a $300 product. And because there’s not a technical spec to map against, if we did something like that it would probably not be a core feature and it probably would be expensive to make clients really think about whether there’s a legitimate need on this or not.
What is the best way to get in touch with you if we have more questions?
Leslie: firstname.lastname@example.org Especially on the GDPR stuff - just let us know what is going to be helpful as you all get more and more requests from clients please do let us know.
Be sure to check out the other instalments in this series to learn more too:
- Ep 1: The Launch of Craft 3
- Ep 2: Craft Roadmap & Competitors
- Ep 3: Craft Plugins & Support
- Ep 4: Craft & GDPR (this one)
- Ep 5: Craft Commerce 2
If you have any questions about GDPR, Craft CMS, or the web in general, please get in touch email@example.com
Or feel free to come along to the next Craft CMS Manchester Meetup that we organise to hear what's new and meet some of the Craft community.