Cookieless: config_id and ePrivacy

je_mi_bi · March 23, 2023, 9:39am

Hi everyone,

Our company is currently piloting the cookie-less cloud version of Matomo.

While I understand the config_id is a randomly-seeded, privacy-enabled, time-limited hash of a limited set of the visitor’s settings and attributes, our EMEA internal privacy team still considers - even if one disable browser feature detection - that collecting some of those settings and attributes is not compliant with article 5(3) of the ePrivacy Directive.

I explained to them that, with browser feature detection turned off, those reduced number of settings and attributes were only part of the user-agent string, still they consider that you are collecting those for analytics purpose without user consent.

I was wondering if there was a way to generate a config_id that would not be based on the visitor’s settings and attributes but on a random or unique ID for instance (Math.random, UUID library, etc.) ? I know this would screw up the number of visitors in that 24 hours window, but for some companies like ours, visitors is not a metric we track at all.

Thanks very much.

Jean-Michel

heurteph-ei · April 17, 2023, 12:42pm

Hi @je_mi_bi
Links to some GitHub discussions about this topic:

github.com/matomo-org/matomo

Add an option to disable fingerprinting / config_id entirely

opened 11:43AM - 03 Dec 21 UTC

MoritzLost

Enhancement c: Privacy

## Summary This is continuation of #16361 and the [related discussion](https:…//forum.matomo.org/t/does-device-fingerprinting-require-consent/42869) in the forums. Right now, the stance of Matomo is that in cookie-less mode, [it doesn't use fingerprinting](https://matomo.org/faq/general/how-is-the-visitor-config_id-processed/) so it doesn't require consent. Under GDPR this line of thought is perfectly sound and reasonable. However, under the ePrivacy directive (which is now implemented in German law since 1 December, 2021 with the [TTDSG](https://dsgvo-gesetz.de/ttdsg/)), this is once again a debatable point. The key phrase in the ePrivacy directive is the 'access to information' already stored on the user's device. Of course, it's not entirely clear what this means in practice. But call it a fingerprint or not, Matomo does [access some data from the user's device](https://github.com/matomo-org/matomo/blob/4.x-dev/js/piwik.js#L3130-L3187) to create the config_id (in particular, the screen size and supported mime types). It's really up for debate if this constitutes 'access to information' – but as long as there's no legal precedence, some clients will want to cover all their bases. So it will once again be necessary to require consent before using Matomo, even without cookies or 'real' fingerprinting in place. So having an option to disable the device detection further would be great. Instead, the config_id could be based solely on User-Agent and anonymised IP address (which the server receives implicitly, so no data access is required). Of course, this would further limit the usefulnes of some reports. But this would be acceptable in order to be 100% sure that using Matomo without consent is completely safe, legally speaking.

github.com/matomo-org/matomo

Possibility not to simply switch off fingerprinting, but to configure it

opened 12:29PM - 31 Mar 22 UTC

amargoShop

Enhancement

The disableBrowserFeatureDetection option completely disables browser fingerprin…ting. Unfortunately, important data is also lost in this way, such as the screen size and the type of end device (mobile, pc, tablet) ## Summary It would be perfect if you could set which data is saved during fingerprinting and which is not. In this way, one could continue to receive the data that does not violate the GDPR. It could be a param for the call of "disableBrowserFeatureDetection" that you can set to "disable all", "allow all", "allow device info" (config_device_type, config_device_brand, config_resolution). Or - in the backend of Matomo - a list of checkboxes for each property (config_xyz) stored in the log_visit table.