Google tag manager / iframe in Joomla Backend

[coolcat-creations]

I reported an issue in joomla-cms repo aboutembedding an external iframe with tracking code from help.joomla.org / docs.joomla.org https://github.com/joomla/joomla-cms/issues/26200

Due to DSGVO (German law) I think you have to inform your visitors about tracking. I am not sure if GDPR applys the same.

We would either need to

• add information about tracking
• remove tracking

Now this issue affects all Joomla backends (because of iframe embedding) and the Joomla properties itself.

thanks!

[mbabker]

It seems some people on some project teams are just now learning that Joomla has a help system within it. And their initial response is to remove GA from help and docs subdomains. If that’s the case, GA will have to be removed from all joomla.org properties since it seems the intent is that Joomla cannot link to a site with any form of analytics and links introduced into J4 such as to GitHub will need to be removed since I doubt you’ll convince them to remove analytics.

[jeckodevelopment]

Hi @coolcat-creations thank you for reporting this issue.

@mbabker I don't think that the removal of GA/GTM is the solution we're aiming at. We could control the "activation" of GA/GTM through the Cookie Script and avoid loading it when the docs site is loaded through the help server. So that should solve the issue.

[mbabker]

1. The cookie control script requested by the compliance team was ready for general rollout to the Joomla installs on .org 9 months ago (extra action would be needed for the help and docs subdomains since they aren’t Joomla sites, but it is not much effort). This could have been solved 9 months ago.

2. Without adding more URL query params or using cookies, you can’t decide to not trigger GA based on referrer (which is not always available based on security configurations). Therefore the most acceptable/reliable fix is to remove GA in general. Or, actually ship the cookie control script.

[mbabker]

Either pull the trigger on shipping cookie control or I am removing GA from the template. Because ultimately those are the two options and I know which one will be implementable in a timely manner.

[coolcat-creations]

It seems some people on some project teams are just now learning that Joomla has a help system within it.

I am not in any team...

[mbabker]

Wasn’t referring to you, rather it was (an admitted) cheap shot at others on certain teams who I would have expected to not only know this feature exists in core but how it works given what their team’s purpose is.

[jeckodevelopment]

The cookie control script requested by the compliance team was ready for general rollout to the Joomla installs on .org 9 months ago (extra action would be needed for the help and docs subdomains since they aren’t Joomla sites, but it is not much effort). This could have been solved 9 months ago.

As far as i know it was pending webmasters team's review.

[mbabker]

And AFAIK (since I’ve ghosted all channels on Glip because of the high stress I find myself under when interacting with the project for too long) that was only requested in the last couple of weeks. My annoyance here is it really shouldn’t have taken a year from the time they first started auditing cookies to the time they asked for general review (meaning the task is still not complete). And if it’s true that people in the teams didn’t realize the help subdomain was embedded into Joomla through iframes and popouts until today then that’s even more frustrating because this should have been found in an audit at an absolute minimum (ignoring the fact if you’ve used Joomla long enough you have probably clicked on a help toolbar button or the help page where the screens are iframed in and seen this).

[coolcat-creations]

Any news about that issue? Because it's affecting the Joomla backend see: https://github.com/joomla/joomla-cms/issues/28865

[mbabker]

Either this should be closed as working as intended as all joomla.org properties are using the same GTM code, or GTM should be removed from the entirety of joomla.org if a policy of "anything linked to from the Joomla administrative interface cannot have an analytics tracker" (subdomains linked to from the 3.x admin include help, docs, community, developer, resources, extensions, www, downloads, and forum; about the only things not linked are the VEL, Volunteers Portal, Showcase, and the OSM website). I would not encourage subdomain specific policies because something is linked to from the Joomla administrative interface.

Prime example of why these types of special policies is a waste of time. How is the help subdomain having analytics on it any different than the downloads subdomain or community subdomain or www subdomain having analytics on them? The same information is going to be gleaned whether you click the "Joomla! Help" link in the main menu, the link on the "Upload & Update" tab of the core update component, the link to the privacy policy on the "Privacy: Extension Capabilities" screen, or one of several links that end up on the community subdomain (training, shop, translations).

[jeckodevelopment]

At this point, I believe that adding a disclaimer/notice that explains what kind of information is collected and how, would be the right path to solve it. What do you think?

[coolcat-creations]

If you are aware that you click an external link you are aware you visit another website. This other website should have eventually the cookie banner to inform the visitor about the usage of tracking cookies. In this case it looks like a regular core button in Joomla Backend and a Popup opens without any Cookie Banner. So either GA needs to be removed from J Properties (and maybe a FOSS used like Matomo, they offer cookie-less tracking by the way) Or in the Backend we need to make it visible that you open an external link and also open it in a full website with cookie banner...

