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

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.

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?

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?

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?

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 use Secure on 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.

@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 @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).

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.