Hi. I raised this issue.

I'm starting a business making apps to sell to kids and hired a lawyer to help with my privacy policy (and believe me, I've read over many privacy policies lately). I wondered if I needed to put a notice in my privacy policy about fingerprinting, such as:

Fingerprinting

Our website takes a fingerprint of your system’s setup, to imperfectly distinguish between visitors to our site.

My lawyer sent me this page to look at: The GDPR and Browser Fingerprinting: How It Changes the Game for the Sneakiest Web Trackers.

I know that Matomo is serious about privacy. Lacking any way to disable the fingerprinting, I've decided to forgo it for tracking hits to my website (but I am planning to use it to track analytics for my games, as I feel that Unity Analytics processes way too much information.)

Thank you for considering this issue.

We're wondering whether fingerprinting in Matomo could be considered personal data... Knowing that our fingerprint is quite imprecise and sometimes recognises multiple people as one: #13528

From https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how-it-changes-game-sneakiest-web-trackers

You’ll struggle to find fingerprinting explicitly mentioned in the GDPR—but that’s because the EU has learned from earlier data protection laws and the current ePrivacy Directive to remain technologically neutral.
Apart from non-binding recitals (like Recital 30, discussing cookies), the GDPR avoids calling out specific technologies or giving exhaustive lists and examples. Instead, it provides general rules that the drafters felt should be neutral, flexible, and keep up with technological development beyond fingerprinting and cookies.
[...]
Thus, when several information elements are combined (especially unique identifiers such as your set of system fonts) across websites (e.g. for the purposes of behavioral advertising), fingerprinting constitutes the processing of personal data and must comply with GDPR.

In Matomo by default we seed the fingerprint with a different seed across websites, so that a same user will have a different fingerprint when they're tracked in multiple websites in the same Matomo. The visitor will also have a different fingerprint in different Matomo instances. So no "cross websites tracking" is possible (unless the enable_fingerprinting_across_websites flag is activated on purpose - which we don't even document publicly).

it will be interesting to review the ePrivacy regulation draft to check on the current status of fingerprinting: #15425

I think what would help is eg to randomly generate a visitor ID in the client that is valid for only max 30 minutes (visit duration) and on every page view or event the ID is extended for another 30 minutes. There will still be a cookie but only for 30 minutes, and it won't be possible to identify a visitor since it would change on every new visit.

You won’t get unique visitors data (or new vs returning data) etc but many wouldn’t even need it. Many segments and most reports would still be meaningful. I reckon that could be a start?

see also #15478 #15479

As mentioned in #15507 ideally we even don't use any cookies by default.

And ideally, by default, the fingerprint includes the current date to prevent fingerprinting visitors across multiple days.

We'd want this feature configurable overall eg in global website settings. If fingerprint is disabled, then it should not be possible to enable it for any site and the setting doesn't show in the sites manager.

If enabled, then it should be possible to be configured for every site in the sites manager.

If fingerprint is disabled, it would automatically also disable the visitor profile ideally since there wouldn't be any profiles anymore anyway.

What other changes can we apply that make sense?

• Eg a configId would match only max 24 hours back maybe or we would at least not look for a different visitorId (would need to think about how this should work)
• would we disable the fingerprint segment and maybe others?
• I suppose userId feature can still be used?
• Disable unique visitor metric
• Ideally disable maybe new/returning visitors metrics

Also impacts referrers reports and multi attribution report when cookies are disabled.

One approach could be:

• Server setting: When cookies are disabled (in tracker, we would add a tracking parameter), also disable fingerprint for cookie consent compliance. When cookies are enabled, it would still use the regular fingerprint.
• There might be also a feature needed to enforce not using fingerprint (anonymised) independent of cookie (maybe).
• A third option be to not have this setting server side and only in tracker like tracker.disableCookies(alsoDisableFingerprint=true)

The first option might be the best. For new installs this would be maybe enabled, for older instances this might be disabled to not break BC or could enable it for everyone.

We're actually now thinking to disable the fingerprint all the time when cookies are disabled. No server side setting. As fingerprint is just like cookie and you'd expect it to not have a fingerprint applied when cookies are disabled.

we have fixed this in 3.13.6 in #15886 and made this the default behaviour.

I don't think there is any further change needed? I'll close this for now.