@imrejonk opened this Issue on April 22nd 2020

Hi,

We recently installed Matomo 3.13.4 and included the tracking code in the <head> section of our website. We generated the tracking code with the option 'Track users with JavaScript disabled' checked.

While tracking visitors with JavaScript enabled works perfectly, it looks like visitors without JavaScript are not tracked at all.

How to reproduce:

  1. On Firefox, make sure that DNT header is not sent and Matomo is not blocked in any way.
  2. Disable JavaScript by setting the javascript:enabled config flag to False.
  3. Click around on the website. Verify that the image beacon gets loaded correctly.
  4. Try to find the visit in Matomo.

Expected result:

The webmaster should be able to find the visit in the Matomo web interface, or at least in the database.

Actual result:

The visit can neither be found in the Matomo web interface nor in the database.

@sgiehl commented on April 22nd 2020 Member

In general that should work. Might it be possible that the browser does not request the tracking image as it's placed in <head>. Would you mind checking if moving the <noscript> part to <body> works?

@imrejonk commented on April 22nd 2020

Hi @sgiehl, thanks for the quick reply. Moving the <noscript> part to <body> had no effect, but we managed to find the cause of our troubles after some more debugging.

Background: our referrer-policy header (as sent by our webserver) was set to same-origin. This is a security feature that prevents browsers from sending referrer information to other origins. We additionally configured Matomo to only track requests from www.ciphermail.com and www.staging.ciphermail.com.

Cause: because our Matomo installation is hosted at matomo.ciphermail.com, a different origin than our website, browsers that support the referrer-policy tag (including Firefox) were not sending Referer: [sic] headers to Matomo. Matomo, being configured to only track requests from the domain names listed above, dismissed the image beacons. I consider this correct behaviour.

Solution: we wanted to keep the benefits of the security provided by the strict referrer-policy header, but still allow Matomo to obtain the full referrer information including path and query string. We achieved this by adding this HTML parameter to the <img> tag of the image beacon: referrerpolicy="no-referrer-when-downgrade". This ensures that browsers which support this tag send full referrer information to Matomo, provided that the connection would not be 'downgraded' from a HTTPS website to an HTTP Matomo installation.

Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Integration_with_HTML

It might be a good idea to add this HTML tag to the <img> part of the Matomo image beacon tracking code. I leave it up to you to decide whether to follow up on this suggestion, and subsequently closing this issue.

Update: we're changing our referrer-policy to strict-origin-when-cross-origin. This has nothing to do with this issue per se, we were just rethinking our use of the header while we were on the subject.

@sgiehl commented on April 22nd 2020 Member

Ah ok. That makes sense. I'm not very deep into that referrer policy stuff right now, but I guess it would make sense to add that to the generated tracking code.
Or might it make sense to have that configurable in any way? ping @Findus23 @tsteur

@tsteur commented on April 22nd 2020 Member

We achieved this by adding this HTML parameter to the tag of the image beacon: referrerpolicy="no-referrer-when-downgrade"

Adding referrerpolicy="no-referrer-when-downgrade" to the default img tracking code in the tracking code generator sounds good to me. Reading the docs again it shouldn't make anything worse. We'll also need to check the docs on developer website if there's any mention of this and just the tracking code if needed (and I can also change it in Matomo for WordPress).

Might not be highest priority since most users would have JavaScript enabled and it's a bit of an edge case but I can see some websites would have this issue and would save them a lot of time debugging this issue.

I'll move this for now into the RC phase should we have time left there. Otherwise we might have to move this into a later milestone.

@Findus23 commented on April 23rd 2020 Member

Just FYI no-referrer-when-downgrade is the default when no referrerpolicy is set and how browsers worked before referrerpolicy existed.
And I'm not sure, but wouldn't one need to modify the referrerpolicy of the tracked site to change the referrer sent to the image? So there is nothing really to do for Matomo (apart from documenting this) as it is working (or rather not working) as intended.

@imrejonk commented on April 23rd 2020

@Findus23 adding referrerpolicy="no-referrer-when-downgrade" to the <img> tag of the beacon image overrides the referrer policy on the matomo.php request as set by the webserver (through the referrer-policy: header). Or at least, that is how it works in Firefox and Chromium, I haven't tested this with other browsers.

In other words, adding referrerpolicy="no-referrer-when-downgrade" to the <img> tag saves webmasters who have configured a strict referrer policy on their website a debugging headache :)

@Findus23 commented on April 23rd 2020 Member

Ah, I thought you were talking of the HTTP header and didn't think of the fact that one can also add it to img tags.

This Issue was closed on July 23rd 2020
Powered by GitHub Issue Mirror