Unicode homograph attacks

[slipher]

Currently, player names are allowed to contain Unicode characters from any language. If the game ever becomes remotely popular, I guarantee you that some players will spoof others' names with Unicode strings that have an identical appearance, but are composed of distinct characters. This would be a highly effective griefing tactic, leading to confusion over which player slot to ban, accidenally banning other players due to partial name matches, etc.

Probably the only feasible solution is to make player names ASCII-only.

Further reading: http://en.wikipedia.org/wiki/IDN_homograph_attack

[Viech]

Another solution would be to display the names in hex in the console player list, too. Bans shouldn't be done via name strings but by public keys anyway (though I didn't check).

[slipher]

If there were two players with homographic names on the same team, there still would be no way of telling which one was performing the antisocial actions. Apparently, the rule would have to be a presumption of guilt for the player with larger code points.

[lamefun]

Console, commands, and slot numbers are elitist anyway. Console should be removed and Logs tab should be introduced to replace it. Player names should be clickable, so instead of guessing which slot to ban, you can simply click the player name name in "telenode DECONSTRUCTED by XXX" messages and click "Ban Player..." Problem solved.

---

"...but by public keys anyway..." - cheaters will release an unban tool that simply generates another key pair. And IP bans won't really work either, at least until IPv6 is widespread and everyone gets static IPs, because of dynamic IP that change often, forcing moderators to ban subnets (possibly city blocks or whole cities) to get rid of a single troll.

[DolceTriade]

Yeah, lamefun's option seems to be the best in terms of UX.

[lamefun]

It's not about accents, it's about characters that look exactly the same.

Sixthly - with lowercase English Y. Sixthlу - with lowercase Russian У.

Now admin sees:

Machinegun Turret DECONSTRUCTED by Sixthlу Machinegun Turret DECONSTRUCTED by Sixthlу Machinegun Turret DECONSTRUCTED by Sixthlу Telenode DECONSTRUCTED by Sixthlу Telenode DECONSTRUCTED by Sixthlу

The question is, can the admin tell the difference and ban the right player?

[RamchandraApte]

I agree with @lamefun

Even ignoring Unicode homograph attacks, you can simply add a dot to the end of the name, etc. Also, as the game gets bigger there will be nonmalicious name collisions. One should be able to right-click the name in the chat logs and ban/kick the user. That seems to make the most sense.

[Veyrdite]

Allowing right-clicking of player names for a ban only works so far. How do you know which Sixthl? is actually the culprit?

Doing something like expanding unicode to hex/similiar only in the console (but not the in-game chat) would work. As much as it's elitist, it's a very powerful and easy way to code way to solve things. IMHO that's why it has survived -- if everything was implemented in a GUI then operating systems would not be as powerful as they are today.

[mbasaglia]

How about using entity numbers?

[Viech]

Actual entity numbers might change on reconnect. There is a namelog to keep track of players who rename or disconnect, we could display the number associated with the log entry. One could use this as an incentive to modernize the namelog code, too.

[lamefun]

Allowing right-clicking of player names for a ban only works so far. How do you know which Sixthl? is actually the culprit?

Find the spam/DECONSTRUCTED message and right click the name associated with it or switch to admin mode and right click the offender's in-game character?

Doing something like expanding unicode to hex/similiar only in the console (but not the in-game chat) would work.

So would showing hex representation of Unicode in a tool tip that appears on mouse over or in right click pop-over.

IMHO that's why it has survived -- if everything was implemented in a GUI then operating systems would not be as powerful as they are today.

No, if everything was implemented in GUI, the full power of OS would've been accessible to everybody instead of just people who want to take time to learn console. It would also mean more powerful scripts, as shell would've never been invented and people would use proper programming languages like Python and Haskell instead of garbage programming languages like Bash to create their scripts, so better scripting libraries would've been developed for them. It would also mean that Xorg dream wouldn't have died - we would've had lightweight remote desktop protocols that work by sending drawing commands and SVGs instead of trying to analyse rendered images. Command line is a fallacy, it's a virus, and even Microsoft has been infected - see PowerShell.

[Veyrdite]

Find the spam/DECONSTRUCTED message and right click the name associated with it ...

Some terminology I'm going to use: "in-game console" is where things like chat appear at the top of your screen whilst playing. "tilde console" is the full-screen console that opens when you hit ~ on your keyboard.

I presume you are thinking of implementing this in the tilde console? Messages in the in-game console tends to disappear very quickly and you can't scroll back in them. Even if the messages are made persistent, only a few lines are shown at once to avoid clogging the player's view.

Actual entity numbers might change on reconnect. There is a namelog to keep track of players who rename or disconnect, we could display the number associated with the log entry. One could use this as an incentive to modernize the namelog code, too.

