GUID registration system

[yetshi]

i will pay for GUID

but only if i get a plush granger

and i has to go rawr rawr when you squeeze it :3

[Caveman]

nope, HW-spoof will take less then getting a new IP.
Remember? Tremulous is OSS

[==Troy==]

MD5 checks on the packages and *.exe file? Or just have a source code, not matching with the actual compiled version... jk. Well, its true, till the PC is in the hand of the player, but not the server, noone can do anything. Well, at least 6 byte static IP addresses will help...

[Caveman]

jfyi we do have md5-checks atm.
But who cares? it only takes a 2 liner to spoof it .)

[sleekslacker]

I would pay to get griefers off my back. You are right though.

Who will be the arbiter?
Who will watch the watcher?

We don't want people from FunZone to start banning people left and right. We could have moderators from this forum to admin though . Make it like, Tremulous Official Server #1, #2 and so on. And although it's wise to not trust people you meet on the internet, there are quite a number of people I would put my trust on in here.

Who has the right to mark players so that they are in the DB and are barred from playing?
Who has the right to unmark them?

It should be implemented as a whitelist. Register and you get to play. If you are banned you will be removed from the whitelist ( Maybe put it on a temp_banlist for temporary bans ). So if you want to get unmarked while being banned, you have to pay again.

In any case it's on trust basis. If we could get 1 respectable admin per 16 players, that would be very nice. If you don't think you can trust the admins, don't pay and continue on regular servers.

Just some ideas. Sorry if I seem to be shooting in the dark .

[tuple]

with cl_unique set (if thats the variable, I forget) a server can be relatively sure that another server cannot obtain admin, but there is no guarantee that the any particular connecting admin actually is who they say they are.

What if the server can identify the player by modifying the key received from the player using the players source, class C subnet and use that result to track/assign rights?  Again, that is not a perfect solution, but it would enable a server to identify a player with a greater degree of assurance than presently exists.  Granted, this would only prevent brute force GUID attacks in that a server would be much less likely to have an admin in the same subnet as the source of a brute force attack.  It may become a mess for players whose ISP has a class A or B subnet for their clients.  It may also stop an admin from sharing their key.

It would narrow the window of opportunity.

Centralized banning is a no go.  See Caveman's reasons and then stretch them forward a year or three.  Sure we trust Belier13 to host the DB and control bans, but what about when he turns 12 and passes it along to Apika!?

However, a system that allowed friendly operators to take part in an ad-hoc form of centralization, one that is not required, run by any specific organization/individual  and can be hosted alongside each and every server if the operator so desires may work, if only to share bans.

Centralization, Bad.  Enabling operators to band around a center of their choosing, not so bad.

[Caveman]

Uhm... Sleek, if that is only for one or a few servers, most of these ideas are not needed.
If I understood it correctly this should pertain to all servers.
At least that's why I was asking about the DB and it's entries

[sleekslacker]

Uhm... Sleek, if that is only for one or a few servers, most of these ideas are not needed.

Well, the current private slots and password systems are not very good. Plus, the payment binds the player so he doesn't breach the rules too frequently. In fact, I guestimate each unique griefer will do harm at most 2-3 times before stopping altogether ( running out of money, it's not worth it ).

Imagining in my head right now, there would be 2 sides: regular & paid-for-GUID servers. The regular servers cannot be stopped. Tremulous is open-source and anyone can run their own servers. The payment is there to insure people with good behavior against the bad ones. Also, newbies from regular servers who have seen how fun the game can be might want to play in a less-retarded environment and check out the more secure server.

If you really want to keep it simple without the power abuse issue, the ban can be made local to servers. The player statistics can be kept centralized ( 5x marked as a deconner,3 times kicked for tking structures & team ) and the local server admin can consider if he wants to kick/ban the player or not. This can be simply implemented using scripts and http calls.

We need to keep griefers/aimbotters out of the game. One way to achieve this is to share players' history between servers. And to build this info, first we need to identify a unique player by his ID. The paid-GUID method is one way, imo.

Oh.. a free way to identify players: using fingerprints ^^. idk how long it will take before the griefer runs out of siblings and friends to register a fake id xD.

http://ffpis.sourceforge.net/intro.html

[Caveman]

Sounds nice, but has a serious draw-back.
Who gets the money?
Who does the registering?

