Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EDD is not GDPR-compliant #6216

Closed
Shelob9 opened this issue Nov 29, 2017 · 71 comments
Closed

EDD is not GDPR-compliant #6216

Shelob9 opened this issue Nov 29, 2017 · 71 comments

Comments

@Shelob9
Copy link
Contributor

Shelob9 commented Nov 29, 2017

I'm concerned about getting our site to be GDPR-compliant by May. Is there a timeline for GPDR compliance tools in EDD?

@pippinsplugins
Copy link
Contributor

pippinsplugins commented Nov 29, 2017

@pippinsplugins
Copy link
Contributor

@Shelob9 this is high on my todo list to work on soon so we'll likely have updates soon.

@Shelob9
Copy link
Contributor Author

Shelob9 commented Nov 30, 2017

@pippinsplugins There is time. I just started working on a plan for Caldera Forms. I wanted to make sure that EDD was working in it too as that's the other bug collector of data on our site besides analytics companies.

@arraypress
Copy link
Contributor

@Shelob9, what is required to make EDD GPDR-compliant?

@scottbuscemi
Copy link

One part of GDPR is the ability for customers to delete their own data.

If this is to become a feature of EDD, I would hope that the actual transaction data wouldn't be deleted completely so reporting isn't goofed up. Perhaps a transaction would simply be attributed to an 'anonymous' customer?

@arraypress
Copy link
Contributor

arraypress commented Dec 28, 2017 via email

@mindctrl
Copy link
Contributor

WooCommerce has some good info here: https://woocommerce.com/2017/12/gdpr-compliance-woocommerce/

@scottbuscemi
Copy link

scottbuscemi commented Dec 28, 2017 via email

@cklosowski
Copy link
Contributor

This should probably be something maintained within EDD itself, I think a plugin would require many people to miss compliance. While it is a requirement for compliance, I'm curious if this would be something that all sites could benefit from.

We could include it (which would then easily allow extensions to remove their data via filters, etc), and allow store owners to enable the feature. Thoughts here @pippinsplugins on where it should live?

@pippinsplugins
Copy link
Contributor

I am not entirely decided on this but I think I would prefer that this live within an add-on, actually.

I view GDPR the same way I view VAT, which we do not fully support in core.

If we add full support for GDPR then we should likewise add full support for VAT and other country / region specific laws (thinking of Germany here). When do we determine when and when not to support non-global regulations?

I suppose my main hesitation in adding GDPR specific features is "when does it stop?" conundrum?

At this time I'd like to propose that compliance features be built through a free add-on that we (EDD) put on an "officially approved" recommendation list. This would include creation of FAQs for it on our main documentation portal.

@cklosowski
Copy link
Contributor

I think, with the reasoning above, I agree with @pippinsplugins actually. We would want to be able to work with whoever builds this (if it's not in-house) to be sure it works with all extensions that connect with customer data, so that we do not end up in a non-compliant state due to some extension data not being removed.

@mindctrl
Copy link
Contributor

WP core has a GDPR initiative: https://make.wordpress.org/core/tag/gdpr-compliance/

@Basilakis
Copy link

@pippinsplugins @cklosowski Any update here?
The dates are really close right now :-)

@pippinsplugins
Copy link
Contributor

@Basilakis No. We are closely watching what WordPress itself decides to do (see link above) and we'll then follow suit.

@cklosowski
Copy link
Contributor

cklosowski commented Feb 27, 2018

Right now I'd say we need to see what 'tools' the core team makes available to Plugin developers. There is a lot of talk around a couple solutions:

  1. Creating a way to register certain data as private
  2. A Request log, for site owners to work through.

I think one of the important things that EDD will have to monitor is compliance with other eCommerce data laws like VATMOS which requires keeping customer data for a timeframe, however, if that user requests to have their data anonymized/removed, what implications does that have for the store owner to remain compliant from an accounting/tax perspective?

Sounds like the Core team has some ideas moving forward on how to build out some of these 'audit' tools, and if possible I'd prefer that we simply hook into those, instead of building a whole new UI for it.

I'd for one think that we need to keep transactional data in place. If a user decides to request their data be scrubbed, I feel like we need to keep the payment record mostly in tact however some of the data is important for tax reporting for the business owner (like the billing address) , we could simply scrub the customer data to be anonymous, while still unique.

https://make.wordpress.org/core/2018/02/19/proposed-roadmap-tools-for-gdpr-compliance/

@RavanH
Copy link

RavanH commented Mar 13, 2018

I think one of the important things that EDD will have to monitor is compliance with other eCommerce data laws like VATMOS which requires keeping customer data for a timeframe, however, if that user requests to have their data anonymized/removed, what implications does that have for the store owner to remain compliant from an accounting/tax perspective?

