[#20140] - [RFC] Joomla should provide a GDPR standard for extension developers
- Closed
- 2 May 2018
- Medium
- Build: staging
- # 20140
The Problem
There are now several GDPR extensions emerging that allows Joomla site owners to install the extension to comply with the GDPR. The trouble is that they ideally should also support 3rd party extensions so that 3rd party extension developers can also show what data they collect and what data they will be deleting or anonymizing when requested. Each GDPR extension will likely offer different methods for including 3rd party extensions.
The solution
Joomla defines a standard that both GDPR extensions and 3rd party extensions should follow. 3rd party extension developers only have to include one XML file (for instance) and that can then be used by whatever GDPR extension that supports the standard.
Proposal
This is an early first draft that I am sure has lots of room for improvement, but it will serve as a basis for discussion.
<?xml version="1.0" encoding="utf-8"?>
<gdpr>
<name>Extension Name</name>
<comname>com_example</comname>
<version>5.7.0</version>
<author>Business Name</author>
<authorEmail>dev@developer.com</authorEmail>
<authorUrl>http://www.developer.com</authorUrl>
<personalData>
<data deleteMethod="keep">
<table>#__com_example_users</table>
<field>name</field>
<userIdField>user_id</userIdField>
<name>Name</name>
<description>The registered users first and last name</description>
<why>Used for personalized greetings</why>
<anonymize length="20">randomize</anonymize> <!-- Requests that a random string is generated with a length of 20 -->
<consent>
<table>#__users</table>
<date>registerDate</date>
</consent>
<data>
<data deleteMethod="anonymize">
<table>#__com_example_users</table>
<field>email</field>
<userIdField>user_id</userIdField>
<name>Email</name>
<description>The registered users email address</description>
<why>Used for contacting the user when changes to the account happens. Only transactional emails will be sent. Never any promotional data.</why>
<anonymize file="components/com_example/helpers/helper.php">Example::generateRandomEmail()</anonymize>
<consent>
<table>#__users</table>
<date>registerDate</date>
</consent>
<data>
<data deleteMethod="delete">
<table>#__com_example_users</table>
<field>birthdate</field>
<userIdField>user_id</userIdField>
<name>Birthdate</name>
<description>The birth date of the user</description>
<why>Used for showing a greeting on the dashboard on the birth date of the user</why>
<consent>
<table>#__users</table>
<date>registerDate</date>
</consent>
<data>
<data deleteMethod="deleteRow">
<table>#__com_example_log</table> <!-- Whole row will be deleted -->
<field>ip</field>
<userIdField>uid</userIdField>
<name>IP Address</name>
<description>The IP address used when accessing the site</description>
<why>To log potential illicit usage of the account</why>
<anonymize>delete</anonymize> <!-- Ignored as the whole row will be deleted -->
<consent>
<table>#__users</table>
<date>registerDate</date>
</consent>
<data>
</personalData>
</gdpr>A few things to note:
- userIdField indicates what field the user_id is stored in so the GDPR knows which row to delete/anonymize
- consent contains information about what field in the database stores when consent was given to store this data
joomla-cms-bot
- | Labels |
Added:
?
|
||
franz-wohlkoenig
- | Category | ⇒ | Code style |
| Title |
|
||||||
| Labels |
Added:
?
|
||
Just to clarify. This is not a proposal for the core to take care of GDPR but to set a standard for those 3rd party GDPR extensions to follow to allow for them to manage the personal data collected by yet other 3rd party extensions. I am simply proposing that Joomla sets a standard for how extension developers should collaborate to solve the GDPR issue.
Could you please explain what a GDPR extension is? When becomes a 3rd party extension a GDPR extension and vice versa? Who will control that and how?
At the moment I would say: Never ever should Joomla define any pseudo-standards related to a completely unnecessarily complicated and confusing law and attached regulations without having a legal department that controls these standards and that is willing to adapt them to changes continuously during the next dozens of years. Why? Because developers and users will rely on these standards: "I've done my part like Joomla recommended it and added an additional XML file."
such a shame that you didnt look at or participate in any discussion about the current proposal - are you really so disconnected from Joomla that you didnt know that some of us have been working on this for a long time
| Status | New | ⇒ | Discussion |
I am far too busy to read everything on GitHub yes.
But I did run it by the whole GDPR team who did not seem to know anything about the current proposal. Maybe I am not the only one "disconnected from Joomla"?
But why the personal attack on someone trying to help solve a problem? I think your energy should instead be spent on trying to come up with the best possible solution for Joomla. Maybe my idea can be included in what has already been discussed or if not discarded.
A GDPR component would be one of these:
- https://pixpro.net/labs/extensions/pixgdpr
- https://www.joomlart.com/blog/joomla-extensions/preview-ja-joomla-gdpr-extension
A 3rd party extension is any extension that stores personal data, such as AcyMailing for instance.
the fact that the "gdpr" team who have never made a report or anything on the volunteer portal have not done anything about this says so much.
I think your energy should instead be spent on trying to come up with the best possible solution for Joomla
That is exactly what I have been doing or I would not have spent the time writing the code and working with others to make it even better.
Really make me wonder when a director of joomla has no idea what is going on in joomla. Did you even try and search on the issue tracker first?
Your pull request does not address the issue I hope to discuss. Your pull request is all about a checkbox, and does nothing in relation to standardising how 3rd party extension developers should handle GDPR. If by "current proposal" you are referring to your pull request then you are comparing apples to bananas or "a checkbox" to a "proposal for a standard".
Also... the Compliance team has released several reports on the volunteer portal and held a sprint and written articles for the Magazine and is one of the most active teams we have at the moment.
Maybe I am not the one who is "disconnected from Joomla" - did you consult with the compliance team before submitting your pull request?
boh, get a room
The compliance team working on a partial compliance solution for joomla.org user profile management? (As in they aren't doing any work related to core GDPR compliance, or helping with questions I've raised about GDPR compliance outside of user profiles). Sure, they might be working on some stuff, but it's not helping here.
Well... when contributions are met with personal attacks I can't really blame them.
Well when someone basically says "I can't be bothered to search for
existing discussions so here's a solution" it doesn't help either.
What this covers is a different scope from the now closed PR that was "all
about a checkbox", a far more visible compliance related task.
Either way I can pretty much say with certainty GDPR compliancy and Joomla
core won't go hand in hand ever if everyone is going to work on their own
solutions and not try to collaborate on existing discussions or proposals.
On Wed, Apr 11, 2018 at 9:08 AM Søren Beck Jensen notifications@github.com
wrote:
Well... when contributions are met with personal attacks I can't really
blame them.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20140 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoTdF0PXm15Y40rywcKXSEtMeRqlWks5tng5ZgaJpZM4TPkb7
.
--
- Michael Please pardon any errors, this message was sent from my iPhone.
For me Søren's approach makes sense, it provides a way to indicate private data as such it should be a core supported feature.
"Brian's" plugin could draw from "Søren's" propose definitions as could other implementations that list or purge privacy data.
The plugin had nothing to do with indicating what is considered private data, it had everything to do with making defining a privacy policy and gathering user consent simpler. The work in that PR goes hand in hand with what is proposed here, but one is not a blocker for or dependent upon the other (and the fact some of the responses seem to indicate they are two alternative approaches to the same problem means people aren't grasping the differences). Even more, as a repo maintainer, it's frustrating that this thread has basically disclosed a "I couldn't be bothered to search for similar topics" mentality which indicates no awareness of previous discussions or proposals (even if none of them touched on this topic).
I agree. I should have searched for similar topics and it was lazy of me. The fact that I would not have found any is a different issue.
I did ask the GDPR (compliance team) though, although I can see that they are working mostly on ensuring that joomla.org is compliant and not so much on the product.
and the fact some of the responses seem to indicate they are two alternative approaches to the same problem means people aren't grasping the differences
Exactly my point. So, can we get back to discussing if this is something we should be doing?
The plugin had nothing to do with indicating what is considered private data, it had everything to do with making defining a privacy policy and gathering user consent simpler. The work in that PR goes hand in hand with what is proposed here, but one is not a blocker for or dependent upon the other ...
Exactly the now closed PR (Privacy policy plugin) and this proposal are complementary
and then we also need UI (left to 3rd party extensions ??)
- deleting the records specified by
<gpdr>definitions and / or anonymizing the relevant fields ?
Now about <gpdr> definition every extensions should also "specify" or provide a method to anonymize the data ??
<anonymize>empty</anonymize>
<anonymize>random</anonymize>
<anonymize>?? staticclass::method ??</anonymize>
i've recently attended to some GDPR brainstorm meetings (even if we are late joining to this party as a closed source firm), but this for sure not make me an expert at all, at contrary , even if there was some payed experts as relators, my personal achievement attending this kind of meetings, is that no one is a "guru" on this matter, there are too much aspects to take care of, especially if you are or you claim to be a "worldwide" supplier, so with this ipothesis in mind, we should follow the "one single small step at the time " approach, and in this case the, #20051 is one starting "real" piece of the full picture
i've made a naive pr #19023 approach to the delete/anonimyze matter
so as the "acient romans said" divide et imperat ...
That is great. I hope it gets included.
But again. This topic is not really about how Joomla handles GDPR but if Joomla could help set a standard for how 3rd party developers can help comply with the GDPR and also delete personal data they store.
It would be great if Joomla supported this standard, if we are including a user self-delete functionality.
The idea would be to try and get all 3rd party developers use one standard for indicating where they are storing personal data and then let whatever GDPR solution the web site owner has chosen (core or 3rd party) handle the deletion of data in core and 3rd party extensions.
I like the idea of providing an indication of how data should be anonymized and have included it in the proposal.
Can we learn something from here? https://wordpress.org/news/2018/04/gdpr-compliance-tools-in-wordpress/
yesterday attended 2 gdpr sessions at the Dutch Joomla Days. The more I think of it the more I think this is a 'must'. Not only would it standardize and therefore simplify the life of extension developers to incorporate and comply to gdpr regulations (especially when you have a site with multiple extensions that gather personal data), it would also be yet another good reason for using Joomla as your CMS of choice.
I think Joomla Core should not only provide security, coding quality and speed, but also compliancy (guidelines / api).
Reading this thread, I am not sure what the next steps are, if / what decisions have been made, and what role I can play in it?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20140.
OK, I'm just going to put this bluntly.
We have 40 days to get a release out with what is essentially required to ensure Joomla can be GDPR compliant. This issue, while important, IMO does not block implementing GDPR related functionality. Yes, it will help with identifying some things related to the data storage layer, but there is still a lot to be considered.
- https://wordpress.org/news/2018/04/gdpr-compliance-tools-in-wordpress/
- https://github.com/gdpr-compliance/info
We need to prioritize here, and we need to get people onto actionable tasks pretty damn quickly if we're doing something in core.
I agree that we should prioritise making the core compliant first. This proposed standard should be secondary, but should of course be supported by the core when rolled out.
But we do also have urgency on this standard as 3rd party developers are also scrambling to develop GDPR extensions and would need the standard released as soon as possible.
I think we just need to start actually discussing the standard instead of discussing everything else. I had one comment regarding the standard and implemented the proposed changes. What do people think?
On a similiar thought. would it be better for Joomla to have a core component for GPDR where 3rd party software vendors could register their data streams and then a user could see all of their data in one place via this component. This would create a GPDR integration standard in Joomla that developers could follow.
On a similiar thought. would it be better for Joomla to have a core component for GPDR where 3rd party software vendors could register their data streams and then a user could see all of their data in one place via this component. This would create a GPDR integration standard in Joomla that developers could follow.
+1
and for who missed it: #20051 is reopened :)
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20140.
On a similiar thought. would it be better for Joomla to have a core component for GPDR where 3rd party software vendors could register their data streams and then a user could see all of their data in one place via this component. This would create a GPDR integration standard in Joomla that developers could follow.
Yes. Ideally Joomla's built in component should follow the standard but we should not close off the standard to only Joomla. We should support 3rd party developed extensions. Sometimes they do a better job than the core at certain tasks and this might be one of them.
I have updated the example XML with the following:
- Now has a
<why>tag to show why we collect the data - All tags have been camelCased instead of d-a-s-h-e-d
- Added deleteMethod attribute to indicate how data should be deleted
- Added a deleteMethod attribute value of "None" to indicate that we are gathering personal data but that it should not be deleted even when requested (this is for vital data such as contact data for an invoice)
The joomla component would not follow the standard, it would be the standard because all the 3rd party vendors register their data streams within the core joomla component and this leads to a standard way on installing and reading streams etc...
Why re-invent the wheel several times by different vendors. Joomla should be used as a unifying platform and this is a perfect example. Once there are standards in place for the Joomla component more developers can adopt it.
We should use Joomla as the platform for things like this where it is a central hub to bring together different software manufactures otherwise Joomla will end up like wordpress where everyone does there own thing and wordpress is almost vestigial.
so I am for a Joomla central Component for GPDR that covers all of the nessasary actions for GPDR + permissions etc..
anyhow that is my thoughts
Well... I am not sure we disagree. I am just proposing that we make the standard now so that 3rd party developers can also get started on implementing the standard. Not sure how that is different from what you are saying?
I think you are saying
- make the standard
- vendors will then adopt it
I am saying
- make a joomla core component with the standard
- vendors will adpot the use of the standard and the core component
This allows for more uptake of the technology and centralising of the data. If the standard is released without a central repository I think there is a risk of the data being fragmented
I think we absolutely agree on a standard for suppling the data but I think the only difference is that instead of there being many different control panels i.e. https://stackideas.com/blog/easyblog52-stable-released and then another for all of RSFeedback, Kunena etc.... I would like it all in the one Joomla Core component.
But either way like you said a standard needs to be made. I hope my comments are helpful and not to pushy.
- make a joomla core component with the standard
You are missing a step in your approach. Before we can make a component with a standard, we need the standard.
Then after that Joomla and vendors can implement it. Many users might prefer to use a 3rd party solution for handling GDPR and not the core. The standard will ensure that both options are available.
Specification then implementation. This ensures there is some resemblance of a plan and feature spec in place to work from instead of just coding stuff and hoping it works for what's needed.
- Open a separate github project but related to Joomla-CMS.
- define the standards
- create a decoupled, basic Joomla component/package.
A) In the first step as an info tool (already helpful for developers and users to see dependencies).
B) documentation
C) include relevant XML files in Joomla core (Profile plugin?) - Then extend component/package or make it extendable; e.g. by plugins and special plugin events, helper classes and so on.
OK, 2 weeks ago I said we had 40 days to figure out what we needed to do to have a GDPR compliancy release ready by enforcement date of May 25. People have been trying to work out a way to address this particular issue and have been moving forward with other seemingly related tasks, but there remains no guidance or communication from the Production Department Leadership.
So... @wilsonge @rdeutz @nibra @dgrammatiko @marcodings @laoneo @SniperSister can someone either set a plan for Joomla releasing a set of GDPR related compliance tools for core or say you all are too busy and I will figure things out myself and simply report status to department leadership until someone wants to step in and be involved or manage the task themselves.
I don't have time left to spend on this topic.
Looking at that GDPR Compliance Info repo I linked a bit ago, they have a section talking about cookies. That probably needs to be incorporated in some form into whatever API is exposed so that the site administrator has a list of cookies (and their uses) from extensions which report the data.
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-05-02 22:29:07 |
| Closed_By | ⇒ | wilsonge |
Personally I prefer such a solution over #20051. If the core takes care of GDPR, then in a way that the whole eco system benefits of it.