RFC: Improving Mautic's GDPR Compliance - Cookie Management

Ideas and Feature Requests
1

Introduction

In light of the General Data Protection Regulation (GDPR) and ePrivacy requirements, I believe it is essential for Mautic to enhance its compliance by addressing certain issues related to cookie management. Therefore, I created this Request for Comments (RFC). I’m hoping we could lay out some procedures to enhance Mautics GDPR and ePrivacy compliance while maintaining its analytic features for the Mautic devs. I outlined some key problems and potential solutions.

Discussed Topics

  • Problem 1: Cookies Are Being Set for Users with DNC Flag
  • Problem 2: Forwarded Emails Result in Cookies Set for Non-opted-in Persons
  • Problem 3: Focus Items Set Cookies Without Consent
  • Problem 4: mtracking.gif Set Cookies Without Consent
  • Problem 5: Mautic Form Submussions Set Cookies Without Asking for Consent
  • Problem 6: Removal of Unused Cookies
  • General Solution: Adopting a Similar Approach as Matomo

Problem 1: Cookies Are Being Set for Users with DNC Flag

Description

When users opt out of receiving emails, they are assigned a DNC (Do Not Contact) flag. As per GDPR/ePrivacy guidelines, opting out implies that users have revoked consent for tracking and cookies. However, Mautic currently sets cookies for every link click, even for users with a DNC flag.

Proposed Solution

Mautic should check if a user has a DNC flag before setting cookies via server-side code. Moreover, the unsubscribe link resolution and page should never set cookies.

Steps to verify

  • Create a new contact
  • Send a test email with a link to a blank page, i.e. not including any of Mautic’s JS, and a unsubscribe link
  • Open the regular link in an incognito browser tab.
    • Mautic sets five first party cookies:
      • mautic_device_id
      • mtc_id
      • mautic_referer_id
      • mtc_sid
    • This is fine if the user gave consent to setting cookies.
  • Clear/delete the cookies
  • Now, open the unsubscribe link
    • You’ll see the standard We are sorry to see you go! e@mail.com will no longer receive emails from us. If this was by mistake, click here to re-subscribe.
    • Mautic sets three first party cookies:
      • mautic_device_id
      • mtc_id
      • mtc_sid
    • This is bad: These cookies are neither technically necessary nor do we have the user’s consent to setting these cookies.
  • Clear/delete the cookies
  • Now, open the regular page link once again in an incognito browser tab.
    • Mautic (again) sets five first party cookies:
      • mautic_device_id
      • mtc_id
      • mautic_referer_id
      • mtc_sid
    • This is bad: These cookies are neither technically necessary nor do we have the user’s consent to setting these cookies. Even worse: The user has previously explicitly withdrawn the consent for tracking and setting cookies.

Discussion

Should we mix DNC and Do not Track? My point of view is, that this isn’t a matter of preference. If a user opted out of communication this has to be seen as withdrawing consent to tracking, too.

From a legal standpoint you’d have to acknowledge that tracking is more invasive as communicating. So, if a user says no to emails they are saying no to tracking even more.

We could combine differing point of views here with a setting switch.

Problem 2: Forwarded Emails Result in Cookies Set for Non-opted-in Persons

Description

When an opted-in contact forwards an email to someone who is not an identified contact and has not opted in for tracking or receiving cookies, Mautic still sets cookies if the recipient clicks on a link in the forwarded email. This is not GDPR/ePrivacy compliant.

Proposed Solution

See General Solution.

  • Don’t set cookies server side, unless we know that the user has opted it
  • We would/could still track the link click server-side
    • This is also fine from a GDPR/ePrivacy point of view, as the link click is attributed to the already identified user (who consented). Therefore, the unidentified users data isn’t processed without consent

Problem 3: Focus Items Set Cookies Without Consent

Description

Mautic’s focus items currently set cookies without asking for user consent. When a focus item is added, it loads //mautic.yoursite.com/focus/1/viewpixel.gif, which sets three cookies without checking for prior consent:

  • mautic_device_id
  • mtc_id
  • mtc_sid

The main problem is: You could use the focus item without any tracking or cookies, but you don’t have any chance doing this. Hence, if you have a user who refuses to consent to your Mautic cookies you aren’t allowed to show him focus items.

As Mautic loads the viewpixel.gif within an IFRAME you can’t block the creation via JS. (At least I don’t know a way of doing this).

Possible Solutions

  1. Count the view server-side without creating cookies. While this would prevent the creation of a new contact, it would be GDPR/ePrivacy compliant.
  2. Create a second viewpixel.gif called viewpixel-nocookie.gif:
    • viewpixel.gif works as it currently does.
    • viewpixel-nocookie.gif tracks the focus item view but doesn’t set cookies.
    • This could achieved using an internal switch, too, instead of using to URLs or gifs.
  3. Enhance viewpixel.gif and set cookies based on an internal server side switch (see General Solution)

The first party cookie mautic_focus_{n} isn’t part of the problem as it is not used for tracking or the like. I’d argue it is a functional cookie and might not need consent. You can set it based on legitimate interests. This won’t mess with the How often to engange setting.

Problem 4: mtracking.gif Set Cookies Without Consent

Description

If you load http://mautic.yoursite.com/mtracking.gif, the tracking gif currently sets cookies without asking for user consent prior to that. It sets four cookies without checking for prior consent:

  • mautic_device_id
  • mautic_referer_id
  • mtc_id
  • mtc_sid

Possible Solutions

  1. Count the view server-side without creating cookies. While this would prevent the creation of a new contact, it would be GDPR/ePrivacy compliant.
  2. Create a second mtracking.gif called mtracking-nocookie.gif:
    • mtracking.gif works as it currently does.
    • mtracking-nocookie.gif tracks the focus item view but doesn’t set cookies.
  3. Enhance mtracking.gif and set cookies based on an internal server side switch (see General Solution)

You could use a consent management tool for mtracking.gif, but you’d lose all tracking capabilities. I’d rather have an anonymous count instead of no tracking at all.

Problem 5: Mautic Form Submussions Set Cookies Without Asking for Consent

Description

If a user submits a Mautic form the submission leads to four cookies being set:

  • mautic_device_id
  • mtc_id
  • mtc_sid

This might not be a problem at all. You could simply ask for consent.
Asking for consent isn’t a problem if your form is for, e.g., newsletter subscriptions.

Aksing for consent is a problem if your form is a simple contact form or something similar. Such a form shouldn’t create tracking cookies. Asking for consent to tracking to simply send a form might reduce form submissions also might be seen negatively by users.

Additionally, I guess many Mautic user aren’t aware that these cookies are set. So, all Mautic user who need to comply with GDPR (which are probbably a lot, given the very broad applicability of the GDPR) are at risk of violating it.

This can be mitigated by turning kiosk mode on, but this is “global” for a form. We lose all tracking capabilities at once by turning it on.

It would be nicer to be able to load a form using something like

<script type="text/javascript" src="//mautic.yoursite.com/form/generate.js?id=1&kiosk=true"></script>

This would enable us to set cookies based on user consent dynamically. Additionally or alternatively (or even better?), we could implement a form element where the user can explicitly consent into tracking/setting the cookies.

Solution

Form should have switch (e.g. setCookieOnSubmission). If toggled, Mautic set the cookies after a form submission, if not then not. This would solve the need to ask for consent on every form.

Additionally, see General Solution.

Problem 6: Removal of Unused Cookies

Description

Mautic currently sets some deprecated/obsolete cookies, such as mtc_sid and mtc_id. Removing these cookies would enhance GDPR/ePrivacy compliance by simplifying Mautic’s tracking and making it easier to understand.

Proposed Solution

Identify and remove any deprecated or obsolete cookies from Mautic’s cookie management process.

General Solution: Adopting a Similar Approach as Matomo

Mautic could leverage a similar approach to cookies as Matomo. This would involve the following steps:

  1. Implement a new Mautic configuration setting: Enable cookieless Mautic. If set to true, the tracking scripts would not create the mtc/mautic_ cookies.
  2. Amend the Mautic tracking script mtc.js to allow something like this:
<script>
    (function(w,d,t,u,n,a,m){w['MauticTrackingObject']=n;
        w[n]=w[n]||function(){(w[n].q=w[n].q||[]).push(arguments)},a=d.createElement(t),
        m=d.getElementsByTagName(t)[0];a.async=1;a.src=u;m.parentNode.insertBefore(a,m)
    })(window,document,'script','http(s)://yourmautic.com/mtc.js','mt');

    mt('send', 'pageview');
    // the user consented to cookies
    mt('send', 'setCookieConsentGiven'); // this will set a mautic_consent cookie and the regular mtc/mautic cookies
</script>
  1. Modify the server-side application to check for the mautic_consent cookie. If set, the server would set/update the tracking cookies. This could work for:
    • redirecting users after a click on a link in an email (solve Problem 2).
    • loading the focus item’s viewpixel.gif (solve Problem 3)
    • loading the fallback mtracking.gif (solve Problem 4)

Request for Comments

I’d like to encourage you to share your thoughts and suggestions on these issues and proposed solutions. Your input could help improving Mautic’s GDPR compliance and ensure a more privacy-conscious user experience.

PS: I guess, gated videos will cause the same issues, but I didn’t test it, as I don’t use these as of now.

4 Likes
2

Thank you Peter for bringing this up and for making actionionable suggestions for solutions.

I’m not a lawyer, but from my modest knowledge of the GDPR, these are all valid points that should be discussed and likely implemented. At first glance, the proposed changes seem convincing and reasonable to me.

1 Like
3

Well, the problem is not only the cookie but that Mautic is tracking the activity of a user in order to serve him individualized content. This is exactly the activity that GDPR is trying to suppress. That means, your website needs to have a cookie banner that explains exactly what you do and only after the consent of the user are you allowed to load the tracking script. Before the consent, you need to suppress not only cookies, but any kind of tracking activity and you are not even allowed to load the script. Now the implementation of the cookie banner needs to be on the website, which might be already beyond the scope of Mautic. But anyways, the discussion is really valuable, and some tools may be implemented in Mautic to facilitate that options.

4

Thanks for your input. I’d like to disagree, though. You can track certain things, like page views or how often a focus item was shown, if the data is not tied to a user. Not tied as in not tied at all—and not just in “tied pseudonymous”.

Just think of Matomo. You can set it up in a way that you can track your page (almost) just like before, but without needing a cookie or even a consent banner. The trick is that no data is tied to any user. The only thing that gets saved is some sort of session identifier. That way consecutive page views can be tracked. But that’s it. At the next day (or, actually, as soon as the user closes the browser) the same user is treated as a new/unidentified person. The only thing you lose: Unique visitors/page views and (of course) long term tracking of interaction, etc.

Mautic could achieve the same. The problem is: Almost all scripts simply set cookies without a possibility to intervene. Forms* could work without a cookie by default, focus items, too. Maybe even DWC. Even mtc.js could work the same way as Matomo. The only drawback: You’d have a lot more anonymous contacts.

If a user becomes a contact/lead they usually consent to some sort of tracking. After that, none of the above is a problem anymore—until they revoke their consent.

* You could leverage the kiosk mode for forms, but that is a tad too inflexible, since you can ask for consent before sending the form—and miss an opportunity using kiosk mode.

I even guess, that by suppressing cookies Mautic would instantaneously become GDPR-compliant as no data is tied to a person anymore. And that without changing much of the code base or losing much if its tracking capabilities regarding contacts (who consented and get cookies just like as it is now).

Yeah, the implementation of consent and cookie management is beyond the scope of Mautic. But, currently, Mautic has no ability to react to user’s consent management settings.

That is what this RFC is for.

5

Yes right, you could track page views without linking that to a user, but Matomo does that already very well. But the focus of Mautic is not to provide statistics, but rather to track the user activity to create an individualized experience. Unfortunately this can be done in GDPR only with expressive consent.

Yes, the cookie on the forms can be a problem, since the user can be identified on any returning form. Mautic does that to be able to provide default data of fields that a user has filled out already in the past. Just it is probably hard to justify that cookie under GDPR before asking for consent.

Focus items I guess have the purpose to provide individualized output for the user. Would be nice though to have there a default option for users who did not agree to a tracking cookie.

Now your assumption that an opt in lead has given consent to tracking is not quite correct. What I know a tracking consent cannot be linked to the opt in. So there would be a need for a checkbox where the prospect is actually giving expressive permission to be tracked. If he doesn´t check it, you still sign him up to the email list but you do not track his website activities.

There are some intricacies in GDPR and I have the impression that most Mautic users still ignore that GDPR is around. There would be actually a need to discuss what would be best practices to operate Mautic GDPR compliant. And yes, some tools in Mautic to simplify this process would be very much welcome.

6

Has any work towards this been done so far?

Are there any articles on how users have been able to use external scripts or such to suppress or alter cookie creation in for example wordpress?

7

This is serious… I have a custom website and just want to respect my users privacy and obey the law, which means I can’t even load the giant legacy blob of untyped javascript that is mt.js (which get’s blocked by adblockers anyways and really should just be an installable npm package with types so it’s usable in a sane and reliable way).

I would greatly appreciate some kind of update on this.

Please take a look at the way facebook’s pixel api handles this:

import type { fbq } from '@types/facebook-pixel'
!(function (f, b, e, v, n, t, s) { //... etc

// GDPR compliance: https://developers.facebook.com/docs/meta-pixel/implementation/gdpr
fbq('consent', 'revoke');

// Enable limited data processing mode.
// https://developers.facebook.com/docs/meta-pixel/implementation/data-processing-options
fbq('dataProcessingOptions', ['LDU'], 0, 0);

// Now it's safe to init.
fbq('init', ID);
fbq('track', 'PageView');

// Later, after consent banner is accepted:
fpq('consent', 'grant') // Now cookies/beacons/trackers are enabled.
8

You can suppress cookies if you do not use the Mautic plugin in wordpress, do not put any tracking scripts and use native Wordpress forms instead of Mautic forms for sign ups.

9

“Kiosk Mode” with Mautic Forms should also be fine for forms.
However there is also asset downloads that place cookies. We are currently working on a paper, collecting all issues to discuss it with development.

10

(C/W)ould post a link to this paper?

If it is a google doc, you could enable commenting, so that others could make suggestions. Might make the creation easier and helps to collect everything.

1 Like
11

the problem is not the cookie per se, but the tracking of user activity that you do with that. Actually, even placing a tracking pixel to determine open rate or use a tracking link, you need permission for that. So you either ask for permission at the moment of signup, or you need to disable those features. I guess there is a need of a wholistic analysis of the GDPR issue and how to treat it in a proper way.

12

I know, currently the hard coded cookie in some occasions is more difficult to prevent that making sure not to track some stuff (even possible with some automated routines) - but if the cookie is set its set.

Especially asset download links and landing pages set them no matter what. There is currently no option to disable through backend.

@peter_k yes I will do, happy to share some of the work…

13

This is the current document:

@luckow is there a way to discuss at the document before editing it?