Multiplayer: usernames should be more distinguishable #5015

Open
janisozaur opened this Issue Jan 7, 2017 · 14 comments

Projects

None yet

8 participants

@janisozaur
Member

Version: 0.0.6-develop

Impostors seem to trick server hosts and staff into thinking they are someone else by using spaces in usernames which can be hard to notice in chat or permission window.

Other social engineering trick can be different casing of username, which should be case sensitive across all platforms.

To thwart that, we could make usernames re-colourable (per client or per server) to help identifying users.

@Sweet-Tan

Would assigning the color per-group on the server side accomplish the same goal? It could then be defined in the groups.json file.

@IntelOrca
Contributor

Other social engineering trick can be different casing of username, which should be case sensitive across all platforms.

Do you mean case insensitive?

@janisozaur
Member

@Sweet-Tan I pondered about that briefly, but I think you would rather want it stored per-user.

Consider following scenario:
janisozaur and janisozaur_*, both first-time users, join and both try to get elevated permissions. They are in the same group so far and if the colours are assigned per-group, they would have the same one.

On the other hand, if the colour was per-user & per-server, someone with PERMISSION_SET_PLAYER_GROUP could assign the colour to one of them and it would be much easier to identify who is who.

Additionally, for non-assigned users, the colour could be assigned randomly on joining.

* markdown trims trailing space

@janisozaur
Member

@IntelOrca I talked to @YoloSweggLord on one of the servers and he mentioned usernames should be case sensitive, I blindly followed. Now that I've given it some thought, case insensitive sounds a bit better.

@YoloSweggLord can you comment?

@YoloSweggLord

Yeah, I meant to say case in sensitive. Must have misspoken when I said that, oops.
Concerning the trailing space issue, I have seen several impersonations where the impersonator tricks the system by adding a training space after this name. The only way to tell them apart from the real deal is to look at their name in chat, where this is a small space between the name and the colon. The space though isn't noticeable unless you're looking for it, which is how impostors get away with it so easily. Basically my thoughts on this were that the game should block attempts to change the username to a string with any number of spaces at the end.
About the case insensitivity issue, I'm not sure if the game even is case sensitive or not. It was something that popped into my head while I was discussing the trailing space issue with Janisozaur. What I understood is that it probably varies between operating systems, depending on whether their file names are case sensitive.

@Lastorder-DC
Contributor

maybe duplicate of #4301 ?

@janisozaur
Member

I'd say it is related to #4301 and perhaps both should be solved, but I will argue this (#5015) is more versatile.

#4301 requests a particular change to be implemented, while this tries to present a more general problem and possibly find a solution to it.

@PFCKrutonium
Contributor

For the space issue, if this was C#, i'd just throw in a .Trim() to remove any leading or trailing whitespace.

@janisozaur
Member

Should the colours be stored in users.json or just assigned randomly for all, even known, users?

@Ziscor
Ziscor commented Jan 9, 2017 edited

I'd want it per-server myself. If it was assigned at random, and if the person that is impersonating just happens to get the exact color of the person being impersonated (and if not random, manually chooses that color deliberately), that might make things confusing, or even troublesome.

But per-server would have it's own issues too as you showed, janisozaur. 😅

@janisozaur
Member
janisozaur commented Jan 9, 2017 edited

Just to provide more detail what I meant by "per server". There are two way this could go:

  • each client could set other user's colour locally
    or
  • the setting could come from the server and be synchronised across all clients. This is the one I think of when I write "per server".

Maybe the assignment shouldn't be random, but based on username hash, so each time a user joins, he would get the same default colour, but changing the name would yield another one. Perhaps at this point there is little point to be able to change the colour at all, but this could still be useful when some colours are not legible.

@marijnvdwerf
Member

Why wouldn't colours be legible? Just use a hand-picked subset.

@janisozaur
Member

@marijnvdwerf because we have themes for windows and for this to work, the colour of username would have to be matched in chat and multiplayer window (players list).

@Sweet-Tan

@janisozaur If color were to be assigned per user, it should be synchronized across all clients. If it were assigned per user on the server side, it is no problem for server operators to assign it manually.

I am still set on colors being assigned per group. This is the idea I came up with. Within groups.json would be a field containing color codes available to be randomly selected for the users. I am not certain what the project uses for the color codes, but if it were hex, I picture it like this.

{
"id": 2,
"name": "Guest"
"colours": [
#ffffff
#ff0000
]
"permissions": []
},

Anyone connecting and assigned to "groupId": 2would be given #ffffff or #ff0000 at random. This would give the option to the server operator whether or not they would like to randomly assign a range of colors, or only assign one color per group. I suppose it's not ideal because it could not be managed within the game well, if at all.

All of that aside, I would compromise with having the color assigned per user as long as the color were defined within users.json, though I am not a fan of assigning any random color to any new user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment