A new attempt at a social cheating solution

by Aardappel_ on 09/23/2006 08:11, 57 messages, last message: 09/27/2006 16:35, 16771 views, last view: 05/18/2024 01:23

Since taking the masterserver down, I have been thinking of new ways to combat cheating in a social rather than technological way. You have all seen my previous ideas on this topic, and I have a new, even simpler system that allows players to establish identity and trust, and admin servers accordingly, all without any central authority:

http://strlen.com/rants/trusted_communities.html

(scroll down, the new system is under "Decentralized trust").

See if you can poke any holes in this one. It is not a silver bullet, but it will bring us much closer to be able to play without cheaters. It works hand in hand with the existing mastermode (it extends it).

If all goes well we will implement this one.

   Board Index   

#29: Re: ..

by StillPeter on 09/24/2006 18:13, refers to #26

The problem with that particular idea is what happens if I log on to a server with 3 hacked clients and then boot people off I don't like?

The proffered solution is good because it makes it much more a hassle to do this as you have to get several unique IDs, gain some trust and then let loose with getting everyone banned. Cheaters are in the minority, by making it harder for them to fake a position to ban arbitrarily, you reduce the chance they'll be bothered to do it.

reply to this message

#30: Re: I think we have a winner

by StillPeter on 09/24/2006 18:15, refers to #28

"Stopping those you simply don't like from playing on a server on the masterserver would be an abuse." should really be, "Stopping those you simply don't like from playing on an open server on the masterserver with the trust system would be an abuse."

reply to this message

#31: Re: I think we have a winner

by Gilt on 09/24/2006 18:46, refers to #28

meh, you seem to understand and agree with the mechanism for the most part. all you're arguing about now is whether the glass is half-empty, or half-full.

For most people, I'd assume the only people they don't want to play with are going to be griefers, cheaters and assholes. All I'm saying is that this mechanism does not take sides, and does not make any judgements on whether a person truly is a griefer, cheater or asshole.

Whether a person is a griefer or vigilante, a cheater or modder, an asshole or mis-understood.... well that's for each individual to decide. this system will not make that judgement for them. the final decision is local to the people involved, and therefore much more relavant then using a central authority.

reply to this message

#32: Re: I think we have a winner

by StillPeter on 09/24/2006 19:07, refers to #31

Am I just misunderstanding you?

My only point is

Suggested trust levels:

* 0: the default. In most cases its not needed to assign trust as the IDs + stats already make it clear enough whether to let someone in.
* 1: played with this person quite a few times and appears to be a normal player, probably not a cheater
* 2: know this person well, certainly not a cheater.
* -1: saw some behaviour from him thats unlikely to be legal, but I am not 100% sure he is cheating
* -2: 100% sure a cheater.

Using those grades on someone because you like them, or want to play with them would be abusing the system as it isn't talking about liking, or enjoying play with them, just if they cheat or not.

If you don't disagree, I probably just got the wrong end of the proverbial stick.

reply to this message

#33: Re: I think we have a winner

by oranjia on 09/24/2006 20:44, refers to #32

This may seem like a silly kind of comment/proposal but here goes.

Basically, we want to check integrity of the clients code (assuming that he's cheating by editing his source...)

So what we do is swop checksums of the executable file.

So basically the server/master/controller asks anyone who joins to send up their checksum or something and if the numbers don't match they get booted.

I guess if the server is reputable, there is no (easy moderate ) way to get through -- you cannot send a fake checksum when you don't know what the checksum is.


Here's the thing - the checksum function is given by the creator of the game, and will be randomized. So not only do you not know the checksum, you also don't know how its calculated.

so to finish off here's my silly protocol:

Client says hello to server
Server says hey here's a function 5(file.size)+(0.34)(79)
or
5(file.checksum)+(0.34)(79)
or
5(file.checksum_of_first_x_bytes)+10

[[note: I like that last function alot]]

The client then calculates it sends the checksum up

Server then authenticates it...

Any thoughts?

reply to this message

#34: Re: I think we have a winner

by Gilt on 09/24/2006 20:58, refers to #32

use case 1:

bob is playing a game with fred. bob sucks, fred is great. neither are cheaters. fred ownz bob really badly. bob thinks fred is a cheater and puts him on his ban/cheater list.

use case 2:

julie is playing a game with george. julie is an good player. george is using a wall hack and aimbot. they have a fun game. julie puts george on her buddy/non-cheater list.



are bob and julie abusing the system? how can we tell? does it really matter?

reply to this message

#35: Sounds Good

by Rob J. Caskey on 09/24/2006 21:23

Aaard - I'd say simplify. Friend should be a binary choice, defaulting to off. This should help people issue more accurate certs. Let age of an assertion count positively in the metric. Negative certs are likely to confuse people into thinking they are actually doing anything long-term to help the problem. I don't see much benefit added from additional granularity. Also, using a flow network and opinion sharing would solve the outline posted in use case #35, but that gets awfully complex.

reply to this message

#36: Re: I think we have a winner

by StillPeter on 09/24/2006 21:44, refers to #34

For the sake of brevity.

Bob is fine, because he thinks the other is cheating. If Julie knows George is cheating, yes, she's abusing the system by deliberately flagging a cheater as trusted to not cheat.

Moderators will look into it and others can flag correctly - "democracy", remember. Of course it matters, people being effectively banned because they're good is *exactly* what cheaters want, they want to look good to other people, part of doing that is booting off players better than they are.

reply to this message

#37: Re: I think we have a winner

by Gilt on 09/24/2006 22:53, refers to #36

there are not going to be any moderators. and there's no practical way for julie to know if george is cheating or not.

Ron @36 has the right idea. flaging cheaters is effectively useless since any smart cheater will be anonymous. This is more about generating trust and identity among the good players.

I think in practice most players who play for a while will have less then a dozen explicit friends in their DB. But as time goes on they'll probably end up having dozens, maybe hundreds of people tacitly logged as 'probably decent'.

so when one of those 'probably decent' people come along that you played with months ago (but have long since forgotten), your client will still remember that he was alright, and will give an ok. that's going to be one of the real strengths of this design that makes it much better then just a regular private server.




in terms of techinical implementation, I'm personally going to push for the 'trust formula' each client uses to be written in cubescript. that way it can be easily customized and changed as the situation merits (more lenient when lacking players to play with, or stricter when there are lots of cheaters etc).

reply to this message

#38: ..

by pushplay on 09/25/2006 00:13

I've been thinking this over in the back of my head. The problem with this system is how often do you see the same players? Maybe I just have a poor memory but I got the feeling I was almost always playing with new people.

I think the system is stronger with community maintained lists of trusted and untrusted people. For instance someone could keep a list of community contributors so I could have Gilt in the trusted list without recognizing him online. This can be as simple as a manual copy and paste operation as long as the file format allows it and Sauer can deal with potentially contradicting data.

reply to this message

#39: Next candidate..

by eihrul on 09/25/2006 01:54

Found a public domain implementation of elliptic curve cryptography that seems simple enough:

http://www.george-barwood.pwp.blueyonder.co.uk/hp/v8/pegwit.htm

If it can be cleaned up/shrunk down enough and the algorithm isn't too dated, it seems like a good choice.

re: pushplay
If we can manage to make public key crypto work (read: I can find a simple enough implementation), then all you would have to do is include a list of public keys to make that work.

Of course, if we have to go with some hash-based solution like Eivets suggested above, that sadly would not be possible...

reply to this message

#40: Re: Next candidate..

by pushplay on 09/25/2006 02:11, refers to #39

Yeah, I've been assuming some kind of public key crypto.

reply to this message

#41: Re: ..

by marcpullen on 09/25/2006 04:35, refers to #29

The hackers will be on the same server cheating against each other. Honest players go to another server and take it over.

You could go a step further and make it so the owner of the actual physical server can be a moderator and watch the votes like a judge, players being the jury. The players vote and the moderator makes the final decision.

Could also do something like ebay, where other players vote for a player and some master server, or even just the server they are on tracks if they suck or not. So you can see if they cheat or are just jerks. That would be harder to do since tracking things requires some kind of controlled ID (ip, username, etc).

reply to this message

#42: ..

by StillPeter on 09/25/2006 08:15

Um, okay, who actually read the whole page that was linked to in the original post?

reply to this message

#43: Re: Next candidate..

by StillPeter on 09/25/2006 08:24, refers to #39

Plain old GPG? (http://www.gnupg.org/)

You could set it up for the user using a bash script in Linux and a bat file in windows and whatever Macs use for that OS set. That way it would be sauerbraten asking for a password on first run.

Even has a trust system build in, not that you have to use it, could be useful?

reply to this message

#44: Re: Next candidate..

by eihrul on 09/25/2006 08:46, refers to #39

Okay, I've got a port of Pigwet in about 600 lines of code. That may be reasonable, although Aard may think it's too much. We'll have to see. ;)

reply to this message

#45: Re: Next candidate..

by eihrul on 09/25/2006 08:48, refers to #44

Er Pegwit, but same diff.

reply to this message

#46: Re: Viva la wikipedia!

by SleepwalkR on 09/25/2006 18:48, refers to #19

eihrul, what about the Diffie-Hellman Key Exchange + that protocol you found? You can use DH to securely exchange the key for symmetric encryption.

Lookie: http://en.wikipedia.org/wiki/Diffie_hellman

Not sure if there is an implementation available that you can use, but the DH exchange itself is pretty simple. I think the problem is generating primes that are big enough not to be easily cracked.

reply to this message

#47: Re: Viva la wikipedia!

by Eivets on 09/25/2006 20:25, refers to #46

Diffie-Hellmann does not improve anything here. If you use your private key to encrypt a challenge and the other one uses your public key to decrypt and see, if the result is correct, this is enough. The only thing which is not good is, that when you first learn the public key of someone, the server could fake it, which is a man-in-the-middle attack.

That means, that the owner of the server could impersonate people, but only in front of others, which learned the public key of that person on their own server. Other people can still find out, that this is not the one he claims to be.

Anyway, Diffie-Hellmann is also vulnerable to man-in-the-middle attacks. So it does not improve things at all.

reply to this message

#48: Re: Next candidate..

by Eivets on 09/25/2006 20:28, refers to #45

pegwit seems to be okay. SHA-1 is known to be broken, but I don't think, the script kiddies will use sophisticated crypoanalysis with a lot of computing power to break it!

The only caveat might be the export regulations...

reply to this message

   Board Index