The new GDPR law does not trump other EU laws like VATMOS. This means that even though personal data may be scrubbed, the transaction itself including billing address (or at least country?) must indeed remain in the database...

@cklosowski
Copy link
Contributor

Thanks @RavanH! Appreciate that feedback. Do you have a reference for that? Just wanting something we can solidly share in our docs later if that comes into question.

@cklosowski cklosowski changed the title EDD is not GPDR-compliant EDD is not GDPR-compliant Mar 13, 2018
@cklosowski
Copy link
Contributor

Just updated the title of this, it was GPDR when in fact it's supposed to be GDPR

@katmoody
Copy link

Very interested in how this is progressing, as we use EDD with our BackUpWordPress plugin for Human Made and are working toward GDPR compliance overall. I was trying to pinpoint specific issues or things we would need to track for EDD to be compliant. Has work begun on the addon yet?

At this point, specifics already noted above include:

  • ability for customers to delete their own data
  • (for the site owner) knowledge of where the information itself is stored and server/database locations

@katmoody
Copy link

Has anyone else put together a full use of all EDD data that is collected for Audit purposes?

@cklosowski
Copy link
Contributor

@katmoody We're looking into getting a documentation source available for what EDD stores. We're still awaiting some decisions from WP Core to see if they are going to offer us as plugin developers some tools for this, or if we're all going to have to roll this ourselves. I'll put something preliminary together early next week from the EDD side of things.

@katmoody
Copy link

katmoody commented Mar 23, 2018

Thank you @cklosowski - We're going through a full review of all our sites and an audit, and I needed to have all the personal data listed for that. As I complete the included EDD info, I will add or link to that list here for you guys, maybe it can be useful for others who are auditing their data as well.

It does look like WP Core is considering some hooks/filters that plugin developers can use but I've not gone through the Trac to see what has been done or planned specifically ;-)

So far, our audit has revealed the following personal data via EDD, though I'm still looking for anything that will in turn identify a customer or could be combined with other data to identify a customer. I'm not including data used for other plugins though some extension info is included by default (license key and transaction id is mapped to the payment processor for example).

  • Full Name
  • User ID
  • Customer Email(s)
  • Payment ID
  • Billing Address
  • License Key
  • Site Url (license activated)
  • IP Address (upon sale)
  • Transaction ID (after sale)
  • 'Send Product Updates' Update Emails
  • Product Receipt (by email automatically, by PDF as requested)

The key factor in this audit is to determine what information we actually have, whether we need it and if so, for what legal purpose. As a reminder:

Lawful basis for processing

  1. Consent
  2. Necessary to perform contract
  3. Necessary to comply with law
  4. Necessary to protect vital interests of data subject
  5. Necessary in the public interest
  6. Necessary for our legitimate interests

From there, we have a spreadsheet to keep all the other information for each data type, like more specific info on why it's needed, who has access, what type of protection it has, etc.

Let me know if I've forgotten something specific!

@cklosowski
Copy link
Contributor

@katmoody Some of this data, while unique is not identifiable to a user though. That's the major thing we've got to determine. We cannot, for instance, just remove a transaction ID from a gateway or a billing address (or some subsection of it) due to VATMOS, as that would possibly pull a site owner out of compliance for those taxation laws.

This is where it starts getting very conflicted/complex. Some of this data, I believe, has to be in tact (possibly made anonymous?) in order for stores to not break the law as well. Because of some of these things, a customer ID would have to remain (to an anonymous customer) so taxation and what not could be reported correctly if audited by the revenue enforcement.

I've started our internal doc for our team to review and start auditing. Once we have more we'll get something up publicly so we can move forward.

@JeroenSormani
Copy link
Contributor

I currently got no resource to back any of the following up, but isn't the removal of data based on the 'right to be forgotten'?

If thats the case, wouldn't it be only for public data, allowing for orders to remain in tact as private data?

@cklosowski
Copy link
Contributor

