Alter Ego Detector 1.7.8

[Harpers Tate]

I would like to reinforce what @Stuart Wright said here https://xenforo.com/community/threads/multiple-account-detection.49951/page-2#post-849713. This add-on is too limited at present for two major reasons.

In real life, what we are seeing is many, many repeated instances of reports, which is a big time-waster. We cannot use individual permissions to prevent these; it is the two, together, that we investigate and dismiss or deal with.

And, presumably ever since we began using this add-on, we have been placing cookies with a limited lifespan. There will be cases where this will allow a future duplicate to go unnoticed; and the longer this add-on remains deployed in its current state, the greater the number of cookies and thus the greater the probability.

In the circumstances, we have reverted to the unsupported AED we used prior to this one. As far as I know, it wasn't actually broken nor did it break anything. Happy to reconsider this if/when these issues are addressed.

 

[CTXMedia]

In real life, what we are seeing is many, many repeated instances of reports, which is a big time-waster. We cannot use individual permissions to prevent these; it is the two, together, that we investigate and dismiss or deal with.

Have you added a "bypass" usergroup - one with just a single setting to allow alter-ego bypass?

This works wonders for us - if we investigate and cannot find anything wrong or any obvious reason for the report, we just put both user accounts on bypass and we don't see any more reports. Simples!

 

[Harpers Tate]

@Clickfinity
It's not sufficient to mark a single user account (either as an individual permission OR using a secondary group). Because in your case, both accounts are now immune from detection. How do you know that neither of them will attempt a re-registration just because this one case was innocent? We have plenty of devious so-and-sos.

Real life, frequent example:
User 1 re-registers as User 2. For some reason (usually to retain detailed history when it has gone unnoticed for a time) we do not merge but instead ban one of the accounts (eg User 2) and leave the other active.

No individual permission setting could ever
- prevent repeat detection of this exact duplicate pair yet
- allow detection when a third account is registered against either of the other two.

It needs the pair to be exempted as a pair.

 

[Mouth]

- allow detection when a third account is registered against either of the other two.
It needs the pair to be exempted as a pair.

But what are you trying to protect against?
If user 1 creates/registers user 3, then it will trigger an alter ego detect. If user 2 logs on, then it will trigger an alter ego detect. Why do you not want that?

 

[CTXMedia]

No individual permission setting could ever
- prevent repeat detection of this exact duplicate pair yet

That's what the bypass usergroup does - it excludes those two accounts from future reports (as a pair, if you like) ...

- allow detection when a third account is registered against either of the other two.

... but does report when a non-bypassed third-party matches either of the two bypassed ones.

Give it a try - it might seem a bit of a bind adding them to the additional usergroup, but the net effect is lots of saved time through not having to deal with the multiple duplicated reports.

We've called the usergroup: Alter ego bypass

... and the only setting change for this group is:

 

[Harpers Tate]

User Groups I'm fine with. Permissions I'm fine with.
Marking individuals (even if by group membership) in order to exclude a given pair, I'm not.

Let's try this - and no, I'm not making it up. We DO get them.

A and B are cohabiting - different people who have shared a home machine. Detected and allowed.
C and D are colleagues - different people who have shared a work machine. Detected and allowed.

A and C are one and the same person. This has yet to be detected. We sanction A for some misdemeanour, and he uses his C account to log on with instead.

Or is clever enough to use, say, two different browsers, each of which is shared with a genuine other. And slips up.

Individual exemption would see A and C as both as exempt.
Pair exemption would not see A-C as an exempted pair and would detect.

We run a highly regulated classifieds section and our tight rules are the source of many re-registrations by those who seek to circumvent them. Their creativity knows few limits and we need to be equally as creative at detecting them whilst leaving the real innocent cases untouched.

Again - it is the PAIR that we have investigated and allowed; not either individual.

 

[CTXMedia]

I see, so using the bypass usergroup method would exclude A, B, C and D from being reported and when A switches to account C it would not generate a report - because both are already individually excluded.

