Lack of interest Avoid Google Analytics receiving PII via query strings

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Kirby

Well-known member
Issue
Under some circumstances, XenForo does pass personally identifiable information to Google Analytics which does violate the terms of service

https://www.google.com/analytics/terms/us.html
7. Privacy

You will not and will not assist or permit any third party to, pass information to Google that Google could use or recognize as personally identifiable information.

Steps to reproduce
  1. Create a new post on xenforo.com and include your personal E-Mail address in the body of the post
  2. Open network tab in the developer tools/inspector of your browser
  3. Perform a search for that E-Mail address and afterwards check which data does get passed to Google Analytics
Expected Result
The E-Mail-Address does not get send to Google Analytics in compliance with their Terms of Service

Actual Result
The E-Mail-Address does get send to Google Analytics in violation with their Terms of Service
 
Upvote 0
This suggestion has been closed. Votes are no longer accepted.
But we don't do anything... We just include the default tracking code, nothing else. Nothing for us to do here as far as I can tell.
 
Yes you do smth, you do include the tracking code :)

I think it is unreasonable to expect the end user/forum admin to solve this - he most likely can't unless he can write code.

There is probably no 100% solution to this, but I think at least smth. should be done to protect your customers from getting banned by Google (and to comply with GDPR):
If the current route is search and the q parameter contains smth. that looks like an E-Mail, phone or social security number, then block that pageview from being sent to Google Analytics or anonymize the URL before doing so.
 
Last edited:
Ok. We include the code. But what we're not doing is transmitting anything to them. Whatever is happening, it's happening in the normal operation of their code which is something we have zero control over.

Frankly, I'd rather just remove Google Analytics support from the software entirely than have the finger pointed at us every time these types of issues come up.
 
Ok. We include the code. But what we're not doing is transmitting anything to them.
Technically I'd say that you are absolutely right, it's Google code that gets the URL and sends the pageview.

However, from a lawyers point of view it's the website which initiates sending data to Google (by including their tracking code), and the website owner is responsible to comply with Googles terms of service and general laws.
That's also Googles view, they explicity forbid "passing PII" to them.
So it's the responsibility of the website owner to get this right, although he actually does not "pass" anything, he just enters the analytics property into the settings and expects the software to do whatever if is necessary.

Removing Analytics support would of course also be a viable option, yes.

Please don't get me wrong, I am not "pointing fingers" at anyone and I am not relying on XenForo to address all those issues (though it does indeed make my job easier if we don't have to do & maintain such stuff just for our company :)),

I am just pointing to potential issues so those can be addressed (if deemed necessary) for other customers.

I know that this is really annoying, but unfortunately it is like it is :(
 
Last edited:
Removing Analytics support would of course also be a viable option, yes.

As it's (in the end) not the product but the website which needs to comply to the GPDR, I see no benefit in dropping Analytics support. It's not like you'd be forced to use the analytics support, so it's entirely up to you to decide if it's compliant. I'd judge this differently if it was mandatory (like Cookies), but it is not.
 
As it's (in the end) not the product but the website which needs to comply to the GPDR, I see no benefit in dropping Analytics support. It's not like you'd be forced to use the analytics support, so it's entirely up to you to decide if it's compliant. I'd judge this differently if it was mandatory (like Cookies), but it is not.


Its a non-issue though as it requires passing a very specific term to the url to generate something to send to analytics (eg the email).

You dont have to even use a search to do it, just make any old fake url up with an email in it, and it will get passed along as the url gets logged.

www.xenforo.com/community/some/random/stuff/here/look/an/email/xenforo@xenforo.com
 
I see no benefit in dropping Analytics support. It's not like you'd be forced to use the analytics support
The benefit (to XenForo) would be that they would not have to deal with such stupid issues, it would be entirely up to the website owner.
As it is right now, Google is blaming the Webite owner (as this is the entity that agreed to Google ToS), the website owner is blaming XenForo (as he expects XenForo Google Analytics feature to work without further manual adjustment) and XenForo blames Google (as it is effectively their code that generates the data to be sent as pageview).
If XenForo did not have Google Analytics support out of the box, the issue would be only between Google and the website owner.

Its a non-issue though as it requires passing a very specific term to the url to generate something to send to analytics (eg the email).
Yeah, unfortunately it is not a non-issue.

This is a policy breach notice we got from Google in 2015 (it was for AdSense though, but Analytics is the same):
Lieber Publisher,
wir haben festgestellt, dass von Ihrer Website personenbezogene Daten an Google gesendet werden. Die Weitergabe erfolgt über ein von Ihnen verwendetes Google-Werbeprodukt, also AdSense, DoubleClick for Publishers und/oder DoubleClick Ad Exchange.
Über die Anzeigenanfragen, die im Anhang aufgelistet sind, erhalten wir Informationen wie E-Mail-Adressen und/oder Passwörter.

Das Senden von potenziell personenbezogenen Daten ist laut unseren Verträgen und Richtlinien verboten. Ermitteln Sie das Problem, das zu diesem Verstoß geführt hat, so schnell wie möglich und beheben Sie es innerhalb von 30 Tagen.

Gehen Sie wie folgt vor, um das Problem zu beheben:
  • Informieren Sie uns über das Antwortformular über Ihre Fortschritte. Sollten wir innerhalb von 14 Tagen keine Antwort erhalten, werden die Zahlungen für Ihr AdSense- bzw. Ad Exchange-Konto vorübergehend ausgesetzt. Geben Sie die Publisher-ID an, die oben in dieser E-Mail angezeigt wird.
  • Überprüfen Sie zunächst die Anzeigenanfragen, die als Beispiele im Anhang aufgelistet sind.
  • Weitere Tipps finden Sie in der AdSense-Hilfe.
Wir informieren Sie künftig ausschließlich per E-Mail über diese Angelegenheit. In den Anzeigenprodukten werden Sie keine Benachrichtigungen dazu erhalten.

Mit freundlichen Grüßen
Das Google-Team für Publisher-Richtlinien

This was effectively caused by having a link to password recovery in FAQ/Help with preset email@example.com.
 
Yeah, unfortunately it is not a non-issue.

You can't call something an issue when you are intentionally doing something specifically to cause that issue.

We can easily strip out search terms on the search page:

Code:
ga('set', 'location', 'http://example.com/example?a=b');

But then that renders analytics for search terms entirely useless.

But still doesn't fix the issue as I said before, just make any old fake url up with an email in it, and it will get passed along as the url gets logged.

www.xenforo.com/community/some/random/stuff/here/look/an/email/xenforo@xenforo.com

What do you expect us to do in this case?
 
What do you expect us to do in this case?
I don't know :)
And I expect Google doesn't really know either, they simply state that it is not allowed to pass (possibly) PII - problem solved (for them).
How to actually comply with this requirement is left as an exercise to the Google Analytics user.

As stated above, I don't think there is a real solution to this, the only thing that could (and probably should, that's the reaon why I reported it) be done is trying to find workarounds for common usecases like search.
 
Top Bottom