Matomo: Tracking code could use HTTPS when the Piwik server is configured to force SSL connections

[b-pfl]

Dear all,

I just noted that the auto-generate javascript / image tracking code seems to be incomplete for the server URL. The following code is generated and misses the protocol information (e.g., "https:" or http:"
in front of the URL string (e..g, during the definition of "u").

Is there a reason for this?

<!-- Piwik -->
<script type="text/javascript">
  var _paq = _paq || [];
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//<url>";
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', 1]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<noscript><p><img src="//<url>?idsite=1" style="border:0;" alt="" /></p></noscript>
<!-- End Piwik Code -->

[sgiehl]

Sure. This URL is missing the protocol to let the browser decide which
protocol to use, based on the website the tracking code is on.

That way the tracking pixel will always use the same protocol as the
tracked website.

[pebosi]

For more information: https://en.wikipedia.org/wiki/Uniform_resource_locator#Protocol-relative_URLs

[b-pfl]

Thanks for clarification! First it did not work on my site but now it interestingly does.
Is there a chance to define that the autmatically generated script always links to the encrypted page? When I set force_ssl to 1 in config.ini.php requests to the web interface get redirected to https://. However, this does not affect the javascript / image code fragments generated in the backend...

[tsteur]

See #7267 where we talked about a similar thing. We're getting this feedback quite often recently. :+1: for this

[mattab]

I renamed issue in attempt to clarify the scope. I'm not 100% sure that we should make HTTPS tracking the default when force_ssl=1 because it could have some performance implications on Tracking API (for example we use force_ssl but we haven't tested performance implications if suddenly all tracking api requests would use HTTPS)

[tsteur]

I think it is more about what users expect. When I set a force_ssl property to 1, then I would expect it is considered everywhere unless it is named something like force_ssl_in_ui

[tsteur]

Also maybe interesting read The Protocol-relative URL technique is now an anti-pattern

[mattab]

in the forums, a user expected force_ssl to also force SSL connection to Tracking API on his websites: http://forum.piwik.org/read.php?2,126694

[Globulopolis]

Provide to separate options to forse_ssl. First for UI(i mean when the user login into piwik admin page), second for tracker.

[mattab]

As part of this issue we should also check this FAQ:
http://piwik.org/faq/how-to/faq_91/#comments

This was reported in feedback:

Comment: I think this information is a bit misleading. I worried that setting force_ssl would also force redirects for the requests made by the tracking code. That's not what I want, because we're using a self signed certificate at the moment.
However turns out that's not the case.
The documentation here suggests ALL requests are redirected.

[mattab]

See also: Google Analytics uses HSTS - maybe we could send this response header HSTS? https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

[Findus23]

In my opinion this is quite important.
My example use case: I am hosting a website on a cheap shared hosting (so no https possible), but piwik is on an own server (so only https, force_ssl=1 and all http requests are redirected to https)
But with the default (//-URL) all visitor data is transmitted unencrypted and (because of the redirect) again via https.

As a result

• everything is transmitted twice
• SSL is useless as everyone can intercept the first unencrypted request

HSTS would solve this (at least after the first request), but it also should work without it.

[tsteur]

@Findus23 I have just updated https://plugins.piwik.org/ForceSSL to also force SSL in generated tracking code.

[Findus23]

@tsteur That's great.

Maybe also suggest enabling force_ssl=1 and the ForceSSL while installing if the site is using HTTPS.

[tsteur]

The plugin sets "force_ssl" automatically

[Findus23]

@tsteur, I am still not sure if adding this feature to a plugin that only few people will use, solves this issue.

Because of this the majority of users will still send the private data of their users over unencrypted HTTP even though their Piwik-Server supports SSL and as a result they think "everything is secure" even though it isn't. (And I think the the use case of having piwik on a modern server with an SSL cert, but tracking an old legacy website, which only runs via HTTP, is quite common)

It shouldn't matter how the website is delivered, the tracking data should always be sent via the most secure way possible.

[tsteur]

See https://github.com/piwik/piwik/issues/7366#issuecomment-77496199 it should be still forced in Piwik as well eventually IMO.

[Findus23]

@tsteur, what comment do you mean? The link just links to this issue.

[tsteur]

That's funny, link seems to not work. Meant my second comment.

[mattab]

Solving this issue will actually solve real bugs, so increasing priority.
eg. some servers are setup to redirect all requests from HTTP to HTTPS (even the piwik.php tracking api request). this can cause errors like Failed to load http://look.anixa.tv/piwik.php: Redirect from 'http://look.anixa.tv/piwik.php' to 'https://X/piwik.php' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://Y' is therefore not allowed access. and in some cases, this causes the session recording and possible other features to fail.

[mattab]

This issue is only about changing var u="//<url>"; to var u="https://<url>"; in the JS tracking code when force_ssl is enabled

[Findus23]

In my opinion this change is required regarding GDPR as we can't protect user data data properly if we don't even know who read it before it hit the Matomo server.

I would even go as far and send a reminder to users to update their old tracking codes.