@sammacbeth opened this Issue on February 6th 2018

When using the form to opt-out of tracking (tested on https://matomo.org/privacy-policy/):

screen shot 2018-02-06 at 17 25 21

Expected behaviour

The PIWIK_SESSID cookie is removed from my browser.

Actual behaviour

The PIWIK_SESSID cookie remains with its previous value.


We have tested this on our own install and the opt out mechanism works, in the fact that this user's sessions do not appear in the dashboard. However, there are two primary concerns:

  1. If the cookie remains, there is no guarantee tracking will not continue - one must trust that the server side is honoring the piwik_ignore cookie. The Privacy by Design approach would be to unset the session cookie, then every user can be sure that the identifier is no longer present.
  2. From a compliance perspective (considering upcoming GDPR and ePrivacy regulations), if a user has explicitly opted-out of tracking, yet the identifier is still being sent by the client, I must be able to be 100% sure that this identifier is not being stored somewhere. On our installation I could see that a session ID for a user who was opted out from the start is still stored in the database. How can I verify that there are no other traces of this user in the database which could lead this to violate GDPR? Similarly any logs upstream on the webserver may need to be purged of this identifier.

Therefore, it would be preferable if the server would remove/reset the PIWIK_SESSID cookie on opt-out, and enforce that this cookie does not persist. This would meet the goal on both sides: that the user can trust the opt-out mechanism, and that the administrator can prove compliance with user consent.

@sgiehl commented on February 6th 2018 Member

Why should the PIWIK_SESSID cookie be removed when you choose to opt out?
The PIWIK_SESSID cookie is set when you log into Piwik, so it's the session cookie for Piwik users, not for people getting tracked. I don't think it make sense to log someone out of Piwik if he choose to opt out.

@fdellwing commented on February 7th 2018 Contributor

I would hate to be logged out of piwik everytime I visit one of our sites where I opted out.

@sammacbeth commented on February 7th 2018

Ok, so it seems I mixed up the purposes of the different cookies set, I simply assumed that PIWIK_SESSID was the tracking cookie because it was set for me. This actually uncovers a second issue that when visiting a page containing the opt out frame I am given a PIWIK_SESSID cookie. With a clean profile, when visiting https://matomo.org/privacy-policy/ I get this cookie, despite not being an administrator of this matomo instance. This session ID is sent with all subsequent requests in the session.

The original issue is still valid, but the cookie which should be unset is the tracking cookie, which appears to be _pk_id.1.f3f2 for demo.matomo.org.

To summarise, the two issues are:

  1. Visiting the privacy policy page sets a PIWIK_SESSID cookie for normal users.
  2. Opting out of tracking does not unset the tracking cookie (e.g. _pk_id.1.f3f2), which remains and will not expire for over a year.
@sgiehl commented on February 7th 2018 Member

1.) You're right. Seems Matomos opt out page sends a session cookie. Which should definitely be unneeded.
2.) Right. The cookie isn't removed. Need to check why this is the case, but don't think the cookie should be needed for anything after opting out.

@Mark-Reiser commented on May 18th 2018

Obviously, the problem still exists on version 3.5.0.

I would feel better when this "bug" was fix until the DSGVO comes...

Is there any news about that case?

@sgiehl commented on May 18th 2018 Member

I've checked the opt out frame again. And the session cookie is needed indeed. The form currently includes a CSRF protection nonce, which requires a short time session storage. Nothing else should be stored in the session unless someone was logged in Matomo before.

@Findus23 commented on June 5th 2018 Member
@mattab commented on November 6th 2018 Member

We got a security report (see below) that maybe the Opt-out is not fully protected by a CSRK nonce token?

CSRF user can be opted-in or opted-out using index.php?module=CoreAdminHome&action=optOut&language=en&setCookieInNewWindow=1

so we should ideally ensure that the opt-out / opt-in cannot be vulnerable to CSRF.
Then we could close this issue.

@mattab commented on March 20th 2019 Member

The scope of this issue is simply to verify and confirm that the opt-out / opt-in isn't vulnerable to CSRF.

This Issue was closed on May 3rd 2019
Powered by GitHub Issue Mirror