[brianteeman]

This really should be a matter left to the dedicated team for GDPR etc

[conconnl]

This really should be a matter left to the dedicated team for GDPR etc

Indeed, compliance team is created for these things. Webmasters Team members can help with Technical things. I will do my own check on the help.joomla.org and how it loads the docs site, the information found I can share with compliance team

[coolcat-creations]

Still we need to do something in the CMS itself about it too.

[conconnl]

For what reason do you need something in the CMS, if the compliance team would come with a solution / decision or whatsoever which result in only having functional cookies?

[coolcat-creations]

Because in the backend we actually let the user run in this tracking without notifying before. The Help Button which opens the Popup looks like it belongs to the backend, but it's not.

In Joomla backend we need to

• make it visible that the user clicks on an external service
• make sure we link to websites that offer a opt-out banner and not just a popup

OR:

If the compliance team would come to a solution very fast, we of course do not need to work on both sides, but in my opinion privacy issue should be cared about and we should fix it as soon as we can.

(The Issue was reported in September 19 already and closed in the cms repo and left open here)

[conconnl]

• I can't do anything on the CMS itself (code wise), I'm sure you can make something happen if a change is needed in Joomla.
• The help server is also part of Production (@marcodings), I can only try to collect information and share it.
• The Complince team (https://volunteers.joomla.org/teams/compliance-team) can be involved, everybody has the ability to contact them.

If doing something depends on a open repository for joomla-websites where volunteers maybe or not look at it and maybe take actions, because someone just wrote a message, then we have other things to improve as well.

[coolcat-creations]

@jeckodevelopment since you are here already and assistent team leaser, can you forward it to the team? Thank you :-)

[brianteeman]

Something about this doesn't make sense to me

• The GDPR came into effect on 25 May 2018 - that is almost TWO years ago.

• All versions of Joomla use the help.joomla.org web site to serve the help pages.

• No one other that @coolcat-creations (that I am aware of) has raised this is an issue in all this time.

[coolcat-creations]

Something about this doesn't make sense to me

* The GDPR came into effect on 25 May **2018** - that is almost **TWO** years ago.

* **All** versions of Joomla use the help.joomla.org web site to serve the help pages.

* No one other that @coolcat-creations (that I am aware of) has raised this is an issue in all this time.

Ok, what does not make sense exactly? In germany we have a saying "where no plaintiff there no judge" - but that does not mean that what we do here is right...

[brianteeman]

Ok, what does not make sense exactly

That no one other than you is raising this - if it is such a crucial/legal/important/ thing then I would have expected a lot of comments/requests.

You only have to look at the hundreds of comments related to the privacy plugin and yet nothing on this.

[coolcat-creations]

Ok, what does not make sense exactly

That no one other than you is raising this - if it is such a crucial/legal/important/ thing then I would have expected a lot of comments/requests.

You only have to look at the hundreds of comments related to the privacy plugin and yet nothing on this.

I think with these kind of measures you work in your comment, it is not possible to determine if a issue is valid or not @brianteeman

[brianteeman]

I am not saying it is valid or invalid. I am just saying that I am surprised no one else has raised this. (There are plenty of Germans on the production team)

[coolcat-creations]

Well - the issue was closed in the main repo ;-) @brianteeman

[brianteeman]

and a thousand other people could have raised it. Or if they had searched then they would have been redirected here and commented here but they didnt

[coolcat-creations]

https://gdpr.eu/cookies/

"To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must:

Receive users’ consent before you use any cookies except strictly necessary cookies.
Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received.
Document and store consent received from users.
Allow users to access your service even if they refuse to allow the use of certain cookies
Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place."

[conconnl]

Probably it's me, as I'm not a coder. I would think that removing GTM from the code on pages like this, is enough to remove GA from the Help proxy. https://github.com/joomla/help.joomla.org/blob/master/templates/helpscreen/base.html.twig

[mbabker]

If it is the edict that GTM should be removed from the help screen proxy then by the same criteria GTM must be removed from all .org subdomains linked to from the Joomla administrative interface and all links to third party platforms which utilize any form of analytical system (cookie based or not), which includes GitHub, should also be removed.

The help screen proxy should not be treated as a special case.

It is not a matter of just removing a line of code from a template. There is a practical issue being raised here. IMO if there is a concern with a pop up from within Joomla loading an external domain that includes analytical tracking, then all external links should play by the same rules.

[mbabker]

If someone feels that my call for not having a special case for a .org subdomain is appropriate, then the other option is the formal deprecation of the help screen proxy and just hard redirect to the Docs wiki and be done with it.

Or, someone can add some obtrusive styling to make it evident that the help content is not coming from your local Joomla installation, instead of the design that is there now which makes the content appear as a seamless integration into the platform.