Tremulous Forum
Community => Servers => Topic started by: next_ghost on September 10, 2007, 10:22:29 pm
-
I've been coding for a few weeks (and some university credits) and the result is a simple GUID registration system. Main features:
- automatic GUID registration and re-registration, good bye manual GUID changes!
- simple network banning in Tremulous server, GUID registration overrides network ban
- up to 131071 unique registrations (takes 3MB of hunk memory), may be changed at will as long as the number is prime greater than 256.
- fast hash table registration lookup, perfect replacement for current slow admin level search
It's far from completion (and not recommended for noncoders yet). I'll post more details tomorrow. For now, you can take a look here (http://www.ms.mff.cuni.cz/~doucm6am/). The patch is written for SVN871, I'll modify it for current SVN later.
-
we can store guid's in a database
-
This BS takes care of the server-unique-GUID and the none-guid-using-fakers in what way?
Sheeesh, for someone that has some university credits you sure have no real clue.
-
we can store guid's in a database
Oh cool! And what are going to do with them to keep DHCP griefers off of you server? :roll:
This BS takes care of the server-unique-GUID and the none-guid-using-fakers in what way?
GUID registration is per-mod. If you want to run multiple servers using the same mod directory, it's not that hard to add a few cvars to set file names and have multiple registration lists in one directory.
No GUID = no connection from banned network. The permission test looks like this:
- Does the player have a GUID?
- No => Is the player connecting from banned network?
- No => Let them in
- Yes => Kick them
- Yes =>
Is there a registration request for their IP?
- Yes => Register them and let them in
- No =>
Is the player registered?
- Yes => Let them in
- No =>
Is the player connecting from banned network?
- Yes => Kick them
- No => Let them in
-
erm you query the database for the guid ok? you can also store admin privileges
what is the problem with it?
-
erm you query the database for the guid ok? you can also store admin privileges
what is the problem with it?
Response time. 'nuff said. :roll:
-
ugh you can import the stuff at server startup
-
ugh you can import the stuff at server startup
Then you end up doing the same thing I have already done.
-
cooler than your poor text file
-
No GUID = no connection from banned network.
This is where the shit hits the fan.
As long as the GUID is not included in the stock client you will have to ban by subnets, thus killing loads of innocent players.
Come up with a better system that has not been discussed already.
-
This is where the shit hits the fan.
As long as the GUID is not included in the stock client you will have to ban by subnets, thus killing loads of innocent players.
Come up with a better system that has not been discussed already.
When you get kicked because you're not registered and you connect from banned subnet, you'll get a message which says "Please register at foo.com/bar" (it'll be set using a cvar). All you need to do is writing a huge red text saying "You need this client to register (link)" on your website.
-
Unless we have a means of identifying the registered entry/GUID to a unique person, this is still useless. In countries where the citizens each has his own National Identification Code, this is a possible solution.
Another way that has been discussed before is to delay the griefer each time his action is noticed. Activation by email can easily be circumvented. Someone ( BIG ) suggested a fee-per-registration method. Honestly, I think this is the best solution. I sure hope that if there is a surplus from that money, it would go to Mr Tyrant & Tyrantina plush toys for everyone :).
-
Unless we have a means of identifying the registered entry/GUID to a unique person, this is still useless. In countries where the citizens each has his own National Identification Code, this is a possible solution.
Another way that has been discussed before is to delay the griefer each time his action is noticed. Activation by email can easily be circumvented. Someone ( BIG ) suggested a fee-per-registration method. Honestly, I think this is the best solution. I sure hope that if there is a surplus from that money, it would go to Mr Tyrant & Tyrantina plush toys for everyone :).
We could use invite system like Gmail did. It's easy to keep track of invites and if somebody keeps inviting anyone who asks, simply revoke their invite rights.
-
try to to think more realistic
-
Its unfortunate that everyone bitches about the GUID system, then bitches about anyone trying to do anything about it. I wouldn't say that this is complete, but it certainly brings some interesting things to the table. Do any of the complaining coders here realize that a successful identity system for trem will most likely not be built by one person, but will be assembled by pieces from numerous devs? Please note that by successful, I do not mean that it does everything and makes toast for you.
The ability to do a subnet ban without locking out established players is a nice advancement, I'd say. As well as multiple local servers being able to point to the same data. Also, using hashed data to speed up the connection probably won't make a difference tomorrow, but may in the future as it grants someone else cycles to build into.
Individuals using the stock client will still be able to connect to most servers, noone with a brain is banning class A networks (Though I'm sure someone will bring up a specific instance of class A banning now.)
Subnet bans are the most effective defense against griefers who've figured out DHCP, and subnet bans are used pretty heavily already. This is the first thing I've seen that would allow players from banned subnets to join (not counting the great firewall of poland :P ) Aside from possibly being more informed as to why they are banned, stock clients are no differently affected than before, other than at least having the possibility of joining the server that they are subnet banned from, which they presently do not have.
No, it won't make a cake, but at least someone is starting to put the ingredients together.
Such a system cannot be made to be perfect, but it can be more flexible than the present system while still maintaining its present level of security. You don't like its level of security? Quit bitching and do something about it.
-
Like I said, as long as the stock client does not have any guid system, all this thinkering is useless.
And tbh here is nothing new. Circumventing the sub-net ban with the guid has already been discussed and i faintly remember there to be a patch for it somewhere around.
Secondly what good does this system do when it is only used to communicate between local instances of the server?
The point is to cut down on grieving on the servers, therefor you'd need to come up with a way to communicate with other non-local servers. And that leads us right back to the failed attempt to build a DB that has all the data. I wont even mention the danger of false positives or worse, the wrong negatives.
So unless there is a way to really identify a single player across servers (again: NOT by IP) and a system that gives trustworthy warnings all this bickering is fruitless.
Heck, have a look at PunkBuster, they do that shit for a living and yet they fail miserably.
Don't you guys think that if id'ing a single player is possible, that we'd already have such a system somewhere around?
-
While I agree that we should stop bitching at whatever ideas thrown at us ( some of them are pretty good ), it is still unclear to me how we can proceed from this work.
An invite system will keep a lot of new users out. The distribution of invites needs to be controlled and who do you trust that part of the system to ? The luser. Great. And there is also the 'not enough invites' issue plaguing Gmail (in it's early stage) and Demonoid.
What would be great is to come up with a viable solution, get at least 50% (75% is preferable) of the community to agree with it, put down a roadmap/todo list for the project completion, and write down the part that you are doing.
-
tuple: Bans don't use default network mask. Actually, you can set any mask you like from /32 (single IP) to /0 (none shall pass! :wink:). I was also planning to implement wildcard masks so you can for example ban 123.45.67.89 with mask 255.0.15.98.
Caveman: Current systems fail because they can't point J. Random User to get backport client. This system will point them to your website which will in turn point them to the client. They get the client, they register and everybody is happy. Except griefers of course :D
sleekslacker: There's no point in limiting invites. Either you're trusted and you can send as many invites as you want or you're not and you can't send anything. Anyway, you can do anything you like on your website. There's no registration front-end yet, just two example Linux apps that write server configuration files properly.
-
next_ghost.
Your statement is plainly wrong.
a) the bug where the ban-msg is displayed only once upon a reconnect is still in play
b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.
c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.
d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.
e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)
f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?
f) are you sure with your subneting? ;)
g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.
h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.
Last but not least.
Before we go on about how to register and to keep griefers away, we should stick to the first point. The one on which everything builds...
A failsafe way to ID a player, one that can not be spoofed.
Until this is done in at least a rudimentary way, all further discussion is really pointless.
-
I highly doubt that there is a viable solution that will work for all servers. The solution is not to recreate punkbuster or some OSS bastardization of it, the point is to give servers tools that they can use as their particular circumstances need.
Each individual tool can and will be shot down as ineffective for countless reasons as there is no monolithic solution that will fit all servers. However, that does not mean that individual tools cannot be combined to create individual solutions to fit the needs of each server.
Would servers benefit from having local communications of this sort? MG could benefit from it right now. PT2 starts up when PT is full, having this data be synch'd between the two would be a benefit. Can this code be modified to synchonize between disparate servers? Between a central server? If it could, could that server act as its own central repo and offer it out to other servers? This tool may be a big hammer, can we use a chisel to create a different tool out of it?
It is not possible to have a reliable identity infrastructure based on GUIDs. However, the GUID/IP combo is stronger than you may think. Consider only allowing a particular GUID to have admin when coming from a particular subnet. Again, you cannot rule out malicious activity, but it would greatly complicate the tasks of the GUID harvesters and GUID brute force attacks.
I'm sure that I could not even begin to envisage the little tweaks that could benefit various servers out there, but put all together those tweaks would very likely create a useful and powerful toolset. That toolset will never exist if everyone keeps pointing out that each tool will not create a monolithic solution.
-
a) the bug where the ban-msg is displayed only once upon a reconnect is still in play
Subnet ban in my system is completely independent on any prior banning code. /reconnect or anything similar doesn't let you in.
b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.
It takes at least one map reload before new registration requests are loaded. And if there're invites, it takes much longer before they get an invite (if they ever get one).
c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.
95 out of 100 players WON'T get caught.
d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.
That's the point. If they don't want to be identified, they won't get in. :D
e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)
To keep morons out, not to limit number of registered users.
f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?
Registration is not required unless you're connecting from a banned subnet. Again, unless you ban 0.0.0.0 /0, 95 out of 100 users won't even notice there's some registration thingie on the server.
f) are you sure with your subneting? ;)
Yes I am. Wildcard masks are commonly used except sometimes they're inverted to add some "fun" to configuration.
g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.
Hello? Do you ever read or do you just drool on your keyboard? THAT'S WHAT I HAVE WRITTEN!
h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.
You didn't bother to download anything from that link, did you?
-
tuple, I agree with you :)
But that is because you seem to take only the player in account that want to get ID'ed and those are not a problem.
Also narrowing the permission down from a subnet is a nice idea, even though I can only envision strange circumstances where this would be needed with the server-unique-guids.
The problem is to keep the server public as possible while at the same time ID'ing players that don't want to be ID'ed.
Mandatory registration will lead to less players if not _all_ server use it and to get that...
Making data available for more than one local server has also been discussed before and dismissed as being undoable as it requires a heavy rewrite of the engine, due to the way the server handles it's confs.
If you really want a chisel, then there'll be no way around an active admin, as ID'ing an uncooperative player is impossible.
And forcing uncooperative players from ones server automagically can only be done by brute force with loads of collaterals.
-
a) the bug where the ban-msg is displayed only once upon a reconnect is still in play
Subnet ban in my system is completely independent on any prior banning code. /reconnect or anything similar doesn't let you in.
That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".
b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.
It takes at least one map reload before new registration requests are loaded. And if there're invites, it takes much longer before they get an invite (if they ever get one).
Sorry, but that will only help you for exactly one game and then?
c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.
95 out of 100 players WON'T get caught.
See my point a) you plan on telling those with the ban-msg that they need the backport (and/or the registration) and they get that for exactly 2 seconds before the bug kicks in and they are left clueless as to why they can not connect.
d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.
That's the point. If they don't want to be identified, they won't get in. :D
Then why not use the Password-feature?
Players from a banned subnet will not get your msg due to the bug and only your regulars will care enough to actually register other players have incentive to do so.
This WILL solve the griefer problem on one server, yes...
Then why not make it more simple?
Just expand the PWD-feature to accept multiple Passwords which you hand out for every player that registers somewhere. So no need to tinker with guids and such, if one of those does grieve then just revoke his PWD and you are all set.
e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)
To keep morons out, not to limit number of registered users.
That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.
f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?
Registration is not required unless you're connecting from a banned subnet. Again, unless you ban 0.0.0.0 /0, 95 out of 100 users won't even notice there's some registration thingie on the server.
And again, the Bug from my point a) hits.
g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.
Hello? Do you ever read or do you just drool on your keyboard? THAT'S WHAT I HAVE WRITTEN!
Hello? you actually let a user modify the iptables? Or do you mean to tell us that you let the tremulous server runs as root?
How sweet of you to tell us your scripts are useless :)
h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.
You didn't bother to download anything from that link, did you?
[/quote]
Nope, as all third party apps that are not in the server-code are unusable. And there is just no way for me to let iptables fall under the rule of any user-script, just as there is no way I'd start any game as root.
Like I said "beware of the security issues" .)
-
That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".
Ahh, THIS bug. We'll just fix it then.
That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.
Rule: don't give invites to anyone you don't know personally. If you do and they get banned, it'll be the last time you've sent invite to anyone.
Hello? you actually let a user modify the iptables? Or do you mean to tell us that you let the tremulous server runs as root?
How sweet of you to tell us your scripts are useless :)
No, I have written code that does the same thing as iptables inside Tremulous server.
-
That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.
Rule: don't give invites to anyone you don't know personally. If you do and they get banned, it'll be the last time you've sent invite to anyone.
And then you finally have closed player base :)
-
That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".
Ahh, THIS bug. We'll just fix it then.
I am pretty sure this is a matter of the client CONTINUEING to try to connect even after it has been denied. A fix would require a client-side modification, probably to the client code itself.
I just had a thought to redo the guid creation system. Get all the information you can about the hardware--speeds, capacities, serial #s, and anything else--and put through the guid-creator thing with the server's ip at the front. Result = a computer and server specific guid. Only problem would be if any parts get replaced.
-
All reasons in g_client.c:ClientConnect are clearly kicks, not connection delays. I'll add a little change of SV_DirectConnect to drop client with reason instead of letting them wait when QVM says no.
OR we could simply move the ping test after all other tests.
-
Get all the information you can about the hardware--speeds, capacities, serial #s, and anything else--and put through the guid-creator thing with the server's ip at the front. Result = a computer and server specific guid. Only problem would be if any parts get replaced.
Still not convincing. The GUID produced using that method can be faked, although probably 90-95% of individuals wouldn't be smart enough to do that. On another look, this fails to identify multiple players on the same computer. Here, let me remind you of Evlesoa and his evil brother. In any case, the 5-10% smart-alex still have a chance to wreck havoc repeatedly once they discover how to fake the GUID.
I really like the idea of delaying these MOFOs instead of trying to totally get rid of them. The latter is impossible, in my opinion.
How it works:
1) All servers can optionally choose to use the new GUID database.
2) Servers using this DB will send any ban info it makes to the GUID server.
3) Each GUID entry may be generated using any front-end ( clan websites, other forums ). However there is only one GUID database server. The front end will forward the user information to the central server and the database change is reflected. Verification at the central server might be crucial.
And what Caveman said,
The one on which everything builds...
A failsafe way to ID a player, one that can not be spoofed.
is definitely a very important point. I would like to stress what I said earlier: fee-per-GUID is a good idea. If someone is willing to fork out $10 for 5 minutes of griefing, every time, then let him pay for his stupidity. Perfect player identification might seem unrelated to fee-per-GUID. I don't really understand what's between the two either.. but I think it has something to do with people not giving their ID just like that because he is the one paying if anything happens. Hooking someone's neck with money is usually a good security :).
-
For the sake of argumentation, lets say there is way of ID'ing a player.
That leaves us with the problem that eg PunkBuster has.
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?
Who will be the arbiter?
Who will watch the watcher?
Oh and before I forget to ask it (again) who actually wants such a server?
I am not alone when I say that we will never adhere to bans coming from a central server...
-
maybe make it easier a bit? identify a computer that is used, not the player. Hardware bans, as it is called. Yes, I know that they can be easily spoofed as everything else :roll: but that is at least something else a player has to do other than find a proxy and change his guid (first one is done in 5 mins, second one in 5 secs, hardware spoof will take about half an hour)
-
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
-
nope, HW-spoof will take less then getting a new IP.
Remember? Tremulous is OSS :)
-
MD5 checks on the packages and *.exe file? :D 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...
-
jfyi we do have md5-checks atm.
But who cares? it only takes a 2 liner to spoof it .)
-
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 :).
-
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!? :P
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.
-
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 :)
-
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
-
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 .)
-
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.
-
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?!
-
(http://img510.imageshack.us/img510/8176/lolzorsll0.png)
-
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.
-
right :)
Which means imho that any discussion about getting griefers off a server automagically is useless. I think I already said that ages ago :D
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 .)
-
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 :P
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!
-
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.
(http://img452.imageshack.us/img452/1086/g3150wh0.th.png) (http://img452.imageshack.us/my.php?image=g3150wh0.png)
-
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.
-
... 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
-
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]
-
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.
-
What's up with the Q_isdigit(), etc.? What about the standard isdigit(), etc.?
-
What's up with the Q_isdigit(), etc.? What about the standard isdigit(), etc.?
dude...
-
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.
-
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.
-
Maybe it's because I use DLLs. :wink:
-
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
-
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?
-
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.
-
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.
-
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 :)
-
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.
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 :)
Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.
-
Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.
Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.
If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.
-
just to save Caveman from having to constantly repeat himself:
YOU CAN'T ID PLAYERS WHO DON'T WANT TO BE ID'd!!!
outlawing guns means only outlaws have guns
-
If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.
If you'd actually read my post then you'd notice no implication of such a possibility. What I was for is a GlobalUID system for those players that want to be positively identified, in place of the Server-Local Unique IDentifier.
Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.
There's never a problem if you're working around it actively.
-
Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.
If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.
Until then it's just half baked BS that is not needed and more work than it's worth.
-
Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.
If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.
Until then it's just half baked BS that is not needed and more work than it's worth.
I see you have no idea how an RSA challenge-response system would work. The private key or hash thereof is never sent to the server. There is absolutely no way to steal the private key short of actually hacking the client.
Background:
RSA is an asymmetric key system, where you compute a pair of keys, and you can encrypt stuff with one key that is decryptable with the other.
It works like this:
- client sends pubkey to the server, that becomes the users GUID
- server sends a randomly generated challenge string to the client
- client encrypts the challenge with privkey and sends the response to the server
- server decrypts the response with pubkey and checks if it's identical to the challenge string, doesn't let the player in if they differ
The privkey is never transmitted, there is no way to infer privkey from pubkey in reasonable time, or compute a new privkey that works with pubkey. You can't just spoof the pubkey because no server will let you in. You can't spoof the privkey because you don't have it.
This is the simplest scenario, a scenario hardened using common cryptographic practices would work very similarly though.
-
19:14 kevlarman> timbo, would you be against adding something a bit more secure
than cl_guid?
19:14 kevlarman> (assuming someone else did the work of course)
19:15 @Timbo> is it really that insecure?
19:16 kevlarman> well with cl_guidserveruniq it isn't
19:16 kevlarman> but then you can't even have 2 servers sharing admins
19:17 kevlarman> we have 2 servers running on the same box and we have to give
everyone admin by hand
19:17 @Timbo> cl_guidserveruniq should be the default imo
19:18 kevlarman> probably yeah
19:18 @Timbo> by which i mean you can't turn it odd
19:18 @Timbo> off
19:18 kevlarman> that might be excessive
19:19 kevlarman> i was thinking about grabbing an rsa implementation from opens
sh or something
19:19 @Timbo> i'm definitely against that
19:19 kevlarman> and adding a client command/game command to avoid breaking any
thing
19:19 kevlarman> any particular reason?
19:19 @Timbo> there is a limit to how important admin on a computer game server
is :)
19:19 @Timbo> RSA is totally overkill
looks like we won't be getting anything like digital certificates to identify players :(
-
ty
-
there is a limit to how important admin on a computer game server is :)
Ha! Yes, that's exactly why I haven't tried an implementation myself. Well, that and my thesis. Such as it is.
Caveman, you never really understood the point of my post. I understand that you cannot ID players who don't want to be ID'ed. My post was about providing unique, global, non-spoofable, totally secure ID for players who DO want to be IDed. And as Hxaltai stated, a private-public key pair would work extremely well for that. A side effect would be that every server could also have such a unique ID.
But as Timbo says, it's probably not important enough to be worth the trouble. :D
-
And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.
-
And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.
it's still a pain to lose your entire admin list when your server moves....
-
Even if Timbo doesn't want it in mainline Tremulous, I think we should see what can be done with GPG for several reasons:
1. it's much easier to say 'yes, let's include that' than 'yes, let's include what that might eventually be'
2. the rate of uptake might persuade him that lots of people like it and use it, and it would therefore be a valuable addition to the codebase
3. most people aren't using "official" code on their servers and clients anyway, if we manage to contain a modification to client binary/game.qvm (like tjw did with g_admin), then the transition should be nice and smooth and before you know it, it will be everywhere.
-
Honestly, I don't see what's Timbo's reason for not accepting a number of things in the code ( libvorbis for example ). Go on and see what you can do with GPG and let's see if the public will be smart enough to use it. Thanks to GPL, the worst it can bring us is a fork of the project.
-
Erm, you do realize that however the ID system works, the server part must finish in much less than 50ms? I'm not really sure GPG can do that, especially when you have multiple keys.
-
Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)
-
Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)
50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone. It could be possible to use separate thread for authentication though. But I'm sure nobody would want to debug that.
-
50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone...
I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.
I also don't understand your explaination of how 50ms can be equal to 20sfps.
-
I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.
I also don't understand your explaination of how 50ms can be equal to 20sfps.
The server runs in a single thread in one huge loop. In general, one loop step looks like this: read incoming packets and parse client commands, calculate new gamestate, send the gamestate to clients, rinse & repeat. Right now, the authentication through GUID takes place during packet reading and client command parsing.
The standard server setting is 20fps and when a frame is finished, the server will sleep until it's time to calculate the next frame. That means that every frame takes 50ms (because 50ms * 20 = 1000ms = 1s).
If you don't finish the frame in less than 50ms, the server won't start sending gamestate updates in time and the game will lag.
-
...
I see your point. I made a benchmark with python's M2Crypto based on OpenSSL and it takes about 37ms to encrypt or decrypt using RSA-2048bit with C2D at 2.13GHz and 51ms at 1.6GHz. While it is quite a long time I doubt it would present itself as a problem, because cryptographic operations need to be done only at a new connection setup. I'm not sure whether the connection is reinitialized across map reloads, but even if it was the case, identity could be somehow cached.
Nevertheless if we were concerned with a possible DoS attack exploiting the overhead of cryptography we can always throw it into a separate thread and have the client wait for a connection a moment longer.
-
Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen. I envisioned that at connection time, and at the start of every map, there would be a little interaction between server and client. In this interaction:[list=1]
- The client would prove it was the true owner of its public key,
- The server would prove that it was the true owner of its public key; and
- All game traffic would proceed as usual (without continual verification), just using the public key as the GUID.[/list:o]As far as I know, a public key could be trivially dropped in to replace the current data in the GUID. The only difference is, I think a public key contains more bytes of data, which I guess would mean a slightly larger packet?
Then, for example, SST would know that I was the same FooBar who signed on yesterday. And I would know that Fragify (New York) was a totally different server from Fragify (Virginia), and not just the old server in a new location.
The only reason to (a) continually authenticate, or even (b) encrypt all game traffic, would be if you wanted to [list=a] - Prevent some kind of insane man-in-the-middle spoofing; or
- Keep any hypothetical internet eavesdroppers from learning you just got pwned.[/list:o]Unless we want to introduce secure online shopping in Tremulous. ;)
I thought that mandatory GUIDs (always-on-GUID by default), combined with public-key-based GUIDs, would make it easy, for example, to deal with multiple players from the same IP address, and various other admin situations that can be a little tricky.
And of course, with a global GUID registration system GPG would probably be necessary, in the long run, to prevent rampant spoofing from making the system worthless. So that brings the whole conversation back on-topic. ;)
But I'm not really interesting writing it, since as Timbo says, it's a lot of trouble and it may not really be worth it. Oh, someday if I'm really bored I may take a stab at it, but not right at the moment. :D I just wanted to know if anyone had seriously talked about it. And now we have!
-
qvms don't get linked against the crt
Timbo just added isalnum() to the Q3 code.
http://svn.icculus.org/quake3/trunk/code/qcommon/q_shared.h?r1=1168&r2=1185&p1=trunk/code/qcommon/q_shared.h&p2=trunk/code/qcommon/q_shared.h
-
is there anything older than the news from last week?
-
Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen.
The standard way to protect EVERYTHING (as in IPSec or TLS) is to use public key agreement protocol (10's of milliseconds) to establish a session key, and then use the session key to authenticate traffic using HMAC (sub-milliseconds). Not that there is a crying need to authenticate normal player traffic, but all privileged (admin) actions would benefit from session authentication.
Caveman makes lots of good points, but this:
A failsafe way to ID a player, one that can not be spoofed.
is not one of them. Public key authentication is a failsafe way to ID a player that cannot be spoofed, unless you can hack that player's computer to steal his private key. USB tokens or smartcards address that problem. Because Tremulous doesn't have much of intrinsic value (admin privileges are fun, but don't hit you in the pockebook like online banking or shopping) there is not a huge incentive to spoof an existing ID. The problem addressed by invites, whitelists, eBay-like reputations, pay-per-ID, etc, is the ability to mint an unlimited number of new IDs at very low cost. As long as minting IDs is easy, there is little incentive for a griefer to spoof someone else's ID. If Tremulous had a mechanism for adding value to IDs, griefers would have more incentive to steal an existing ID rather than minting a new one, and authentication would then be needed.
So what is an appropriate way to add value to Tremulous IDs? Reputation, in my opinion. This would involve:
* Each server operates a reputation system (like Dretch*Storm's experience points - XP) according to its own formula. Griefing would be penalized by reducing XP for successful votekicks, admin kicks, and bans of various duration. The server operator could link in-game reputations with forum reputations (post counts or member ranks) to make it more difficult to quickly mint new in-game IDs. A server could require pay for play (although I certainly wouldn't pay simply for the privilege of avoiding griefers and I doubt such a server would succeed). Much better would be inferred payment: require registration through an institutional email account (isp-provided, .edu or corporate, but not hotmail/gmail/yahoo). A griefer might have access to a few such addresses (Verizon permits 8 email addresses per account) but not an unlimited supply.
* Each server publishes its reputations using a standard (to-be-defined) interface which any other server could query. There is no need for a centralized "ban" server, the existing master server allows a server to find all other servers that send a heartbeat. The reputation query would contain a GUID; the response would contain the public key used to authenticate that GUID and the reputation info.
* Each server would collect reputations from every other server it cared to check (valuing the opinions of some servers more than others). It would then make a decision to admit or deny a player using its own criteria.
A crucial point of this scheme is federation: there is no central authority for making ban decisions. Instead there is an information sharing federation in which every server is sovereign: it publishes what it chooses to publish, and makes whatever decisions it wishes based on information published by others.
A second crucial point is that because new GUIDs can be minted and because, if per-server GUIDs are used, a player can choose which GUIDs to disclose and thus which servers' reputation info can be linked to the player, THERE IS NO VALUE in attempting to rely on negative reputations as a reliable way of detecting griefers. Caveman is absolutely correct on this point: a GUID does not ID a player unless he wants it.
So why bother?
Because if there are a few well-admined servers that limit GUID minting somehow (e.g. by requiring registration from a paid email address) and choose to share their users' XP info, then they would be able to leverage each others efforts. Perhaps the federation would grow in popularity, or perhaps good (well-intentioned, whether skilled or noob) players would migrate to more griefer-friendly servers. Hard to say without trying.
-
The problem with user identification is that it really only works with users who WANT to be identified. Tracking a user who does not want to be identified is not easy, and is impossible for a game server.
The problem with this federation reminds me of an old mad magazine joke.
A man walks into an office and up to the front desk. "I'd like to attend trucking school." He says.
"Are you a member of the truckers union?" The person behind the desk asks.
"No"
"You have to be a member of the truckers union to attend trucking school."
"ok, can I join the truckers union?" The man asks.
"Are you a trucker?" The desk clerk asks.
"umm, no"
"You have to be a trucker to join the truckers union."