Remove user_fingerprint

[bogaert]

We know the user fingerprint is not reliable. Past investigations on large datasets (500M+ logged in events) have confirmed this. For instance:

If 2 events have a different domain_userid but the same user_fingerprint, the probability that this is the same user is less than 50%.

I'd argue we should stop sending it altogether because the mere presence of the fingerprint creates confusion among our users (as far as I know, we never recommend using it).

Because deprecating the fingerprint could be a breaking chance for existing users, an alternative might be to disable it by default. Thoughts?

[alexanderdean]

The other strong argument in favor of removing the user_fingerprint is that the presence of fingerprinting technology in a tracker can cause that tracker to be rejected by an ad network's third-party tags approval process.

If we are going to remove it, my recommendation is that:

• We treat this as part of the atomic.events refactor
• We define an Iglu Central schema called something like legacy_fingerprint
• We migrate the user_fingerprint data from atomic.events into the above schema
• We provide users with the code to manually recreate the legacy fingerprint if they so wish in their tag manager (ideally in concert with Add global contexts features #405)
• We delete the user fingerprinting code from the Snowplow JS Tracker

[christoph-buente]

So the general tendency is to remove this feature rather than fix it? For example with an external library like fingerprintjs2?
https://github.com/Valve/fingerprintjs2

[alexanderdean]

Yes, the presence of any fingerprinting will cause a JS widget to be rejected by major ad networks.

Once we have #405, it should be straightforward for anybody to implement their own fingerprinting and attach to each event. Even easier with #450 when you can write a dedicated fingerprinting plugin...

[christoph-buente]

As long as we can override the value of the fingerprint id with anything, people are free to do whatever, right? But yes, #450 would be good to have, as such feature could be turned on/off during built time.

[yalisassoon]

@paulboocock I think we should remove the user fingerprinting functionality from the JS tracker in the next release:

• It doesn't work
• I don't think we should be encouraging the user of fingerprints as tracking technologies - their use is opaque to end users
• As discussed above the presence of fingerprinting technologies in trackers can lead to them being blocked

[paulboocock]

I've taken the approach to remove all capabilities of fingerprinting within the tracker itself, however the api method stubs are still present so this can go out in a MINOR release but produce a warning when used. I will remove the remaining stubs in version 3.0.0.
This means fp will not be sent with any tracker events, and user_fingerprint will not be populated when using this tracker. Users are still free to add their own context containing user fingerprinting if they wish but there is no specific fingerprinting capabilities any more.

I've also taken this opporuntity to remove the augur.io fingerprint capture we have as an autocontext. Again, users can manually add this as a context if they wish but as the goal here is to removing automatic fingerprinting from the tracker, it seems reasonable to remove the augur identity trackig too. Also augur.io does appear to be a dead project now from what I can tell.