As far as I'm aware of every cookie that can be httponly is httponly. Can you show one that is not that way?

What do you refer to here @neunzehnachtneun ? To the JS tracker? In JS you cannot set a cookie as httponly

Thank you for answering! Yes, I refer to the JS-Tracker and, yes, you are totally right. I read a bit about javascript and cookies and it's totally useless to set the cookie header to httponly.

But also I read about the cookie header 'samesite=strict', which is possible to use with javascript and which I would like to use with matomo. What do you think about that?

While using samesite you need to really take care of your cookie domain or you will run into a hell of a lot of trouble. This is especially important if you use a reverse proxy.

(This does not mean I'm against it, but it might be a breaking change for some people.)

You would also need to have matomo running on the very same domain? not even a subdomain? or would a subdomain still work?

samesite is a origin related setting and should be used with caution. it would have effects on the tracked data and most certainly break the 3rd party cookie in in many use cases

Seems like this is becoming far more important: Chrome is planning to make all cookies that don't have an explicit SameSite option have SameSite=Lax by default. At the moment it is an optional flag (#same-site-by-default-cookies), but chrome 80 (release in the beginning of January 2020) will have it enabled by default.
https://www.chromestatus.com/feature/5088147346030592

(Disclaimer: I haven't fully understood the topic and the explanations are all a bit vague, so this might be incorrect)
This means that if your Matomo is on matomo.someagency.example any request that isn't from the same site (so someagency.example or www.someagency.example) won't recieve any cookies. If you have Matomo installed on the same "site" as the website you are tracking (so a subdomain or subdirectory) nothing should really change.
But in every other change this will break some things. One I noticed that is especially critical is the opt-out iframe. I guess the same will also happen for widgets without token_auth.

Simply updating all cookies to add a SameSite=None flag won't help much as on one hand SameSite is a useful security feature as it makes CSRF attacks far harder and on the other hand there is a bug in all current Safari versions (iOS and MacOS) that causes them to interpret SameSite=None as SameSite=Strict which will break even more things.

Another related change is that starting in chrome 80 all cookies with SameSite=None and without the secure flag will be rejected completly. (https://www.chromestatus.com/feature/5633521622188032) So Matomo instances without HTTPS (I hope there are hardly any left) might have even more problems if we try SameSite=None.

More Details:
https://web.dev/samesite-cookies-explained

When talking about the third party cookie (_pk_uid) and the opt out cookie, I guess the best setting for all setups with Matomo on its own (sub)domain is SameSite=None + secure. The Safari/iOS fix for SameSite=None will not be backported to iOS <13, so we should not write the SameSite attribute for ios and macos until most users are on a fixed version. This would mean that the third party feature and the opt-out iframe feature will require https. Which should not be an issue in 2019. If its possible an alternative solution for the opt out cookie on http should be implemented.

We could possibly also detect some browsers and send different headers for them? But of course be hard to test and maintain it all etc. Might be worth for some very popular browsers/versions.

Data from 20.09.2019 (https://david-smith.org/iosversionstats/)

Proposed values for the SameSite flag:

SameSite=None (but not for iOS or Safari on macOS):

• Opt-Out IgnoreCookie (piwik_ignore)
• 3rd Party Cookie (_pk_uid)

SameSite=Lax

• PHP Session Cookie (MATOMO_SESSID) -> requires PHP >= 7.3: session.cookie_samesite=Lax
• Language Manager Cookie (matomo_lang)

Proposed values for the secure flag:

• set if Matomo runs on https
• not set if Matomo runs on http (maybe add some warning, that it will not work with Chrome >=80?)

@MichaelHeerklotz
Both sound good to me and are about what I would have suggested.
But this also means that we would need to make it very explicit that using Matomo without HTTPS means:

• that features are broken
• that it is highly likely that you are in violation of privacy laws.

it would be great to fix this in the next minor release eg. 3.12.1 as we're starting to get reports that people see a a warning in their Chrome developer console:

A cookie associated with a cross-site resource at https://x.matomo.cloud/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032"

Not sure if this issue is maybe related? #15083

@tsteur I doubt this as #15083 also is reported in non-chrome browsers and I doubt many people are using Chrome Dev or Canary (two releases after the current one) which I think is the first one with this change.

Simply here to comfirm @MichaelHeerklotz proposition for default as value as they are in accordance with Chrome DevTools warning: "A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure"

This still seems to be an issue, unless I have misunderstood something. Getting

A cookie associated with a cross-site resource at http://xxx.matomo.cloud/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure.

Could you advise on how best to proceed?

@jackherizsmith can you maybe share with us on which page this is happening? Feel free to email us at support@matomo.cloud