On Fri, 9 May 2008 23:08:23 +0800
Kestas Kuliukas <kestas@[EMAIL PROTECTED]
> wrote:
> > By security, however, I mean limiting the ability for people to
> > cheat or otherwise misbehave on that server. This includes
> > providing a description of expected behavior, like the Electronic
> > Protocol House Rules (believe or not people need to be *told* that
> > taking two positions or hacking someones password is wrong) and
> > monitoring activity on the server for indications of duplicate
> > positions, collusion, etc.
>
> Hmm, the adjudicator on phpDip is supposed to take care of this, and
> make sure cheating like that can't happen. There is a problem with
> people using more than one account, but I've added logging of
> IP,browser,time details etc and I'm hoping to add moderators to be
> able to manage it in a more automated way.
On judges, GMs do manual examination of the registrations in a game
while JKs look at registrations as they come in and sometimes the email
headers. Without getting into the details, duplicate position cheating
is almost impossible this way, which takes care of most of the worst
problems on a judge as long as either the GM or JK insists on a
complete registration and verifies the data. It does mean that most
judges run about 50 games.
In the past couple years I've caught several attempts at duplicates, a
couple illegal uses of another party's password and a couple attempts
to guess passwords. I've seen several accusations of collusion but,
in the rare case that the accusations turn up anything, they are either
better than average attempts to disguise a multi or the alliance falls
apart despite its meta-game origin. Most accusations of collusion are
nothing, however.
A second set of eyes on the data is the only way. I had someone ask me
once why I thought GMs were necessary for on-line Diplomacy games. The
answer is that when there isn't a GM then the JK (or other admin)
becomes the de facto GM for every game on the server. If the number of
games exceeds the GMs capacity to monitor them then cheating will get
out of hand.
> Also this problem is limited to the low-points games where the
> newcomers play, but it is a problem and if other sites have come up
> with smart ways to resolve it effectively without needing moderators
> I'm interested to hear.
You're right that most cheating, abandonment and other issues occur at
a low level of play. It's unfortunate that is also where you have new
players evaluating the game for its long-term entertainment potential.
It's not bad when you catch the problem before game start or even
spring of 1901, which usually happens, but people coming in as
replacements can take a game that's already suffered multiple delays
and force its termination if not identified before their first turn
processes. Also, in the rare cases that cheating does occur at a higher
level of play, the players are more sophisticated about covering their
tracks. Check out Scott Marshman's home page:
http://members.tripod.com/~smarshma/index.html
Nice guy, right? Ask Jay Furr his opinion. Scott once signed on a six
positions in a standard game. If you think that the web page indicates
a narcissistic pathology, you're right in one.
You could use the GeoIP data base with the PHP API to flag a game for
intervention when the IPs in use indicate a possible geographic
overlap by comparing the city or the metro code. Using metro code would
not be as thorough as a proximity check, but has the advantage of being
much easier to automate. The online demo is at:
http://www.maxmind.com/app/locate_ip
There are links to sample code that utilizes the data base. There's a
free version and a commercial version. The difference is that the free
version is updated as often as the JDPR (2005 being the last update).
That means that most of the IP addresses in use will scan. I don't know
how that's going to work when IPv6 comes into common use.
> > That happens to be my big issue. Once 0.8 is available on
> > Sourceforge, I'd love to set up an install and provide more
> > detailed input, maybe some usable patches.
>
> Great :-) if you subscribe to the sourceforge mailing list you'll get
> a notification when it's released (hopefully some time this
> June/July).
I'd already signed up for the list. :-)
Chris
|