@JeroenSormani From what I can read on the official documentation page (https://gdpr-info.eu/), its' not just about 'public data' but about being able to 'profile' a person based off the data collected. That means while we may have to keep the payment history in tact including transaction IDs, items purchased, some billing address information for taxes, we can likely remove non-necessary data like the name, email address etc and make them anonymous as in while I can build a profile, I cannot tie that profile to a given individual because I now know nothing about who that person is, just that they are a generic 'record' with no means of contact.

I do have a concern/question that I thought about this morning and that has to do with financial institutions and disputes. For instance, PayPal can allow a dispute up to 180 days after purchase, but a right to request deletion has to be processed within 30 days of request...which means a user could purchase, request deletion and dispute within the valid timeframes.

The likely hood of winning a dispute is already low in some cases, but not having any data except the transaction ID could make that difficult. I'm still reading more into this but I'll keep posting my findings/questions once we have more info.

@katmoody
Copy link

My reading was that any data that could lead to the discovery of someone's identity. On the Transaction ID and such things, the only reason that they can currently lead to someone's identity is that they are all linked together. Removing the link back to the specific user would likely work, or anonymizing it?

The request to be deleted is just that, a request. If the data has to be kept for financial reasons (ie for VAT or tax filings) then my understanding is that the request can be denied for that reason as the other law overrides it. But I'm no lawyer and am just as confused as everyone else on a lot of the info I read.

@mindctrl
Copy link
Contributor

@cklosowski
Copy link
Contributor

This is exactly how I read it...and my perspective on it as well :)

The request to be deleted is just that, a request. If the data has to be kept for financial reasons (ie for VAT or tax filings) then my understanding is that the request can be denied for that reason as the other law overrides it. But I'm no lawyer and am just as confused as everyone else on a lot of the info I read.

@katmoody Thanks for your feedback. I appreciate it greatly.

@lalunecreative
Copy link
Contributor

@cklosowski Great, I couldn't find the ticket so I wasn't sure if there was one for it specifically! It's awesome that you guys are staying on top of it, do we have a release date thereabouts for the GDPR stuff? Core is pushing for the 15th with theirs.

@cklosowski
Copy link
Contributor

@lalunecreative No hard date yet no. I've been following core's tickets so I know their dates. As much as I want to push on the 15th with them and integrate, it's likely we'll be shortly after that to allow for some further development. While their date is the 15th, it's very likely there will be continued changes in their work up until that point, so we just have to keep shifting with the moves they're making.

It is a focus of ours though, so movement is continuing to press forward.

@danieliser
Copy link
Contributor

@lalunecreative I would argue any purchase is effectively consent.

To be fair, the mere fact they made a purchase that couldn't have been completed without checking that required field should constitute consent ;). IE They literally cannot complete the purchase without having done so (at least not without of the box options).

@cklosowski Not sure how much code you guys have dug into in terms of what core is doing, but I have been following closely and wrote up a quick implementation guide based on the functionality that core has introduced so far in beta, none of which has any documentation, so this may be of use to you guys.

https://danieliser.com/practical-guide-to-gdpr-compliance-for-wordpress-plugin-and-theme-developers/

@bobriley
Copy link

bobriley commented May 9, 2018

Hey guys, I sell a plugin and am using EDD Software Licensing - since Software Licensing records the sites whose licenses have been 'activated' it seems like we need to add something to our plugin itself, not just the website where we sell the plugin.

In our plugin we have a "activate license" page where it would seem like we'll need to add both a link to the privacy policy as well as a checkbox that ensures they've read the policy or they won't be able to activate the license.

For those of your selling plugins/themes using EDD SL, is this how you guys read things? If not, how you are handling it within your product?

@cklosowski
Copy link
Contributor

@bobriley We are still working through all the issues we need for all our repositories. Software Licensing doesn't have all it's own issues created yet.

As always we cannot provide specific things we read on the legislation because that would equate to us providing legal advice to you, and as you can see from this issue already, there are many interpretations of some of the language (like needing one checkbox or two, some argue 1, some say 2). EDD is building it in such a way that we're trying to make it so you as a store owner can implement the solutions in a way that your legal representation advises you to.

As we get closer to fully merging and releasing some of our implementations we'll have them ready for store owners to complete. We just got the WP Core functions less than week ago to start implementing.

@codebard
Copy link

codebard commented May 11, 2018

The thing with GPDR is that it requires an easy way for users to delete the data. So just a notice and confirmation like cookie law wont seem to cut it. Or 'you agreed to our terms of service' methodology.

To chime in the general discussion before this point and some of the approaches voiced : GDPR shouldnt be treated like VAT - VAT was, and is something that pertains to local tax authorities and their action: For there to be consequences, a local (national) tax authority must think that some site is not paying the taxes due to their government, and then act on it. There first needs to be probable cause for this to happen - just like any citizen in any country being investigated for suspected tax evasion. So the authority must be informed of valid purchases by their own residents, then must conclude that the tax for those valid purchases were not paid that quarter, then initiate the procedure for following up and so on. And the consequences would be according to how that country would handle that VAT avoidance - owed VAT plus a measure of interest and fines applied on top, which would be totally pointless to pursue for small amounts.