Registering by paying for a guid on one server, and expecting other servers to honor this guid?
Come ooooon....
People are greedy and thus they'll be wanting to be payed if they should honor the payed-guid.

Oh and if you pay on one server and expect the other servers to honor it, what's to keep a griefer to set up his own server and fake the payment to get his guids for free?

And most important, what's the incentive to pay for a guid?
This is a free game, after all. And as long as you have free servers you will not draw many a player to pay-servers and I dare say you'll also scare regular players off

Edit:
And I forgot to ask...
Since you ask for money, you have to draw a legal contract where the player will have to be granted specific rights.
And since the player payed on one server, that server will be obliged to cater to that player.
So the saying "my server, my rules" will no longer apply .)

[player1]

truth

QFT!

useful discussion

I think that along those lines, a more configurable frappr may be of use to the community as a whole. I would like to see a version where only servers which are send their heartbeat to the main server are shown (not just a few users). Also, a separate map would show every client who registers a GUID (even server-specific ones?). There would be two maps: servers and clients. A variety of filters could be applied.

On the server frappr:
by ping (two-digit green, 100-150 yellow, >150 red)
by number of playerslots (size of dot)
favorites (map pin)
uptime (shown on pin)
# of incidents/kicks/bans/tks/decons (hover over pin)
QVM/svn/mod (hover over dot)
current map (hover over dot)

On the client frappr: (w/ registered server-specific GUID)
by #/servers lvl1'd (two-digit green, <5 yellow, <3 red)
by playerslots-divided-by-inverse-of-adminlevel (size of dot)
favorites (map pin)
playing time (shown on pin)
# of kicks/bans received (hover over pin)
# of kicks/bans issued (hover over dot)
online status (bright dot)

Ideally, you would be able to connect to a server from the server frappr, and PM a player from the client frappr. The only Trem frappr I ever saw was "post a funny pic" and had, like a guy in Latvia and a guy in Tasmania and a teddy bear in Finland. I think all you l33t coderz with u cred 2 use could produce a useful tool for evaluating some Trem patterns with such a frappr.

[Caveman]

before you start thinking about what you would like to do with ID'ed players, how about we try to stick to the foremost problem?

How to ID players that don't want to be ID'ed and how to circumvent spoofing?!

[tehOen]

[next_ghost]

before you start thinking about what you would like to do with ID'ed players, how about we try to stick to the foremost problem?

How to ID players that don't want to be ID'ed and how to circumvent spoofing?!

I'd suggest not trying to do that in the first place. As you have said, everybody who tries to do that now fails miserably. Even those who make a living doing that. It's much easier and more reliable to go the other way around.

[Caveman]

right

Which means imho that any discussion about getting griefers off a server automagically is useless. I think I already said that ages ago

As for the other suggestions... it all boils down to either public servers with active admins, servers for a closed (registration mandatory / passworded) player-base or unmaintained ones.
Effectively what we already got with server-unique-ID's to ID Players that want to be ID'ed.

The ideas here are not bad, just not really thought through .)

[tuple]

I hope everyone here understands that positively identifying a player %100 of the time is just not possible.

However, we can narrow down the avenues of attack.  Take the players GUID, in this instance we'll say its XXXXXXXXXXXXXXX
Then, take the first 3 octets of the IP the player is communicating with the server with, in this instance we'll say  it's 207.68.173

Mash them together:
XXXXXXXXXXXXXXX20768173

The result, XXXXXXXXXXXXXXX20768173 is used to identify the player.  Hell, have a var that allows the operator to use class B subnets in case its needed:
XXXXXXXXXXXXXXX20768XXX

The result is a number that is partially generated by the client, and partially generated by the network infrastructure(the IP).  With the client creating a hash based on the servers IP, no 2 servers have a unique GUID for the client.  With the server appending the source IP to the GUID, even a hacked GUID would only be useful from a class C subnet (254 usable IPs) or a class B subnet (62000 and something IPs).  Obviously this isn't really true in that 13.23.76 and 132.37.6 would appear the same to the server, maybe replace the . with a lower case c to delineate the octets.

GUID brute force attacks would have considerably less chance of succeeding and the server can be more sure that a player/admin actually is who they say they are.

If you still think I'm sane, follow me while I wander to where fixing an issue this would create (for some) might lead, aside from the mountain off issues I'm sure I'm missing or glossing over

A few ISPs use Class A subnets for their clients, but I don't come across this very often at all.  Still, some admins would find their rights getting screwed up at times.
So, the admin goes and logs onto the forum for the server while connected to the trem server and clicks a button.  The forum software has authenticated the user and knows their IP.  Using pyquake and python, (only scripting lib for quake I know of right now) the forum server determines which slot on the server the admin is using by comparing the IP connected to the forum vs the IP connected to the server and grants that slot the Admins pre-assigned admin level and presto, the Operator has successfully avoided that nasty work thing!

[sleekslacker]

Sounds nice, but has a serious draw-back.
Who gets the money?
Who does the registering?

trem.net
The notion that the devs are being paid for their hard work is a nice thought.

Registering by paying for a guid on one server, and expecting other servers to honor this guid?
Come ooooon....
People are greedy and thus they'll be wanting to be payed if they should honor the payed-guid.

solution A:
The server owners have the decision whether to use the information or not. We don't expect them to honour the guid.

solution B:
All paid-GUID servers are set up by trem.net (aka official servers), and a standard policy is maintained across those servers.

Oh and if you pay on one server and expect the other servers to honor it, what's to keep a griefer to set up his own server and fake the payment to get his guids for free?

The multiple front-end idea is rubbish, yes. The players' data should be stored by only one party, whom will receive the money. The data is then accessible and writable by server admins (indirectly).

And most important, what's the incentive to pay for a guid?
This is a free game, after all. And as long as you have free servers you will not draw many a player to pay-servers and I dare say you'll also scare regular players off

The devs get the money for what they have put effort in. Although they might have not started the game because of money, it's still a nice way of saying thanks.

Also, if the paid-GUID servers really works in keeping griefers out of the game, I am sure a lot of players would pay a comfortable amount to get in.

Edit:
And I forgot to ask...
Since you ask for money, you have to draw a legal contract where the player will have to be granted specific rights.
And since the player payed on one server, that server will be obliged to cater to that player.
So the saying "my server, my rules" will no longer apply .)

By paying for the GUID, the player is given access to a set of servers, and his own game statistics is stored by a central server. Server admins have the right to keep out certain players out of their own server based on the player's statistics. Example:

Player1:
-marked as deconner : 5 (times)
-teamkills : 13
-total ban by admins : 18

Server1:
-max_decon : 10
-max_tk : 10
-max_ban : 20
Player1 is not allowed in this server.

Server2:
-max_decon : 10
-max_tk : 20
-max_ban : 30

Player1 is allowed in this server.

The matching criteria can be custom-scripted for each server. We should also be able to turn off automatic matching and let admins request a player's stat with the GUID and decide on their own.

[Caveman]

That is all nice, But places the Devs in debt to the players to have actually some of those servers up and running.
Which would mean that besides developing they have to admin those.
Even if they found some Admins they trust, for how long would the guid?

Oh and like you said only "certain players" are allowed to be barred entry...
That would mean as soon as I accept those bought-IDs I can no longer make the rules for my own server

Trust me on this. If you force server-owner to accept any set of rules by which they can only regulate their server for which they pay, they will not keep them up.

That leaves the DEVs (who get the money) to maintain the servers and doing that with the fee for guid is out of the question, even if they wanted to.

[Caveman]

... 13.23.76 and 132.37.6 would appear the same to the server...

It would, if you use the correct way...

013.023.076 != 132.037.006

[sleekslacker]

That is all nice, But places the Devs in debt to the players to have actually some of those servers up and running.
Which would mean that besides developing they have to admin those.
Even if they found some Admins they trust, for how long would the guid?

Well that's one of the solution, if the devs would like to admin and maintain the system themselves. The other one I gave (solution A) is for server admins to implement their own rules and admin themselves. All trem.net has to do is maintain the GUID-DB server.

Oh and like you said only "certain players" are allowed to be barred entry...
That would mean as soon as I accept those bought-IDs I can no longer make the rules for my own server

Server admins can make up their own rules and apply it to their own server. "Certain players" there doesn't mean across servers (although server admins can do so if they want ). The advantage provided by a paid-GUID system is that it can delay a griefer from assuming another identity & joining the game repetitively.

I think that's the end of my thoughts on this one. In short,

There are 2 different parts in the system:

1) Paid-GUID for unique ID per-player ( it's easy to buy a new ID but your cost increases linearly )

2) Unique ID across servers. Any kick/ban action can be sent to the central GUID server. Server admins can do what they want based on the player's data.

