Anonymise fingerprint #15855
Anonymise fingerprint #15855
Conversation
tsteur
added
the
Pull Request WIP
| @@ -120,6 +122,10 @@ protected function getConfigHash(Request $request, $os, $browserName, $browserVe | |||
| $configString .= $request->getIdSite(); | |||
| } | |||
|
|
|||
| if (PrivacyManager::shouldAnonymiseFingerprint()) { | |||
| $configString .= Date::now()->setTimezone(Site::getTimezoneFor($request->getIdSite()))->toString(); | |||
There was a problem hiding this comment.
todo: generate random string per site per day or so to anonymise it more
There was a problem hiding this comment.
👍 and quite a long string so it's not possible to guess if one knew all the other data points
There was a problem hiding this comment.
Really great we can have this feature in Matomo 3 and 4 :-)
Note regarding documentation/letting people know:
- we could create a new FAQ for this feature (eg easy to find when "no fingerprint analytics")
- document this in https://matomo.org/faq/general/faq_21418/
- also in: https://matomo.org/docs/privacy/
- and in https://matomo.org/features/
| ng-model="anonymizeIp.anonymizeFingerprint" | ||
| data-title="Anonymize fingerprint" | ||
| value="{{ anonymizeIP.anonymizeFingerprint }}" | ||
| inline-help="By anonymising the fingerprint, Matomo will still generate a fingerprint. However, this fingerprint will change for each visitor every 24 hours. This means a visitor can no longer be followed over multiple days, no profile can be generated, and an individual cannot be identfied. This setting currently applies to all websites. When enabled, it will ignore any visitorId and as a result, the unique visitor metric will become inaccurate and sometimes different visitors may be falsely identified as the same visitor if the used device is similar. It will partially also disable the visitor profile in the UI. Please note that this feature does not deactivate the UserId feature."> |
There was a problem hiding this comment.
Suggested after few minor tweaks:
By anonymising the fingerprint, Matomo will still generate a fingerprint. However, this fingerprint will change for each visitor every 24 hours. This means a visitor can no longer be followed over multiple days, no profile can be generated, and an individual cannot be identified. This setting currently applies to all websites. When enabled, any Visitor ID collected will be ignored. As a result the Unique visitor metric will become inaccurate, and sometimes different visitors may be falsely identified as the same visitor if the used device is similar. The Visitor profile will also be disabled in the UI. Please note that 'User ID' feature is still available.">
btw I find this not clear, could we explain more clearly? sometimes different visitors may be falsely identified as the same visitor if the used device is similar
There was a problem hiding this comment.
This is not the final version yet anyway. Only wanting to make sure the concept is working, not details.
Indeed, how else could we call it so it's really clear? |
|
It's hard to say. What we're looking for is maybe not even related directly so much to "fingerprint". Saying it "anonymises" the fingerprint kind of suggests we usually don't do that but that'd be also not 100% correct. Also wondering what we could say how this maybe impacts cookie banners. Eg can we say as a result, if no personal data is tracked, no cookie consent is needed? So is it maybe more about avoiding "cookie consent" (if also no personal data is tracked)? Also be good to have confirmed that we're confident enough once we apply a random token per day that users can really no longer be identified across days. |
|
Sounds good... could we maybe name
someone with access to DB could potentially re-create the original hashes since other data points used in fingerprint are stored in the Db afaik, so as long as the daily (or more frequently re-generated, even customisable?) string is random and long, it would be secure? |
|
When consent has been given, would we still limit the fingerprint? |
| $isVisitorIdToLookup = false; | ||
| $idVisitor = false; |
There was a problem hiding this comment.
here we wouldn't want to change the logic in "findKnownVisitor" when cookies are used and "limit fingerprint" feature is activated, then the cookie visitor id would need to be used to match visitors accurately. (we assume eg. consent was given when cookies are received by tracking api).
(Otherwise this would break legit use cases and changes/bc break tracking API, especially as the setting is global and affects all sites)
@mattab that makes afaik no sense as from a privacy and user perspective tracking with cookie or fingerprint is the very same things. All/most privacy laws consider the fingerprint as the same as a cookie and that's why you'd want to ignore any visitorId from a cookie and ideally we'd also disable cookie feature in general in tracker. To avoid easy to understand / simple UI that is useful to users could have one setting "Avoid cookie consent banner" or "cookie less tracking" or similar. But splitting this up makes not really any sense except for making things complicated. |
|
@mattab I'll close this PR for now. Let's discuss further this Wednesday. Wanting to prevent implementing some solution that might be obsolete in Matomo 4 and people need to change things again possibly so be better to work on it first in Matomo 4 and back port it to Matomo 3 |
|
Might be more clear to use this approach of super privacy mode |
refs #13655
@mattab was quickly working on this 30 min for 3.X.
The full feature #13655 (comment) could be developed in 4.X. While it's not fully implemented, it would be something though that could already help. The idea is basically to add the current date to the fingerprint, to ignore any visitorId unless it is a userId, and to disable the visitor profile in the visitor log (not in userId feature or API etc which can all be done in Matomo 4)
Not sure if "Disable fingerprint" is the right word since a fingerprint is still needed. Of course there could be also a feature "Disable fingerprint" which generates a new visit on every tracking request. It would basically add the dateTime to the fingerprint as well as some random generated string. That can be useful if people only want to know how often eg a page was viewed etc.
Any thoughts?