GDPR EU regulation? about legal HOT 11 CLOSED

I wonder what you expect from this issue. The legal module can only provide some means for your legal documents. It can and will not take any responsibility for the contentual aspects.

from legal.

The site owner takes sole responsibility for all legal matters. While Zikula may provide some “help” in this area (e.g. the Legal module, etc), the project has no legal standing to take responsibility for any matter whatsoever. As with ALL Open Source projects, you use them at your own risk. Zikula cannot be liable for any legal matter.

from legal.

We may need to give the user an information about his data stored at the site. That can be a part of legal or even a new module wich is collecting all data. Need more reading about the requirements.

from legal.

I've read some brief summaries on the topic, and some might apply to Zikula in general, some to particular Zikula modules. Maybe some not at all. Personally I have a hard time understanding why ANY EU regulation is binding on ME, here in the US. But, I expect our EU members will have expectations that I will meet if I can.

(by "members" I mean members of our non-profit, not of the Zikula community)

Basically, here are the broad concepts:

Consent. EU residents must grant "provable consent" for data collected on them. I take this to mean "marketing" data but I might be wrong. For mailings, double opt-in is required. This I guess would apply to a bulk mail module in Zikula, but it could be facilitated by an opt-in checkbox provided by the Legal module.

Access to data. If we store data on an EU resident, they have the right to request that data to see what it is. This could, I suppose, be provided by a dedicated module that finds and displays any record with links to a user record or master content record for that person.

Right to be forgotten. What a headache. If they want their data removed from your database they can do that and you have to comply. In order to maintain database integrity, I don't think this could be a "delete" function; you would have to null or clear the data in each related record. Maybe there could be an api or hook that responded to an action to initiate this in the User module.

Notification of data breach. Self explanatory.

from legal.

@Guite at least a discussion. I know from my friends that this GDPR topic is now highly debated and this affects how end user expects software to behave in order to comply with some of those regulations.

@craigh, of course, responsibility is not an issue, no one expects Zikula takes any responsibility as Open Source. It is more about that "help" part.

@rallek It is not that easy, unfortunately...

@robbrandt Thanks, we have some cases to discuss at least... (I guess it does bind you because of US-EU agreements and maybe if those will not be sufficient new ones will be made)

So there are two areas Zikula core and 3rd party modules, of course, we can focus only on Zikula core and there are 3 ways of handling it:

0. No handling or add only text information in the legal module that GDPR is not supported or supported partially (users can be deleted but only from users table) - so basically what we have now.

1. Zikula core only is GDPR ready - (this is kind of ridiculous as we all use 3rd party modules but...) so I'm now not sure about this example but in case of "Right to be forgotten" it can be done two ways:
   1.1 the user is asking admin etc via email and then admin is removing user and data manually
   1.2 user just click remove my account and data associated with it and core is cleaning all data collected for that user - so in case of plain core it will be users table, zauth table and this is all - no 3rd party modules data involved etc..(I consider profile module as 3rd party)
   In case of Consent and Access to data - similar thing just data that core collected and Zikula core is ok - Of course, this probably would make more harm than help as some might think that all data was removed even from 3rd part modules.

2. Provide a mechanism for easy user data review/remove where module (core and 3rd party) can respond to user data view or user remove data event... something like LinksContainer or Search.
   I do not think we need another core module we could in principle use LegalModule to provide this mechanism which from user perspective could be just two additional links in users panel - Display collected data and delete an account and collected data. I can imagine additional "flag" that marks modules in extensions that are Data protection capable in composer.json for example.

I think this kind of data protection laws sooner or later will come to US and other countries as well and it will be a standard.

from legal.

https://techblog.bozho.net/gdpr-practical-guide-developers/

from legal.

https://ec.europa.eu/commission/priorities/justice-and-fundamental-rights/data-protection/2018-reform-eu-data-protection-rules_en

https://ec.europa.eu/commission/priorities/justice-and-fundamental-rights/data-protection/2018-reform-eu-data-protection-rules_de

from legal.

How about removing the (very obsolete) default content of the privacy policy template? IMHO we should replace this by a placeholder like we have at the trade conditions or the legal info, too.

from legal.

👍

from legal.

GDPR has been a recurring topic in our non-profit and we've spent a lot of time talking and thinking about it. I have some broad suggestions for how Zikula could ease the burden of complying with it. These suggestions have to do primarily with the data review, export and right to be forgotten portion of the law. As for us, we aren't going to do anything explicit to support these; we are just going to hope that the few EU citizens we support don't ask for these things. If that's the case, we will address them manually. If it gets to the point where these requests are routine, some coding will have to be done.

On to the suggestions. These could provide a competitive advantage to Zikula if they were built into the architecture:

Core:
Develop an API for the following functions:

• disclose: this would show the visitor any Personally Identifiable Information (PII) stored in a given module
• migrate: this would encapsulate all the "disclose" data into a common format, such as csv or json
• forget: this would either delete or anonymize any PII in a given module.

How each module responds to those API calls would vary according to what the module dev thought best. For the Users module it would include nearly everything for a given user. For a shopping cart module it would anonymize PII while retaining the actual transactions. A forum module could delete all posts based on UID.

MOST could help with this. In addition to merely creating classes that would respond to the API calls, it could provide default services, such as assuming that PII is associated with the "own" features based on UID. I.e., disclose all data where created_uid = the member's UID, migrate that data, and forget that data.

Personally, I am hoping that our treaty canceling president performs a GDPRexit.

from legal.

@robbrandt thanks for this comprehensive post, it contains some nice ideas. After the first (urgent) activities have been done we can look at this topic (what can Zikula support) again I think.

from legal.