But GPDR is different - users not being able to delete data is something obvious and it doesnt require reqporting to an authority, or the authority trying to confirm non compliance through long legal procedures and follow up with another series of long legal procedures. An official tasked with investigating such issues can just register and confirm that s/he has no way to delete the data.

And the fine for non compliance is quite serious - nothing like what could potentially result from VAT avoidance.

For that, both WP and EDD and any major plugin must have their own way of handling GPDR by default, at least for the default features. Plugins may extend these, but such compliance must not be left to plugins alone.

@danieliser
Copy link
Contributor

@codebard - read over my link above about practical implementation guide. WP core v4.9.6 includes the forms and all of the eraser and exporter functionality in such a way that plugins simply extend it with their own export and erase functions. Same for privacy policy etc.

Core will be handing 99% of the workload and plugins should only have to deal with their own internal data by hooking into those existing interfaces.

@Spreeuw
Copy link
Contributor

Spreeuw commented May 14, 2018

Core will be handing 99% of the workload and plugins should only have to deal with their own internal data by hooking into those existing interfaces.

Exactly, but EDD & extensions should be providing that. You can't expect all shop owners to roll their own.

@cklosowski has already created something (WP GDPR - Easy Digital Downloads) that works with a third party extension (WP GDPR), but I think this should at least work with the core WP methods and then preferably be integrated into EDD itself. I can live with an add-on too, but if the add-on requires another add-on while this functionality is offered by WP Core I think that should be changed. (to be fair, this wasn't cristalized yet when chris created that add-on).

@Basilakis
Copy link

@Spreeuw I suppose that as long as EDD team gave us a solution, we have to leave with that.
if someone wants to go an other way ( like the core team did 1week before the GDPR update ), then they are free to go with that and develop on their own time ;-)

@Spreeuw
Copy link
Contributor

Spreeuw commented May 14, 2018

Fair enough, I didn't want to come across as if I were demanding anything, but I think it would make most sense to work with what is offered in Core regardless. But fully agree on the timing on everything and grateful that there is a working solution for now.

@rubengc
Copy link
Contributor

rubengc commented May 14, 2018

Then, what we should do? Wait to EDD update or as a temporal solution use WP GDPR + @cklosowski EDD add-on?

@pippinsplugins
Copy link
Contributor

EDD will be providing the export and deletion of personal data. It's nearly complete and will be released as soon as able.

@codebard
Copy link

That's really great to hear Pippin. Looking forward to it.

@danieliser
Copy link
Contributor

@Spreeuw - To be fair, the plugin you mentioned is a commercial one, the one that was the origination of the concepts being added to WP Core was free and worked on standardizing things.
That plugin is effectively dead now as those are merged into core.

I personally don't like the idea of a commercial option here like the one you linked. The reason being they get to decide what plugins & things they will support, what order, and when etc.

By putting the guts into the core, you will get to 100% coverage on your site much quicker. IE each plugin will do what EDD & Popup Maker and others have done and quickly extend the core functions with their own data.

This means that within days or weeks you can have thousands of plugins supporting GDPR rather than a handful that the team of that one plugin can get put together on their own.

That said I recently had a small quarrel with an EU user who blamed WP core for the sluggishness of developing these features. The facts though are that nobody from EU contributed early on with exception to those who developed commercial solutions. Only when non-EU devs took up the mission did core progress get made. To clarify only 1 issue about GDPR was submitted prior to Feb 28 2018, and 80% of those submitted since are from a Canadian and an American.

@Spreeuw
Copy link
Contributor

Spreeuw commented May 14, 2018

@danieliser I don't need to be convinced that using the filters from core is preferable over a solution that uses a 3rd party plugin (see my other posts above), I'm just thankful for the work of Chris that gives us a solution to work with today. And from Pippins remark it sounds like EDD core will have the export functions which I am assuming will be using the WP core filters so lets just be patient.
And thank you for the great documentation on those new filters, hats off!

@tomusborne
Copy link

One thing I'm worried about is the Software Licensing extension.

When a user activates their license key, their IP address and website URL are logged in the EDD Dashboard. Any thoughts on this? How will this be handled within EDD itself for its own extensions?

@danieliser
Copy link
Contributor

@tomusborne - based on my research their is no reason to worry about it. That is essential data to the contractual agreement to provide service you both entered into when they purchased.

Same as things like legal invoicing. They can’t expect you to delete all record they purchased. That would be illegal. Same concept here. You need that info to do your job reasonably well.

@cklosowski
Copy link
Contributor

Ok, it's time for an update with actual code and issues so here's the short version of where we are at:

We have a few status:

  • To Do
  • In Progress
  • Ready for Review (just needs review and testing)
  • Approved (Means it has been tested and code approved)
  • Done (Means it has been merged, but not yet deployed)
  • Deployed (The code has been deployed to users)

Misc Issues:
EDD: Privacy Policy Checkbox for checkout: Deployed (#6484)
Free Downloads: Newsletter Opt-In Unchecked by default: Deployed
EDD: Helper functions for masking data types: Done (#6502)
Free Downloads: Privacy Policy Checkbox: Done
EDD: Record agreements and terms on customer record: In Progress (#6432)
EDD: Privacy Policy Example Template: Ready for Testing (#6530)

Data Export Requests:
EDD: Customer Record: Done (#6544)
EDD: Customer Payment Data: Done (#6543)
EDD: File download log improvements, in preparation for export/eraser (#6548)
Simple Shipping: Customer Shipping Addresses: Approved
EDD Message: Export logged messages: Approved
EDD: Include file download logs in Export: Ready for Testing (#6499)
Reviews: Include Customer Reviews in Export: Ready for Testing

Data Anonymizer/Eraser:
EDD: Anonymize Customer Record: Approved (#6498)
EDD: Anonymize/Delete Payments: Ready for Testing (#6497)

We have a list of To Do items that I'm working through still, but that should give you some idea of where we are at with all the issues we've currently worked on.

@lalunecreative
Copy link
Contributor

Is it possible to switch the TOS agreement to allow a selection of a page like the privacy policy options instead of writing it directly in EDD? I get that it's using Core's new features, but why not just make them consistent with each other?

@danieliser
Copy link
Contributor

@lalunecreative Assuming I correctly understood what you are asking (take a section from the middle of another page) your likely not going to see that. Standardizing that also means you likely have to insert something into that page manually around your section that another plugin could use to pull the right info. This means a shortcode start & stop, or manual html etc. Ugly solution really once you break it down.

That said there are plugins that allow inserting page content via shortcode, but not only partial content (unless you mean the excerpt).

Simply no clean way to do what your asking, again assuming I understood correctly.

@lalunecreative
Copy link
Contributor

lalunecreative commented May 18, 2018

Sorry I wasn't clear, right now you can select a dropdown in EDD to choose a privacy policy page. Which shows up on in the checkbox when you go to checkout. Instead of writing the TOS in the box on the settings page, why not just offer that same dropdown and select a page? It wouldn't be doing anything that you aren't already doing with the privacy policy option.
terms

@fuzzytake
Copy link

fuzzytake commented May 19, 2018

@cklosowski Downloaded and activated the wp-gdpr-edd-addon plugin

However, the wp-gdpr-core returns the following error on the Add-on Licensing section:

Fatal error: Class 'wp_gdpr_edd\lib\Gdpr_Form_License' not found in /web/htdocs/www.example.com/home/wp-content/plugins/wp-gdpr-edd-addon-master/view/admin/menu-page.php on line 12

11 print_form(); 14 ?>

Thanks

@Stiofan
Copy link

Stiofan commented May 21, 2018

When is the GDRP compliant version intended for release and is there anything i can do to help (as a developer)?

@cklosowski
Copy link
Contributor

@lalunecreative We were going for the least number of changes for our users for now. It's possible we may switch our Terms of Use to be a dropdown for a page, but for now we're keeping it as a setting as to get as much work done without having to run regression testing against all the other areas that aren't directly affected by this.

@cklosowski
Copy link
Contributor

cklosowski commented May 21, 2018

@fuzzytake For now we're focusing on the tools build within WP Core. Since that is bundled for free with WordPress and is likely to be the most used platform for GDPR compliance we'll start there and then continue work on the Integration plugin you're discussing once the Core work is done.

@cklosowski
Copy link
Contributor

@Stiofan master currently has quite a few issues already merged (see #6216 (comment)). I'm working through the rest of the core ones today to try and get them into master.

By the EOD today, I'm hoping that core will have the exporters and anonymizers for itself merged into master

@cklosowski
Copy link
Contributor

EDD Core master branch now has all of the functionality for 2.9.2 in it. We have a few small tweaks to make to the way the settings or organized, but that will not affect the functionality.

I will keep this issue updated with any release information as we near that time and have documentation built.

@cklosowski
Copy link
Contributor

EDD 2.9.2 (and subsequently 2.9.3) are released with our initial work for GDPR. Since we've pushed these out, i'm going to close this issue for comment, so we can raise any new points as new issues for easier milestoning and future releases.

Thank you all for your feedback and due diligence in the conversations regarding GDPR.

@awesomemotive awesomemotive locked as resolved and limited conversation to collaborators May 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests