I had a user ask me as an admin to help them with something, so I impersonated them to make sure I understood the problem they were seeing.
Now I’m registered as sharing a fingerprint with this user. I hid that fingerprint, but it’s still noise on the fingerprint display.
Given the ability of admins to impersonate, would it make sense to have a setting to exclude staff, or at least admins, from fingerprint matching?
Are there any plans for this plugin to be added to Business hosting? This would help me fingerprint possible sockpuppets much easily. If not, what other alternatives do you recommend?
Looks like an awesome plugin, giving it a whirl now.
My observations so far.
Lots of matches and lots of data to look through if one was to fish for suspected duplicate accounts. In my opinion, this plugin would be a lot more useful if the fingerprint list highlighted (or prioritized) matching devices if one of the members is/was banned and/or silenced. There are very few reasons people will set up secondary accounts when not banned, but banned members will always try to sneak in. Having this show up on the list would most likely make this plugin more useful.
I disagree with you on that. Sockpuppeting can be a major problem in some communities. Also, some users are more prone to do that kind of thing, almost wherever they participate. I’ve personally seen it.
I’m also not sure about the “always try to sneak in” when it comes to banned members.
Now, this doesn’t say your suggestion can’t be useful.
I guess you’re right now that I think of it. Forgot about users creating secondary accounts to push their agenda, whatever that may be.
Users can be silenced next time they visit the site with a matching fingerprint.
These errors should be fixed.
Removing the line from app.yml and rebuilding your instance should be enough.
What error are you experiencing?
I think I could add an option for that.
I agree with you and I believe I could implement some indicator to highlight banned users.
Hmm, that is an interesting error given that there are already checks to ensure that method is not called unless data really exists. Are you running the latest version?
I’ve had one new link spammer come in with five sockpuppet accounts before any of the accounts were banned. It’s real. I’d expect that almost any site that gets search traffic and has open sign-up probably is getting SEO spam sockpuppets; the only question is whether admins are finding it. 
@dan one more suggestion after having used this plugin more: In the list of users matching a fingerprint, I keep on clicking on users’ avatars, expecting them to be links to their admin pages or profiles, so that I can easily investigate whether they are accidental matches or actually sock puppets. I’d suggest admin page would probably be more useful for that investigation, but either would be easier than reading the hovertext, memorizing their user id from the hovertext, then hoping I type it right in user search to finally get to their actual user data. 
This plugin is amazing … so many of the trolls caught that would just keep changing VPN IP.
This should be considered to be native to Discourse ( @codinghorror ). Cookies, cache and IP don’t do justice for catching repeated troll attacks in 2020.
Except it totally fails when your users have iPhones. That is a critical weakness, and it is impossible to surmount.
It turns out that my spammers aren’t using iphones. We use data explorer to look for the “start with innocuous text and later edit it to be link spam” attacks, and fingerprint has done a good job of helping identify those spammers and help us shut down attacks faster. Not making the argument that it should be included by default; I don’t like collecting PII and don’t collect it without cause. If we didn’t have a spammer/troll problem I would absolutely not want to be using it, not because it’s nefarious, but because I don’t want to collect PII without a need related to providing service. So I think that it’s useful but also it makes sense to me that it’s a plugin rather than core. Making it be a conscious choice is a win for privacy. I asked my whole mod community about how they felt about it before implementing it, and was glad to have that conversation up front.
That’s fine, it’s an experiment I am happy to run, but everyone needs to be aware the trend is strongly towards browsers locking down all fingerprinting methods. This trend is most advanced in iOS but I expect it to extend to almost all browsers and platforms over time.
This is where discourse half-threading gets confusing; not sure who you are meaning to respond to, which leaves your antecedent unclear. Not sure if you’re actually responding to me or to @dylanh724…
In any case, I think that the status quo of leaving it in a plugin is a good idea.
The context is clear; I’m replying to the topic (fundamental weaknesses of browser fingerprinting), and to anyone who finds what I said relevant to them.
Some related news
With Firefox (and Safari, I think) now blocking fingerprinting, the nail in the coffin will be when Google Chrome blocks fingerprinting by default, then the rest of the Chromium dominoes will follow.
Could this give a false positive if two people are sharing a computer?
Same computer AND same browser, it sure will. A POSITIVE, nothing false in it (It analyzes the browser, not the user behind the keyboard)
Isn’t that pretty easy to bypass (whether that be through Tor or a different method)?
Everything can be bypassed. Here, it isn’t linked to the IP (what Tor or a Vpn would help with) but on the BROWSER. The easiest way to go around this is to use another browser, or directly another device (you still need to do this ON TOP of the Tor/Vpn thing to not be detected with the IP address)