Mautic GDPR Compliance === ## Authors * Dirk Spannaus - [twentyZEN](https://twentyzen.com) * Input from * [peter_k](https://forum.mautic.org/t/rfc-improving-mautics-gdpr-compliance-cookie-management/27801) * [Sven Döring](https://moorwald.com) ## Motivation There is a large focus at user side on the compliance of tools and method with legal requirements. Many commercial solutions don't deliver - but currently also Mautic can't be run completely compliant without hacks, workarounds of limitation of features. Some of them can probably be solved quickly with help of the core development team pointing out, where to look for. Other issues may be difficult to solve, as they will limit already introduced Mautic features or render them useless. The benefit of solving this issue is a powerful value proposition for Mautic: Run either at a SaaS or on premise and have the option to be completely GDPR compliant with your system. ## Overview of problems with "Vanilla" Mautic 1. Forms set cookies (except when in "Kiosk Mode") 2. Asset downloads / redirection links / landing pages / focus items always set cookies 3. No support for "Do not track" 4. mtracking.gif sets cookies - always 5. Forwarded E-Mails set cookies 6. Current device fingerprint option not compliant 7. No support for removing cookies after revoking decision 8. Other issues ---- ## Problems in more detail ### Forms set cookies - except when in "Kiosk Mode" #### Description Forms and embedded forms set cookies. Consent Management in whatever way is not supported. #### Scenarios * You don't want to set cookies, when many different people use the same machine (thus "Kiosk Mode") or the form should be submitted anonymously anyway (which needs other hacks additionally). * You embedd a form in the website for registering. At this point you have no consent yet to track people, except if you block loading the form via an external consent system. Not showing the form without additional user interaction is a bad user experience and will probably reduce conversion rates. #### Quick fix Enabling "Kiosk Mode" for the specific form. ### Asset downloads / redirection / landing pages / focus items always set cookies #### Description Whenever you directly link an asset in your webseite or anywhere else, it will also set a cookie with it. Also visiting landing pages or loading focus items will set a cookie. There is no option in the GUI to either to disable for single or all assets / redirections. There is no "Kiosk Mode" like in forms. #### Scenarios * We planned to establish Mautic as the only digital asset management for a new client website. Due to that reason, we ended up to provide asset downloads outside a marketing automation campaign outside of Mautic. Thus not achieving maximum efficiency, due to duplicated asset management. * When we planned to use a simple landing page just to show a simple mautic form. However - we ended up using the form in "Kiosk Mode" standalone. #### Quick fix Adding a "kiosk mode" to other objects as well. #### Long fix * UI switch for single or all assets * smarter approach, that is connected to a global status for the particular user decision * should always respect Global Privacy Control #### Pointer to code, thats responsible for the issue missing #### Status not started ### No Support for "do not track" // Global Privacy Control #### Description More Background can be found [in this Wikipedia Article](https://en.wikipedia.org/wiki/Do_Not_Track). Actually "DNT" is deprecated already since 2019, and replaced by ["Global Privacy Control"](https://globalprivacycontrol.org/) according to [that article](https://joindeleteme.com/blog/how-to-enable-global-privacy-control/). Its not supported by browsers natively, [except Firefox](https://caniuse.com/?search=globalprivacycontrol) and [some specific privacy aware browsers](https://globalprivacycontrol.org/#download). A couple of extensions add that capability to major browsers. It has also been mentioned, that a "do not contact" decision should be understood as a "do not track" decision as well. Then the unsubscribe action should also trigger the "do not track" actions as soon as its available. ##### Should Mautic support it? Also other Marketing Automation tools, like [Hubspot is suporting it](https://knowledge.hubspot.com/de/privacy-and-consent/turn-on-support-for-global-privacy-control). Also if Mautic want's to be the goto place for privacy aware clients its a must. However, not tracking the client might break some campaigns. We should make a clear distinction between "do not track / privacy control" which aims mainly at tracking data and potentially selling data from it from "campaign control events". A simple "please confirm, that you want that" or "here is the link to the download" may sometimes be no tracking, but rather a "campaign control event". Mautic users should be able to differentiate between that. Otherwise not even an optin campaign would work anymore. You couldn't record the client decision for an optin, when the tracking is generally disabled. In addition a recent higher court case in Germany [required LinkedIn to honor DNT settings](https://www.heise.de/news/Do-Not-Track-LinkedIn-darf-nicht-mehr-erklaeren-Browserfunktion-zu-ignorieren-9348171.html). Therefore it is essential that Mautic supports it. #### Scenarios * People may decide to be contacted through newsletter / campaigns, but may optout to being tracked. According to the data privacy officer of a client, this information needs also to be available to them. Currently its a either sign in or don't get information at all. We should be able to allow people to optin campaigns, downloads without tracking them in a sense, thats not related to control of campaigns and such. * People who decide "do not contact" would also expect to not being tracked anymore. However - in that case a simple "please resubscribe, it was an eror" wouldn't work anymore, as the user is not known at the moment after the decision and removal of tracking means. #### Quick fix Not using Mautic tracking scripts on your website solves it for your website, but its ignored in all other Mautic components. #### Long fix Implementing GPC as supported option in Mautic. It should then be respected on a per user basis systemwide. #### Pointer to code, thats responsible for the issue missing #### Status not started ### Forwarded E-Mails set cookies #### Description Whenever a receiver of a mail (newsletter / campaign mail) forwards the mail to someone else, clicks on the link will be handled as if the regular recipient clicked the link: * can be tracked * gets a cookie set * can unsubcribe the original recipient of the mail * controls the further run of the campaign This might be problematic, as the new recipient wasn't asked to confirm any rules of engagement, that the initial recipient agreed to. #### Scenarios #### Quick fix There seems to be no short fix. There is no way for mautic to identify, if the regular receipient clicked the link or an unknown contact, who this mail was forwarded to. Even if we can argue about who is responsible for the situation (the person forwarding the mail?) its still our system that's tracking without consent. Not sure, if "Identify visitor by tracking url" disabled would be of help here and if it breaks campaigns. Outside of the technical scope, the initial agreement with the registered user could be extended to make people aware of this problem and to ask not to directly forward their mails to other people. However, this is contrary to desired behaviour, as marketing people would welcome mails to be shared and reach a wider audience. Maybe its a good practice to provide an "unloaded sharing link", that people should share instead prominently in the mail. There is also the option to individually mark links as non trackable (need to look this up in the forum/documentation). #### Long fix * We need to check, how others handle that issue. * Instead of marking links, that should not be tracked, we should also be able to set links that should be tracked. * Individual mail settings should have a switch to activate / deactivate links to be tracked, with individually overriding this with a link option (as described before). #### Pointer to code, thats responsible for the issue missing #### Status not started ### Current device fingerprint option not compliant #### Description The problem with device finger printing in the typical way: its having similar issues as with cookies (only it doesn't store data at the clients device). So while it respects the ePrivacy regulations, finger printing doesn't solve the cookie problem (due to missing consent) completely. #### Scenarios #### Quick Fix Don't use builtin fingerprinting. #### Long Fix Matomo implemented an alternative to finger printing - the [config_id](https://matomo.org/faq/general/how-is-the-visitor-config_id-processed/). Its not completely the answer for Mautic's problem - finding a way to identify visitors reliably, as the config_ids change every 24h. The time-window a campaign benefits from recognizing an identified visitor is pretty short in terms of marketing campaigns. On the other hand 24 hours is already debated as being at least the maximum that would be viable from a data privacy regulatory standpoint. And even that is highly debated. The config_id could be refreshed and linked in each situation, the action of a mautic lead is definitely linked to them personally and they agreed to be tracked. #### Status not started ### No system support to remove cookies #### Description There is currently no technical way to support users in removing cookies etc. set by the Mautic instance. #### Scenarios * People unsubscribing or revoking their consent, system keeps tracking via existing cookies. #### Quick fix * Add a description to your data privacy statement on how people can manually delete the related cookies from their devices. #### Long fix * Introduce a function, that removes cookies from the related Mautic instance from the users device. #### Status not started --- ### Other issues #### Gravatar function can't be disabled ##### Description Gravatar function pings the gravatar service (run by Automattic) with opening each mautic lead. ##### Quick fix There is a workaround with a patch, which renders kills the function with a simple (not nice) code chance. Needs to be applied after each update of Mautic. https://twentyzen.com/en/think/faq-items/deactivate-gravatar-in-mautic/ --- ## General Solutions There needs to be a more advanced way of how to process tracking and make sure, the consent is there and still valid. User braden describes a potential approach [in his forum comment](https://forum.mautic.org/t/rfc-improving-mautics-gdpr-compliance-cookie-management/27801/7). ## How to proceed [ ] 1. marke sure assumptions made in this documents are correct and complete [ ] 2. finalise discussions about the desired outcomes [ ] 3. discuss with core devs about small fixes [ ] 4. introduce long term solution into the development roadmap --- ## Further links ### Plugins * https://github.com/content-optimizer-gmbh/mautic-email-tracking ### Forum Discussions * https://forum.mautic.org/t/is-it-possible-to-disable-tracking-per-email-basis-instead-of-on-the-whole-mautic-instance/28537/7 * https://forum.mautic.org/t/rfc-improving-mautics-gdpr-compliance-cookie-management/27801