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

[RFC] Joomla should provide a GDPR standard for extension developers #20140

Closed
aDaneInSpain opened this issue Apr 11, 2018 · 37 comments

Comments

Projects
None yet
@aDaneInSpain
Copy link
Contributor

commented Apr 11, 2018

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

@laoneo laoneo changed the title [Discussion] Joomla should provide a GDPR standard for extension developers [RFC] Joomla should provide a GDPR standard for extension developers Apr 11, 2018

@joomla-cms-bot joomla-cms-bot added the RFC label Apr 11, 2018

@laoneo

This comment has been minimized.

Copy link
Member

commented Apr 11, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

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.

@ReLater

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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."

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

A GDPR component would be one of these:

A 3rd party extension is any extension that stores personal data, such as AcyMailing for instance.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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?

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

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?

@rdeutz

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

boh, get a room

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 11, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

Well... when contributions are met with personal attacks I can't really blame them.

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 11, 2018

@marcodings

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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.

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 11, 2018

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).

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2018

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?

@ggppdk

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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>
@alikon

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2018

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 ...

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 12, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 12, 2018

I like the idea of providing an indication of how data should be anonymized and have included it in the proposal.

@simbus82

This comment has been minimized.

Copy link

commented Apr 13, 2018

@Ruud68

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2018

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.

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 15, 2018

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.

We need to prioritize here, and we need to get people onto actionable tasks pretty damn quickly if we're doing something in core.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 16, 2018

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?

@shoulders

This comment has been minimized.

Copy link

commented Apr 16, 2018

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.

@Ruud68

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

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)
@shoulders

This comment has been minimized.

Copy link

commented Apr 17, 2018

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

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

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?

@shoulders

This comment has been minimized.

Copy link

commented Apr 17, 2018

I think you are saying

  1. make the standard
  2. vendors will then adopt it

I am saying

  1. make a joomla core component with the standard
  2. 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.

@aDaneInSpain

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

  1. 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.

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 17, 2018

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.

@ReLater

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2018

  1. Open a separate github project but related to Joomla-CMS.
  2. define the standards
  3. 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?)
  4. Then extend component/package or make it extendable; e.g. by plugins and special plugin events, helper classes and so on.
@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 28, 2018

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.

@rdeutz

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2018

I don't have time left to spend on this topic.

@mbabker

This comment has been minimized.

Copy link
Member

commented Apr 29, 2018

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.

@wilsonge

This comment has been minimized.

Copy link
Contributor

commented May 2, 2018

Closing this in favour of #20281 - and letting you take charge of this Michael

@wilsonge wilsonge closed this May 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.