NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/sci/virtual/2843

Internet Message Format | 1992-08-20 | 4.4 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!plains!news.u.washington.edu!milton.u.washington.edu!hlab
From: [e-mail]
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: world description
Message-ID: <[e-mail]>
Date: 18 Aug 92 05:11:11 GMT
Article-I.D.: u.1992Aug20.182853.10869
References: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: University of Washington
Lines: 75
Approved: [e-mail]
Originator: [e-mail]



[stuff about MUDing deleted]

>[e-mail] (Dave Stampe-Psy+Eng) writes:

>I think MUDDs are a step in the general direction of Cyberspace,
>however, I see a few MAJOR draw-backs to this type of environment.
>The problem I see lies in creating security for such a system.  For
>those of you whom are not familiar with how the object-oriented system
>of how a mud works, it is as follows.
>
>1)      The user types some command.
>
>2)      The system then looks for a procedure that handles that command.
>
>3)      ***Here's the problem.*** The system starts in your inventory,
>        looking for an object to handle that command, then it goes to
>        the inventory of the room...this could be your player object, or
>        some object lying in the room, next it goes to the environment itself.
>        If it goes all of the way through this list, and can't find the
>        command, it will give you an error.
>
>Here's why this is a problem.  If you override some command, in for
>example an object in your inventory, it will never get to the
>environment.  This is bad, because a net-runner could override your
>security also, which is embedded in the system, simply by calling the
>base-level procedures or creating his own to run on your system.
>
>An argument to this would be that you could imbedd security checking
>in your base level code, but this will both slow down your machine and
>be expensive.  Also, if ever even 1 copy of your custom software got
>out to the rest of the net, your security measures would be useless.
>Also, you would have difficulty sharing data with the rest of the net.
>
>This is a common problem on Muds, when people become wizards, they
>sometimes try to write objects which give them administrative access.
>
>Anyway, this is the major problem I see.  Any ideas???

My apologies if this is old hat - this is my first reading in this group.

The command evaluation you describe is that used by 'LPMud' - one type of
UNIX MUD. Other MUDs do things in different ways. In mine, I allow for
actions from all of: object, player and room, rather than just the first
one that raises its hand.

The reason that this type of flexible handling is used is to avoid having
to pre-determine what is possible in the universe. Some locations (e.g.
a garbage room that destroys things dropped in it), need information about
actions on objects, a cursed item may not be droppable, a cursed player
may not be able to drop things, etc. Thus, all inputs are desireable. The
writer of the code for the garbage room cannot know what all things will
be dropped there - some sort of co-operative scheme has to be used.

It IS somewhat of a security problem, but many MUD-folk have looked at it
quite a bit and not found a good solution. Marcus Ranum's UnterMUD allows
players to wander through portals to MUDs running on other machines by
not allowing objects to have 'programs' attached to them, and by using a
very simple object representation based purely on text. Even so, lots of
problems in regards to ownership, permissions, etc. still remain.

Virtual worlds will run into the same problems, and more. Will all worlds
have identical sets of physical attributes? If so, how does someone do
something "better" - like adding texture-mapping to objects? The description
system will change over time, so worlds, and their authors, will have to
be prepared for unanticipated properties. Allowing programs attached to
objects is a very handy way of expressing complex (read: interesting)
behavior, so some sort of standardized program representation will eventually
have to appear. Static worlds are not as interesting as dynamic ones.
Worlds "authored" by one person are not as interesting as those created
by groups of people. (Less chaotic, perhaps, but likely not as interesting.)

--
Chris Gray   ualberta!ami-cg!cg   or   [e-mail]