Why Wizards
rusty wright
From: dur...@husc4.HARVARD.EDU (Cyberpixie)
Date: 21 Jun 90 21:01:48 GMT
OK, so why wizards? Welp, let's take it from the point of view of
the user. What can I, as a user who doesn't like a given
wizardless MUD, do to that MUD?
First thing: I can spam the database in a big way. It is more than
easy for me to log on, macro up cash, and dump entire files into
the database as objects. Or, failing that, I can simply create a
thousand characters, using a simple robot. Describe them all, fill
all the available fields...no big problem there, and it'll chew up
disk space.
Or even easier, I can macro a thousand 512 character gripes. You
begin to see the problem, I trust.
One of the main reasons for my 'object quota' idea is to prevent
people from crashing the server by creating gobs of objects. In my
original design a player would be given a quota of Q objects (this
includes rooms, exits, things, etc.) and they can create up to Q
objects within the time period T. For example, to make the arithmetic
easy, let's make Q be 240 and T be 24 hours. So within a 24 hour
period a player can create at most 240 objects. If they create 240
objects in the first 5 minutes they won't be able to create any more
objects until 23 hours and 55 minutes have passed, and at that time
they can create 240 more objects. Also, if they don't create any
objects for several days their quota still stays at 240.
A variation on this to make Q and T be relatively small; for example,
make T be 1 hour and Q be 10. The effect is the same; within a 24
hour period you can only create 240 objects.
Another wrinkle is to 'clamp' new players' quota to 0 for their first
48 hours. The theory here being that people who are out to try crash
a mud server are doing it in anger and after 48 hours they may have
cooled off. And it also just makes it more difficult when combined
with the following scheme.
As for the problem of someone creating a slew of characters, you can
use a similar scheme. For object quotas you limit players to creating
at most Q objects in a specified amount of time. For character quotas
you limit a host (i.e. internet address) to creating at most C
characters in a specified amount of time.
Likewise for the gripe problem; have gripe quotas.
These schemes aren't foolproof. For object quotas a determined person
could get around it by creating a large number of players and then
connect robots to all of them and fire them all off to start creating
objects. Similarly for gripes. Likewise, for character quotas, if
the person has access to several machines (as many computer science
undergraduates do) they could continuously create a significant number
of characters.
But the most important aspects of these schems is that it is the mud
server doing it and therefore it can PREVENT or LIMIT the problems
before they get out of hand. If you have a player that is
consistently using up his/her object quota then the mud server can
send email to the mud administrator to notify them of suspicious
behavior. Likewise, if a host/internet address is consistently using
up its character quota the mud server can send email to the mud
administrator.
When you rely on wizards it is more likely that they will notice that
something is wrong after it is too late and the damage has been done.
However, this does not solve the other main way to ruin a database.
Think: for a MUD to be wizardless, there must be many unlinked
exits available, correct? What happens if I log on Monday and take
them all? And do the same the next day? And so on? Building has
become much harder, I think.
I think someone already addressed this problem with the OPEN_OK flag
idea. I had a different idea that is similar in effect but with some
additional features. My idea is for places like the designer's
teleport room on Islandia. You put a robot in the room that owns the
room. When a person wants to make a link out of the room they whisper
all of the @ commands to the robot who does the actual commands; e.g.,
whisper builder_bot = @open myexit
whisper builder_bot = @link myexit = #1234
whisper builder_bot = @desc myexit = ...
...
The additional feature is that the robot can also maintain a
"directory" of all of the exits out of that room. Then you can do
things like
whisper builder_bot = list exits owned by xyz.
to get a list of all exits 'owned' by player xyz (the robot really
owns the exit, thus the quotes). Or if you don't remember the exact
name of an exit you could do
whisper builder_bot = what exits contain "hall" in their name?
And of course you could do
whisper builder_bot = list all exits.
How complicated you want to get for searching and matching is limited
by how much time you want to spend on the robot.
--
--------------------------------------
rusty c. wright
ru...@violet.berkeley.edu ucbvax!violet!rusty
Vintage Mutant Ganja Technerd
>
>One of the main reasons for my 'object quota' idea is to prevent
>people from crashing the server by creating gobs of objects.
[Object, login, gripe quota ideas deleted]
...
Sure, it's possible to add the extra quota code to this
hypothetical BloatMUD. It's possible to add a 'Kill Quota'
as well, allowing old fogies to scour common rooms of pesky
sleeping newbies instead of yollering to the nearest Wizard.
But I have to ask, *why*? The present system works pretty
well, and could be made almost perfect with a modified mail
registration. (One that has almost instant turnaround time.
Login message gives you address to send mail to, a daemon
replies with a name/password.)
>If you have a player that is
>consistently using up his/her object quota then the mud server can
>send email to the mud administrator to notify them of suspicious
>behavior.
>Likewise, if a host/internet address is consistently using
>up its character quota the mud server can send email to the mud
>administrator.
Likewise, you can write something like my facist.c program,
which cross-references idle times of character, the hosts
they're logged in from and the idle times of people logged
into the host (later found courtesy of port 79) to pin-point
the login as well as address of potential insurrectionists.
Bletch.
>When you rely on wizards it is more likely that they will notice that
>something is wrong after it is too late and the damage has been done.
*Shrug*. When you rely on primitive security measures like
these you're tossing out a challenge to the world, daring
would-be hackers everywhere to cause problems for you.
>> [What if someone uses up all the opened exits?]
>I think someone already addressed this problem with the OPEN_OK flag
>idea. I had a different idea that is similar in effect but with some
>additional features. My idea is for places like the designer's
>teleport room on Islandia. You put a robot in the room that owns the
>room. When a person wants to make a link out of the room they whisper
>all of the @ commands to the robot who does the actual commands; e.g.,
>
> whisper builder_bot = @open myexit
> whisper builder_bot = @link myexit = #1234
> whisper builder_bot = @desc myexit = ...
> ...
What if Joe Dufus, tinywar or a similar hacked client at his side,
walks in and types:
/repeat 1000 w builder_bot = @open myexit %\;@desc myexit...
using up all of builder_bot's object creation quota? :)
(Yes, I know, you could have the 'bot reject requests for more
than 2 exits a day from the same player. But clever players
will append %;/namechange to the end of their macros, and
unless you have a Wizard robot it won't be any wiser. But
if you have Wizard robots, why all this discussion in the
first place? Please, don't start with name changing quotas.
I can feel the database swelling already.)
The point of my soliloquoy? "You can't make a MUD totally
secure." There will always be hackers out there that would
delight in foiling your security measures even if they have
no reason to mung up the database.
Things like quotas would only slow down and annoy legitimate
users, they'd pose a minor annoyance to a determined enemy.
Come to think of it, there are better ways to annoy users
than quotas. For example, a delay of 5 to 10 seconds between
object creations and logging in, will all do the trick of
'limiting' spamming without the juggling of quotas, login times,
keeping track of hosts, et al. Problem is, it's all more of a
hinderance than a help.
rusty wright
<... stuff of mine about a "ruggedized mud server" deleted ...>
But I have to ask, *why*? The present system works pretty
well, and could be made almost perfect with a modified mail
registration. (One that has almost instant turnaround time.
Login message gives you address to send mail to, a daemon
replies with a name/password.)
I sometimes wonder if I'm the only one that recognizes the obvious
problems with registration. I can think of three offhand; listed in
no particular order they are:
(1) The biggest fallacy with email registration is that there is a
1-to-1 correspondence between a person and email addresses. There are
plenty of people on the internet that have a workstation sitting on
their desk and that have the root password to their workstation, so
they can make accounts willy-nilly and send an email message from each
account to your daemon and thus create as many mud characters as they
want.
Or, for those that don't have superuser privileges, it's trivial to
create forged email by using telnet to connect to the network socket
of the email daemon (sendmail on unix). This trick is very old.
Or, they can route their mail through various machines using % or
bounce it off some uucp machines with ! thus creating a variety of
From: lines that your daemon probably wouldn't be able to distinguish
as being from the same person.
(2) A number of mud players can't send email; for example, they're
using some network terminal server to connect to the mud server. I've
heard proponents of mud registration cavalairly dismiss this problem
claiming that the number of people that can't send email is
insignificantly small. This has not been my observation; I know
several players that are either in this category or were until some
friend or associate gave them an account on their workstation, or they
are using a friend's, roommate's, etc. account. In fact, one (and
perhaps two) of these people that I know are wizards.
(3) Many players and (mud administrators) consider player anonymity to
be very important, for whatever reasons. My feeling is that player
anonymity is a significant component of what makes up the mud
environment or atmosphere. In other words, take it away and the
"flavor" of the mud would be changed considerably. Of course a
determined tinymud wizard could probably track down a player (if the
player isn't using a network terminal server) since the tinymud server
logs connections by name and internet address and for wizards the WHO
command shows the internet address that players are connecting from.
--
rusty c. wright
ru...@garnet.berkeley.edu ucbvax!rusty
Russ Random Smith
>I sometimes wonder if I'm the only one that recognizes the obvious
>problems with registration. I can think of three offhand; listed in
>no particular order they are:
>(1) The biggest fallacy with email registration is that there is a
>1-to-1 correspondence between a person and email addresses.
Correct. There is not.
>(2) A number of mud players can't send email; for example, they're
>using some network terminal server to connect to the mud server.
Correct. There are a few.
(1) and (2) are minor points, however, when you consider that some of the main
reasons of registration are to cut down on frivolous creation of characters,
and to attempt to instill some small sense of accountability in players.
>(3) Many players and (mud administrators) consider player anonymity to
>be very important, for whatever reasons. My feeling is that player
>anonymity is a significant component of what makes up the mud
>environment or atmosphere.
The players are completely anonymous, unless the head wizard of the appropriate
mud decides it's his business to take note of someone's real address (such as
it is). Like I keep saying...if you can't trust a head wiz that far, then
don't play his game. Do you visit people you dislike?
>--
> rusty c. wright
> ru...@garnet.berkeley.edu ucbvax!rusty
--
--Russ "Nightfall" Smith-- | Wait, I'm LIVING my childhood power fantasies!
Randomized Ranter for Bob! |-----------------------------------------------
ru...@uokmax.ecn.uoknor.edu | DISCLAIMER1: Even smileys make my face ache...
Flame Dodger,1988 Olympics | DISCLAIMER2: IMHO IMHO IMHO. There, I said it!
Robotron 2084
>The players are completely anonymous, unless the head wizard of the appropriate
>mud decides it's his business to take note of someone's real address (such as
>it is). Like I keep saying...if you can't trust a head wiz that far, then
>don't play his game. Do you visit people you dislike?
I would like to know who plays my mud, so I can distribute "Three's
Unabridged Dictionary of Commands" more widely. I'm tired of finding players
called "test" and variants thereof, and seeing unlocked players. So if I
ever get around to de-ansifying 1.5.4, I'll set the options so that people
have to ask me for an account. It's not as if there's going to be any
problem sending me mail, because the game is only playable on the local
ethernet.
--
grils - yum\ cobol is evil \ smulrine%cs.stra...@nsf.ac.uk \ Glasgow's
------------\it has no slack\____________________________________\ Miles Better
You Might Be \ --------------\ robology \ anything i say is my \-----------
Allowed! \ 2069^H^H84! \ isn't bad \ own warped opinion. \ i like grils