Excellent - thanks.

MOST excellent!

Also, and you may have anticipated this already, but it would be useful to allow admins to reset the AED if their userID counts have been reset. Perhaps this means a timestamp or AED version number in the cookie.

And once an overlap has been reported for a particular pairing, it would be useful to stop further reports of that particular pairing. That is, once users A and B are reported as overlapping, it isn't necessary to report it again. But this should not stop new overlap reports for A and C, or B and C, from being made.

Just an update on this:

I've completely rewritten the back-end (the old mod was only the backend), but I've yet to write the front end which will allow easy management of all the reports, cookies etc. At the moment the new version is running on my production forum (around 3000 visits per day), so I'd like to keep running it to make sure it is stable and works as it is supposed to. So far, so good.

The new features are too numerous to mention, but it does import the old cookies from the original version, so there's a pretty much seamless upgrade path between the old and the new version.

I'm not sure when this is going to be ready, but I would guess about 1 month, most of the difficult logic and tricky testing was done in the backend, so writing the front end should hopefully be simpler.

Now onto your suggestions:

Cookies contain a unique cookieID which ties back to the database, userids on the cookie and the first visit on that cookie, as well as an MD5 hash of the cookie contents. Everything is based on userids, so to be honest if someone resets all their userid numbers (why would someone want to do this) then it won't work anymore. Thankfully the fix in this situation would be easy - the admin would have to drop all the records from the AED tables (can someone tell me what AED is supposed to stand for, I should really know since I'm writing it - the A and the D I get, but the E?).

If during the login process the cookie ID on the PC is not found in the DB then it will be removed from the machine and a fresh cookie issued - in this way it would solve the problem you've just described. This functionality has already been tested.

I've implemented this a little differently. Firstly the same users logging into the same cookie will not raise another report (that is also how it worked in the old/current version). Before you had the choice just to exempt users, but now you can exempt a cookie as well. The advantage of exempting a cookie is that all subsequent users won't be reported (unless they go to another computer and log in). This is useful for a PC where many people share it (like a common PC in a work cafeteria for example).

Of course if you've exempted a cookie and it gets cleared, then you'll get the report again unless the users have been exempted.

The main thing that used to bug me with the old one was having to retrieve the userids and enter them into that comma separated list. This will be much easier in future! The system also automatically PMs offenders and asks them to explain. If they don't, you can have them automatically banned or suspended within a configurable period of time. There's also an option to immediately ban users who register from a computer where a banned user has logged in...

Hi, here are my suggestions:

• The reports should be searchable. So if you enter a specific user name in the searchbox you should find the reports.
  
  
• The system info (e.g. browser, os, screen resolution, ..) as well as the IP-Adress(es) should be within the report. In some cases this might be helpful. It would be also helpful to have for each posting the system info saved to have a thrid way to compare users (appart from shared IP-Adress and cookie)
  
  
• The first save date of the cookie should be reported.
  
  
• I'd love to have a automatic cronjob that searched once a day for users who were during the last 24 hours online with the same ip-adress. We have a very huge forum that is a few years old so searching for a specific ip often shows dozens of users who accidently had the ip-adress during the last years.

The actual interface will be concerned more with dealing with the current issues - such as tracking new reports and resolving them, so it won't deal too much with history. However, each time an incident is reported it can be sent as a PM, started as a new thread in a given area or appended to an existing thread. Each report contains detailed information about each user found on the cookie. If you keep this information you can then use the advanced search features of VB to locate the info you need.

I have deliberately left out IP address and browser info from the reporting. Why? IP address is becoming more and more useless as a way to track users - that's the whole idea behind the cookie-based approach. Many users are logging on via proxies (for example when they are at work), or are using dynamically allocated address which are changing often. Including the IP really would be of limited use.

What about browser details? Since our cookie is tied to that specific browser, why do we need these details? How will it help? All we need to know is that a cookie with a given ID is tied to a particular computer. I don't want to include detail in the report unless it is really useful.

However, the report does mention how many times a user has been allocated a cookie, and warns if this number is too high - could indicate cookie deleting behaviour. However, users who delete their cookies after each session will probably never be caught by this hack anyway.

Yes, the first time each user is added to a cookie this date is saved both in the cookie and in the DB. It is also mentioned in any reports.

Such a feature is out of scope for this mod and has nothing to do with any of its functions. However, you should be able to do this with a simple SQL query, or write such a cronjob yourself. Remember that people who work in the same company would be flagged with this. Most of my users are in the same country, so such a report would produce so many false positives that it would keep me busy investigating them all!!

I'll post some samples a bit later on about how some of the reports look that are running on my forum at the moment.

AED - I've always thought it stood for "alter ego detector".

Ok everyone - it's time to show you some goodies of how this product looks so far. As I said earlier only the backend is done (a few minor tweaks to do), but you can see a few things in the meantime.

The program is keeping a running log. This is basically a development feature I put in to track how the flow of the program through the various bits. But actually it turned out kind of cool.

This is what the standard text looks like for an alert message raised to the admins:

(note that I have removed personal info like email address)

The users can also get a PM. This is what they look like on my system, but the standard version of the product will have different, more generic text:

I've still got a few minor tweaks like adding info to the admin reports that a user will get a PM and whether or not they will be banned or suspended, and how much time they have left.

Please also see screenshot attached to this post.

Imagine this situation (we accutally have this issue):

There?s a Club with a public internet terminal. Many forum users log in there.

The Club?s owner has an account too as well as many more fake accounts to promote his club.

Sometimes the owner uses his own PC ? so we can be quite sure that in that case all multiple accounts are fake accounts.

Sometimes the owner uses the public PC ? in that case we can?t distinguish between normal users and the owner?s fake accounts.

So let?s imagine the owner clears the browser cache on his private computer and logs in again with several of his accounts. In this case we have to wait and watch again for a while till we can guess whether he?s using the public or the private PC (in other words: if we can ban all multiple accounts or if there may be normal users among them)

Did I make myself clear? When public computers are involved it may be very comfortable to have system data as well.

I'm NeitherSparky and I approve this mod. ;) Looks great!

do you have a beta for this that can be used?
looks awesome nice job so far