The StoogeBot Manifesto

In our opinion, the reaction to the StoogeBot highlights two issues.

The first issue is the need for standard ways for servers to declare bot policies. Currently, server administrators set the policies in Quake by choosing things like level sequences and game rules, and players express their opinions about such policies by choosing the servers that they play on. The natural extension of this is for server administrators to declare bot policies, and for players to take such policies into consideration when choosing their servers. One way to do this is to have servers declare either "no bots", "bots welcome", "players decide", or "no policy".

However, even if such policies are agreed on, there is no way of forcing a proxy bot to obey such standards. This leads us to the second issue, which is much broader than Quake, and applies to internet gaming in general: the network protocols used by internet games need to be made more secure. This shouldn't come as a surprise to anyone; people have also taken advantage of weaknesses in the network protocols of Netrek, Diablo, Descent, and others.

In any event, we have a number of ideas about how to improve the network protocols of internet games, and would be happy to discuss them as they relate to Quake. In particular, we feel that the protocol needn't necessarily be encrypted, and that providing the option of using something along the lines of client authentication (verifying that a client is not fake), might offer a nicer solution to the security problem.

It's our hope that, in the wake of the StoogeBot, the Quake community will, at the very least, discuss these issues.

Having said all that, we'd also like to rattle off a list of clarifications to some of the misconceptions and disinformation that have been circulating about the StoogeBot:

• The StoogeBot has never been, and probably will never be, compatible with QuakeWorld; however, the QuakeWorld protocol is no more secure than the vanilla Quake protocol, and operational QuakeWorld proxies do exist. (At least one is being distributed publicly; fortunately it is still primitive.)
  
  
• We will not release the source code to the StoogeBot until the network protocols have been made secure.
  
  
• The StoogeBot is a client-side executable, not a QuakeC program, and as such, it is not trivially decompiled and recompiled to remove the bot's built-in safeties.
  
  
• Important strings (e.g., "no bots") do not appear as plain text in the StoogeBot executable, and cannot be "hex edited" out. We add that an experienced hacker will eventually be able to circumvent the StoogeBot's safeties, but:
  
  
• It is almost trivial to write a proxy bot based on software freely available on the net, and we know of several such projects, at least one of which is being publicly distributed over the Web with far fewer safeties than the StoogeBot.
  
  

Also, a word or two on motivation:

The release of the StoogeBot was not an attack against Quake or id.

Eventually, the StoogeBot presence in Quake will fade away as its novelty wears out, servers implement "no bots please" policies, and (hopefully) authentication is added to the game.

We truly hope that by the time less polite and more hackable proxies find themselves in the wrong hands (which they will), the example of the StoogeBot will have provoked some thought about how to deal with the problem. We certainly don't want to face any such proxies in supposed "bot-free" deathmatches.

We'd like to close with the following bit of serious humor (if there is such a thing) describing ways to keep the bot-abusing knuckleheads in line:

Those looking for a progs.dat file that welcomes players with a "no bots please" message might want to visit the SGQP website.

The StoogeBot Team
[email protected]
http://www-graphics.stanford.edu/~quake