@mikkeschiren opened this Issue on February 19th 2020

I think that setSecureCookie should be set to true as a default, not an option. From my point of view, serving Matomo over https should be expected - not http. An therefor it should make sense to have setSecureCookie=true as default, and if it should not be set to true, that should be the option, that makes setting up tracking much simpler for the end user, from my perspective.

So this should be the override:

_paq.push(['setSecureCookie', false]);

@sgiehl commented on February 19th 2020 Member

Thanks for your suggestion. Guess might make sense to expect secure cookies by default.
Might be something we could evaluate for Matomo 4. It kind of breaks BC, as the tracking code needs to be adjusted for HTTP sites

@Findus23 commented on February 19th 2020 Member

I think this might be even worth breaking BC for as the alternative is having everyone using HTTPS (which should be far more people than those that don't) edit their tracking code.

@tsteur commented on February 19th 2020 Member

We had this topic few days ago in slack. Problem is when your site is not fully https, and eg some pages are http and some are https then you end up with different cookies and different visitor IDs etc.

Many people are still using http, and for example have a login on https etc. Seeing this sometimes while investigating issues. Of course they could then just remove the line from the suggested tracking code. Would need to make sure the default tracking code we suggest has a comment next to it explaining things and explains when to remove it etc.

serving Matomo over https should be expected -

In this case it's the user website that matters as we are setting a first party cookie unless I'm not seeing it?

@sgiehl commented on February 19th 2020 Member

Assuming we make secure cookies the default setting, we could extend the tracking code generator with an additional option My site is served https only, which is checked by default. And when you uncheck it the _paq.push(['setSecureCookie', false]); is added?

@tsteur commented on December 21st 2020 Member

BTW we should maybe rather make such a change as part of Matomo 5. Because when you change this, it can cause issues when users have HTTPS and HTTP traffic as it would create different visitors depending on protocol.

Not sure what the benefit is though. If someone only uses HTTPS (which many sites do), then this should basically not even be needed to be called as there wouldn't be much of a benefit?

@tsteur commented on July 27th 2021 Member

The idea could be that we add the paq push call to the default generated tracking code instead of changing the default value in matomo.js.

This way it is a bit more likely that users will figure out why they have double visits etc.

And it's very quick to implement.

And we don't break as many installs as it would be mostly behaviour for new installs (unless someone uses the API to get the tracking code which many do)

Problem: It would currently log Error in setSecureCookie: You cannot useSecureon http. when someone is using HTTP on their site. This will create confusion, bug reports, support requests, ... We should remove this log message in that case.

@tsteur commented on May 10th 2022 Member

@Findus23 @mikkeschiren @sgiehl can someone help me what the benefit of setting the secure cookie is when the site is only served in HTTPS anyway? In that case it wouldn't be sent over HTTP anyway?

And when someone is using HTTP and HTTPS then it wouldn't be in the interest of the user to enable secureCookie as it will generate different visitor IDs on the different protocols and cause wrong numbers.

@Findus23 commented on May 10th 2022 Member

@Findus23 @mikkeschiren @sgiehl can someone help me what the benefit of setting the secure cookie is when the site is only served in HTTPS anyway? In that case it wouldn't be sent over HTTP anyway?

That's only true if HSTS is enabled (which I assume is not true for the majority of Matomo sites). Otherwise, I think there is nothing stopping an attacker from serving the site via HTTP and linking the user to it (by MITM-ing their connection).

@tsteur commented on May 10th 2022 Member

FYI It's currently active on 24% of sites https://w3techs.com/technologies/details/ce-hsts

And I believe if you are already browsing a site on HTTPS, then a browser wouldn't the HTTP request? I just tested this on my site and the browser would block the request.

Powered by GitHub Issue Mirror