Browser Do-not-track kills active Opt-out ability

Support & Bugs
1

These are our settings

  • “do-not-track” is NOT enabled within configuration of the Matomo Tag Manager
  • The Opt-out-iframe from the general settings in privacy > opt-out is displayed on our website.

Unfortunately there ist a bug in the implementation of the opt-out:

  • it does check weather the browser sends “do-not-track” and in that case changes the information given and removes the ability to opt-out:
    • "Das Tracking ist bei Ihnen derzeit nicht aktiv, denn Ihr Browser hat uns mitgeteilt, dass Sie kein Tracking wünschen. Hierbei handelt es sich um eine Browsereinstellung. Um das Tracking wieder zu aktivieren, müssen Sie die sogenannte “Do Not Track”-Einstellung in Ihren Browsereinstellungen deaktivieren. "
  • but it does not know, that “do-not-track” is not enabled within Matomo (Tag Manager)

So these users can never opt-out and are always tracked.
Privacy wise really bad.

I don’t know, if this is maybe only since we implemented the Tag Manager.

Any help is appreciated

2

Hi,

If I understand your question correctly this is something worth testing:

So I opened that opt-out iFrame and it showed

Das Tracking ist bei Ihnen derzeit nicht aktiv, denn Ihr Browser hat uns mitgeteilt, dass Sie kein Tracking wünschen. Hierbei handelt es sich um eine Browsereinstellung. Um das Tracking wieder zu aktivieren, müssen Sie die sogenannte “Do Not Track”-Einstellung in Ihren Browsereinstellungen deaktivieren.

just as it should.

Then I went to the DNT settings in Matomo and set it to Do-not-Track Unterstützung deaktivieren.
I reloaded the opt-out iFrame and it showed me the possibility to opt-out as the iFrame knows the global Matomo settings.

But I think I know the reason for the misunderstanding: The “Do-Not-Track” setting in Tag Manager is not really explained properly. It doesn’t control if the Matomo server respects DNT (that is still the global setting in the Admin-Page), it just adds _paq.push(["setDoNotTrack", true]); to the tracking code. This setting runs in the tracking code and detects via JS if DNT is enabled. If it is, it won’t even send any data to Matomo. If it isn’t (or you didn’t enable the setDoNotTrack or Tag Manager setting) it will send the tracking data to Matomo, but if DNT in Matomo is enabled it will not record it.

I hope this clears everything up a bit.
I created an issue in https://github.com/matomo-org/tag-manager/issues/225 to clear this up in the description text.

3

Hello Lukas,

ok, I did not know about the admin do-not-track-settings.
But i am still confused.

These are (and were) our current settings:

  • Activated in admin section
  • deactivated in Tag Manager
    -> leads to above mentioned contradictory behaviour
  • no opt-out possible
  • but user does gets tracked

Since we use anonymization, self hosted Piwik etc. and therefore decide to ignore browser implemented do-not-track, we should

  • deactivate in admin settings
  • but what do we have to to in order to respect the opt-out-iframe setting?
    • activate in tag manager?
    • or keep deactivated in tag manager

Thank you for clarification

4

Are you really sure the user gets tracked?

If you have activated it in the admin section then no request with the DNT header will be stored in the database
(You can confirm this using https://developer.matomo.org/api-reference/tracking-api#debugging-the-tracker)

If you want to ignore the DNT header, then disable it in both places. The opt-out cookie will be respected always independent of these settings.

5

Absolutely. I detected the problem while viewing a session recording of a user who came across the opt-out-iframe which displayed that his/her visit would not be tracked!
As I mentioned earlier, this may be related to the tracking via tag manager.

Thanks, this is what we will do.

6

I am not 100% sure, but I think session-recording can’t record the contents of happen inside an iFrame, but just the URL. So when watching the session recording it might be that you are watching the content of the iFrame for your browser (which potentially has DNT enabled).

7

If true, then this could explain it. But it was a recoording of a larger scree, whre the iframe took up only a part of the screen. Unfortunately I deleted this recording already.

I have not yet had the time and setup to test all use cases (which would also help …)