Remove user_fingerprint

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?

[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.

[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