Discourse Fingerprint - Browser Fingerprinting Plugin

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.

1 Like

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.


Hey, we’ve just started to get 500’s on attempting to load the /fingerprint page. Not sure what’s happened here - any ideas?

NoMethodError (undefined method `data' for nil:NilClass)
(eval):9:in `_fast_attributes'
app/controllers/application_controller.rb:445:in `serialize_data'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'


plugins/discourse-fingerprint/app/serializers/flagged_fingerprint_serializer.rb:30:in `data'
plugins/discourse-fingerprint/app/serializers/flagged_fingerprint_serializer.rb:51:in `include_is_common?'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:375:in `include?'
(eval):9:in `_fast_attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:468:in `rescue in attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:455:in `attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:480:in `_serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:359:in `serializable_hash'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:89:in `block in _serializable_array'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:79:in `map'

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. :smiley:

@udan11 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. :slight_smile:

1 Like

The admin/upgrade page says there are no updates, we are on c91883f

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.

1 Like