The scenario you're presenting is quite a complex one - in terms of detection/reporting - you want A and B excluded from reporting from the 'home' device, but if A uses account C on that same 'home' device you want it reported. I expect you'd need a third dimension, such as the MAC address of the device being used, in order to allow you to triangulate when A (who is the usual user of the 'home' device) suddenly switches to user account C on that same device (or vice versa when A uses C's 'work' device). The same would work for mobile devices too since each device should have a unique MAC address, and could - depending on how the algo works - get around the use of proxies to mask IP addresses.

You could then (thinking out loud here since the capability doesn't exist) set up a "pair" exclusion by turning off reporting for A and B when they use device X (the home PC / laptop). Similarly a pair exclusion could exist for C and D on the 'works' device, which would then still allow for the reporting of A / B on the device/s that C / D use (and vice versa). This could be extended to more than two accounts too, since the common binder will be the device's MAC address, for example A, B and C sharing a house or being members of the same family.

Sorry, all a bit pie-in-the-sky really and beyond the scope of this current add-on - just imagining how you might get the pair exclusion you'd like.

 

[Harpers Tate]

Sorry, but I see that as over-complicated. I don't think we really need to go as far as comparing or recording machines' MAC addresses.

When we get a report, what we do is investigate the two subjects and determine if we will permit them to co-exist on our board for whatever reason.
Suppose we allow it. That's all we've researched, and that's all we are allowing. No more, no less. We're not exempting either party from having duplicate accounts (which is all the current permission can do); we are permitting one pair to both have member accounts.

So that, and that alone, is what needs recording so that future reports of the same pair are suppressed, and we don't have to either research it all again, or write usernotes and refer to them. Let's call it a list of "permitted pairs" where each entry is two user IDs side by side. That's it. That's all we need.

I don't care if the same two pop up together on a different machine at a later date - because we have determined that they may co-exist. I do care, though, if either of them shows as sharing a machine (any machine, previously seen or not; it's immaterial; so MAC addresses and the like are unnecessary) with someone else outside this permitted pair; whether or not the new party is part of another permitted pair elsewhere. Because until I have researched this new pair, I don't know whether to permit them.

And, if we get a genuine threesome, then we'll record three pairs. XY YZ XZ

(Aside: this needs to be alongside a User Group permission such as we already have; I'll give that to, eg, members of the Administrators Group because they can have as many accounts as they want).

 

[CTXMedia]

How are you going to identify the machine if you don't use a MAC address?

 

[Stuart Wright]

How are you going to identify the machine if you don't use a MAC address?

Don't need to identify the machines. It's the people logging in that's important.

 

[CTXMedia]

Sorry, but I see that as over-complicated.

You're right - got a bit carried away with myself. Good job I don't write add-ons.

Don't need to identify the machines. It's the people logging in that's important.

So what you want to do is add pairs of user accounts that are not reported if they trigger a match? For example, if the add-on identifies A and B as a possible alter-ego, before doing anything else it should check the "pairs" table to see if there's an entry for A+B (or B+A), and if so - stop right there; if not, report it as normal.

Good suggestion!

 

[Xon]

@Liam W when this addon pushes a signup into a moderated state, it doesn't include the user it matched on.

 

[Harpers Tate]

So what you want to do is add pairs of user accounts that are not reported if they trigger a match? For example, if the add-on identifies A and B as a possible alter-ego, before doing anything else it should check the "pairs" table to see if there's an entry for A+B (or B+A), and if so - stop right there; if not, report it as normal.

Good suggestion!

Exactly.

 

[CTXMedia]

Exactly.

I got there in the end.

 

[CTXMedia]

@Liam W - would you be up for adding this "pairs exemption" feature? It would be great for bigger boards (where we're likely to have couple/family pairs, flat share pairs, co-worker pairs, etc.)

 

[Liam W]

I'll see what I can do...

However, I may rewrite this add-on soon as well... My old code style was well, unclean...

Liam

 

[Harpers Tate]

PLEASE fix the cookie duration while you are in there

 

[Stuart Wright]

My old cold style was well, unclean

Colds are usually messy.
Must state that the AE Detector is critically important for finding duplicate registrations. This is a big deal when you have trading forums where people have been excluded for defrauding other members. If those people return undetected to continue the fraud, it's the members who end up out of pocket and the forums who end up getting a bad reputation for not being able to protect its members.

 

[upnet]

Thanks for this add-on. I'm wondering is there a way to exclude a list of members from detection? I like to have the Redeploy Cookie option enabled, but then I get a lot of notifications from a few members who are allowed multiple accounts and use cookies.

 

[Xon]

@Liam W

IMO, this addon is lacking 3 critical features:

• The bypass permission check needs to check both users (not just 1 effectively at random)
• When a user is moderated on signup, it's vital the alter ego is reported in the spam filtering reject reason.
• Only make 1 report per alter ego pair.

Is there any chance this would be done soon, or would you accept a code-drop adding it to the addon?