This sounds great. Would we do something like prepend the number to nicknames in tilde-console messages?

or switch to admin mode and right click the offender's in-game character?

I can see this being useful, however mods are not always there to see the playing committing the crime. A bad player can abuse physical/spatial things like changing teams or running around really fast to avoid prosecution, so if we implement this we need to make sure it's not the only way to ban/kick users.

[Veyrdite]

No, if everything was implemented in GUI, the full power of OS would've been accessible to everybody instead of just people who want to take time to learn console.

It's interesting to hear your opinions -- I come from a completely different background of thought.

In my mind every application has atleast two parts: the code that does the work and the interface. UI's like qt and the console are used as interfaces to bridge between programs and the user.

UIs are an example of interfaces that work well between program<->user. There are other interfaces that work well between program<->program. None do both well: GUIs are a horrible way for one program to operate another program, API systems like C-style shared object files are a horrible way for a person to operate a program.

The console is a middle ground for me. It compromise to work as an interface for both users and other programs. It's a jack of all trades, master of none.

If you need your code to be operated by both users and other code: I believe the easiest and fastest route most of the time is to design your code to use a console-style interface. Alternatively you can implement both a program/API style interface and a GUI interface seperately, but this is more work. Sometimes requirements (eg you are handling lots of data) mandate that you do one route over another, but for simple commands like 'kicking users' this is not the case.

A lot of things we implement in the unvanq gui use cvars and the console message system as an interface to talk to the engine. This allows us to be able to quickly develop new features and test them without having to dedicate time to making a GUI for them. There are exceptions to this (eg table contents), but wherever possible it's convenient to be able to test features via the console interface by hand, then make a GUI that runs console commands.

I don't think it's a good idea to make common features in Unvanquished console only: good ways to operate kicking and banning do need to exist in the GUI for most players to be able to know about and how to use them. Fixing problems like unicode attacks in a graphical interface is very hard compared to fixing it in a console interface, however :)

It would also mean more powerful scripts, as shell would've never been invented and people would use proper programming languages like Python and Haskell instead of garbage programming languages like Bash to create their scripts, so better scripting libraries would've been developed for them.

To me writing in a programming language like python and using a console is not that different. I use bash and python in both interactive and script-running modes.

Are you combining the concepts of shells like 'bash' with interfaces like 'consoles'? You can run much more than traditional shells in a console: many text-mode/console applications work using the mouse (and I love them :P). Unvanquished opens a console when you hit tilde that runs only one interpreter, but if you don't want to write anything into it you can still use it as a console for looking at previous game/player messages. It has features beyond the shell that it's running.

I don't disagree that bash has a lot of horrible design, but I don't think that affects daemon's console.

[Viech]

Please keep the discussion to the actual issue.

[lamefun]

Fixing problems like unicode attacks in a graphical interface is very hard compared to fixing it in a console interface, however :)

If you take time and think, it's not that much harder. If you can display Unicode hex representation and IP address in console, why can't you do the very same thing in GUI?

I presume you are thinking of implementing this in the tilde console? Messages in the in-game console tends to disappear very quickly and you can't scroll back in them. Even if the messages are made persistent, only a few lines are shown at once to avoid clogging the player's view.

I think there should be a dedicated server log window:

API systems like C-style shared object files are a horrible way for a person to operate a program.

If you need your code to be operated by both users and other code: I believe the easiest and fastest route most of the time is to design your code to use a console-style interface.

If there were no CLI, programming languages would've had better tools to implement quick GUIs. CLI is a virus.

API systems like C-style shared object files are a horrible way for a person to operate a program.

C is a horrible way for a person to program a computer, and shared objects are a horrible way to export APIs. If there were no CLI, proper strongly-typed API interfaces like COM/DBus would've been better developed. CLI is a virus.

Alternatively you can implement both a program/API style interface and a GUI interface seperately

If a program isn't like that already, it's garbage, not a properly written program.

[Viech]

Keep the discussion to the actual issue. Entirely. Every post below this one will be stripped down to on-topic content.

@lamefun In the future, I'm not going to accept your tirades on elitism or proprietary software within issue discussions, not even as part of an otherwise on-topic post. Use the off-topic section of the forums if you insist on bringing this up again and again.

[Veyrdite]

If you can display Unicode hex representation and IP address in console, why can't you do the very same thing in GUI?

If we did it for the in-game console, then players would never actually see the true form of the unicode characters and so no one would use them.

If we added a new togglable message window that shows messages with playernames in hex, we've just made a clone of the tilde console.

I think there should be a dedicated server log window

Dedicated servers effectively have this (it's equivalent to the tilde console). (If you think it should be done differently/with more features that might be a different issue request).