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, 16773 views, last view: 05/18/2024 21:47

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   

#18: Viva la wikipedia!

by eihrul on 09/23/2006 22:20

http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
http://en.wikipedia.org/wiki/XTEA

I think we have ourselves a winner. Sure, it has weaknesses, but damn is it small and simple. ;)

reply to this message

#19: Re: Viva la wikipedia!

by eihrul on 09/23/2006 22:35, refers to #18

Doh, it's symmetric only. Live and learn. :(

reply to this message

#20: Re: Viva la wikipedia!

by Eivets on 09/23/2006 22:43, refers to #18

Aeeh, don't want to poop at your party, but this is a symetric cipher, which is not exactly suited for public key,
I think :-(

All public key encryptions I know of require mathematics with huge numbers, which is not really trivial to implement.

reply to this message

#21: ..

by StillPeter on 09/23/2006 23:48

I say:

Give it a try.

Concerns would be.

Politics, if you plain don't like someone, or what they say, you get your friends to 'not trust' them. The moderator idea is good and the countering methods outlined are good though.

Losing ID on upgrade, bound to happen, maybe there should be an installer, which leads me to my next point.

CVS users, they cvs up, re-compile, and join, they start with more ammo due to a tweak and are instantly branded as cheaters.

reply to this message

#22: ..

by Passa on 09/24/2006 02:04

"The intended usage is blocking whole ISPs, not just one IP, so this would be a rather extreme measure."

I do hope it does not get that drastic.. I'm pretty sure I've seen cheaters on my server from the same ISP as me.. and for example, if a cheater is from Telstra (Australia's shittest and largest ISP) then all future players from Telstra cannot play. You would quickly lose player numbers.

reply to this message

#23: I think we have a winner

by Gilt on 09/24/2006 02:32

I am completetly for this.

Really this whole issue is not about cheating. It's about being able to play with the people you like, and not playing with people you don't like. and being able to do that without a completely isolated private server.

So along with the usual concepts of public and private games, this is just the adding of semi-private/semi-public, or I guess, "protected" games.

And it's conceptually very simple for the end user. Basically the only additions from a user perspective is the addition of a 'buddy list' and a 'ban list'. I think even a complete newbie can understand those concepts. Everything else can be handled silently by the game. Various actions like kicking or not kicking for a certain period of time, can even be hooked to implicitly modify the trust values of each relationship.




I didn't really like the other centralized systems since it makes the issue about cheating, and assigns an absolute trust value, rather then this relative trust value. There's just a lot of problems with absolute trust, including the need for central admins, moderators, and also 'trust wars' / false accusations. In this system each player is their own admin and mod, and trust wars are actually somewhat desirable.

The newbie problem will always be a problem, but at least this system does two things:
1) it pushes the choice of helping newbies to each individual player. that's alright since it does no good to force people who don't want to play with newbs to play with newbs.
2) it allows newbs to form their own 'communities' if the established ones are too closed off.


You guys can argue about the technical details, but design wise, this is the way to go for a project like this.

The only issue is that griefers might target the other public resource we have, the servers. Trying to take control of all the servers and stuff like that. As well, knowing server admins, I bet they'd also want servers to have their own personal 'buddy' and 'ban' lists; which would be the solution to that problem and something worthwhile in the long run.

reply to this message

#24: ..

by Max of S2D [Fr] on 09/24/2006 08:06

I understood nothing. @_@

reply to this message

#25: Re: I think we have a winner

by StillPeter on 09/24/2006 10:47, refers to #23

Actually, it is about cheating. Its not going to stop someone better than you kicking your ass, or being against someone who isn't nearly in the same league as you. You'll have to go elsewhere, wait for them to, or visit the same server as your friends regularly as before.

reply to this message

#26: ..

by marcpullen on 09/24/2006 16:23

If we wanted to keep things simple, why not just tweak the kick code/function so players can kick a user and/or ban a user from a server?

So if 5 people are playing, and one has a hacked/cheat version, the other 4 have a vote (same as voting for a map), and they get kicked from the server if all 4 agree. Kick is for that session, ban is for the life of that instance of the game running (e.g. stop and start the game server to clear the ban list), or provide a function/command to flush the ban list.

That would give the power to the people and would keep things decentralized.

reply to this message

#27: Re: I think we have a winner

by Gilt on 09/24/2006 16:26, refers to #25

umm... it's not magic. if you want to play with your friends you still have to go the same server.


basiclly it's a pro-active, automatic, democratic kick-ban. it's not necessarily going to protect you from cheaters more effectively then currently. but it can make protecting yourself much more efficient and easier.

reply to this message

#28: Re: I think we have a winner

by StillPeter on 09/24/2006 18:02, refers to #27

Exactly, if you want to play with your friends you still have to do much the same as before.

This solution isn't about playing against people you like and not against those you don't like. 'not trusting' people you don't like would be an abuse of the system.

The idea is to stop people who have cheated from getting on a server in the first place, not to stop people you don't want to play because you don't like them getting on a server - that's what making a server have a private game is for. Stopping those you simply don't like from playing on a server on the masterserver would be an abuse.

It would stop cheaters more effectively than the current method (there isn't one) since they can not go on the server if they have cheated before - so they cannot master themselves on a server and boot all or crash people's clients etc. etc.

It will (hopefully) be a pro-active, automatic, democratic kick-ban of *abusers*, not just people you don't fancy playing against(!)

reply to this message

#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

   Board Index