3) IF.. If there is a server-side demo recording feature, all the better for handling disputes.

Consider it like paying tax to have police in your community. Hmm, maybe some people prefer the anarchy.[/quote]

[player1]

before you start thinking about what you would like to do with ID'ed players, how about we try to stick to the foremost problem?

How to ID players that don't want to be ID'ed and how to circumvent spoofing?!

I agree with you, I don't think it can be done. A Tremulous client frappr would be totally voluntary, and probably devolve rapidly, but perhaps it would help us to make some decisions as to subnet bans, the Poland question, and triangulating griefers. It would be a place for known players who want to be known, and serve almost no purpose in identifying the evil amongst us.

It might be a nice tool for allowing known (and knowable) players to contact one another, set up games, make internet friends, etc.

The server frappr would be a place to visually reinforce the server list in a geographic fashion, with those "closest" to the player shown as such, and those which have more playerslots represented as "bigger".

I just think you have a better chance of creating something like this than a GUID registration system which shares info across many servers. Players would have to register their GUID voluntarily, for each server they have admin status on. It's probably not any more useful than the other ideas proposed here, I just like the idea of a graphic representation of the server list and client base.

[/dev/humancontroller]

What's up with the Q_isdigit(), etc.? What about the standard isdigit(), etc.?

[I let my dog hump my leg]

What's up with the Q_isdigit(), etc.? What about the standard isdigit(), etc.?

dude...

[kevlarman]

What's up with the Q_isdigit(), etc.? What about the standard isdigit(), etc.?

repeat after me...

qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt

repeat that every morning for a month and you might figure something out.

[/dev/humancontroller]

repeat after me...

qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt

qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt
qvms don't get linked against the crt


uhm...
# while [ 1 ] do echo "qvms don't get linked against the crt" > /ppl/kevlarman &

repeat that every morning for a month and you might figure something out.

I still don't know if I'm onto something.



I don't know why I haven't noticed this thing yet. Maybe it's because my pro compiler pwnz your compiler, and qmvs do get linked against the crt. isdigit(), etc. work.

[/dev/humancontroller]

Maybe it's because I use DLLs. :wink:

[I let my dog hump my leg]

Maybe it's because I use DLLs. :wink:

that is not an option for others so what you say fails Q_isdigit() exists for some reason
if you cant tell why please stop coding

[FooBar]

I've been thinking about this for a while, although my time available these days for active programming is rather low.  I have a couple of questions:

1. When Trem 1.2 comes out, will it have GUID enabled by default? If not, it should.  Although it's relatively easy for users to change GUID, it at least means that every player would have a semi-unique identifier whenever they're playing.

2. Has anyone considered changing GUID to be an implementation of PGP / GPG?  This would eliminate the spoofing problem, since it can be undeniably established whether a client legitimately owns a public key.  The GPG libraries are open-source.

I believe that eliminating spoofing and making GUID the default would solve or ease many of the griefer problems seen today, when combined with good adminship.

I suppose there might be an international distribution problem if GPG is used.  What do you think?

[Caveman]

Foobar, you miss the point.

PGP/GPG does not provide anything towards the goal to ID player that do not want to be ID'ed.

As for the rest of your post... well the answer was already given and is topic of another thread.

[FooBar]

Caveman, you are most helpful.  Would you condescend to point me in the direction of the other thread, where (I assume) the issue of default GUID has already been dealt with?  Many thanks in advance.

Although its application is broad and not strictly limited to this topic, the GPG idea is quite relevant here.  Its goal is to prevent spoofing, not to "ID players that do not want to be ID'ed."

The motivation: let's assume you have a global (not server-local) GUID registration system.  If a player goes to a malicious server, that server admin could easily steal their ID and go to any other server and spoof it.

Any GUID registration system must necessarily have some kind of bulletproof encryption or password system, otherwise you will quickly get spoofers and then you're right back where you started.

There are other good arguments in favor of GPG, but that's the idea that's relevant to this topic.

[Caveman]

Foobar check any thread pertaining to 1.2 .)

And gpg / pgp is still useless as this does something quite opposite to what we need. It only proves that someone is who they say they are.

And as I did point out (quite often) there is no way to ID someone against their will and that is the whole point here.

ID'ing for admin-lvl on servers is a done thing, see server-unique-guids for that we need no gpg/pgp and spoofing is not really possible with that guid