home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / virtual / 2799 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  4.2 KB
  1. Path: sparky!uunet!ogicse!plains!news.u.washington.edu!milton.u.washington.edu!hlab
  2. From: autodesk!robertj@uunet.UU.NET (Young Rob Jellinghaus)
  3. Newsgroups: sci.virtual-worlds
  4. Subject: DESIGN: Security (was Re: DESIGN: doors between worlds)
  5. Message-ID: <1992Aug17.063556.23992@u.washington.edu>
  6. Date: 14 Aug 92 18:04:08 GMT
  7. Article-I.D.: u.1992Aug17.063556.23992
  8. References: <1992Aug12.085135.19434@icf.hrb.com>
  9. Sender: news@u.washington.edu (USENET News System)
  10. Organization: Autodesk Inc., Sausalito CA, USA
  11. Lines: 67
  12. Approved: cyberoid@milton.u.washington.edu
  13. Originator: hlab@milton.u.washington.edu
  14.  
  15.  
  16.  
  17. In article <1992Aug12.085135.19434@icf.hrb.com> jtt@icf.hrb.com (Jack
  18. Taylor) writes:
  19.  
  20. >How about when I initially connect to the "router" I get placed in a
  21. >"waiting room" (Can't you picture it, plants, some dog-eared old
  22. >magazines, elevator muzak), which contains portals for all the worlds
  23. >that router knows about. From there I can select the world I want to
  24. >enter. World creators don't necessarily know about all the other world
  25. >creators in a manner which would allow them to simple attach worlds
  26. >arbitrarily.
  27.  
  28. This reminds me of the other compelling reason for some kind of world-
  29. portal mechanism: security.  If I create a virtual world of my own, I
  30. don't want anyone to be able to get into it unless I grant them
  31. permission.  Permission in this sense means creating a portal to my
  32. world and giving it to someone else.  Likewise, I shouldn't be able to
  33. access anyone else's world unless they have said it's OK.  A world
  34. that I don't have permission to access will simply never become
  35. accessible to me through any portal I can reach.
  36.  
  37. Any VR system which doesn't support portals will have trouble defining
  38. access boundaries.  And simple access isn't the only issue; what about
  39. modification?  What if you let someone into your world, and they start
  40. trashing the place?  Can you throw them out?  How?  Can you just
  41. restore your world from a backup and leave the other copy of the world
  42. for them to destroy?  This starts looking like a many-worlds inter-
  43. pretation of cyberspace.
  44.  
  45. Likewise, any VR system that does support multi-user, secure worlds
  46. will need navigation mechanisms that don't assume you can enter any
  47. world in the cyberspace.  This starts getting into issues of secure
  48. personal identity in cyberspace (how do you know that dragon at your
  49. portal is really your friend?), not to mention money (a thriving
  50. cyberspace will eventually need to support paying to enter particular
  51. worlds, or to access particular information; the "cyberspace mall"
  52. won't happen without it).
  53.  
  54. All of these are beyond the scope of the VR standard under discussion,
  55. but it's important to remember that the current VR standard is only a
  56. piece of the software structure that will comprise a fully-fleshed-out
  57. cyberspace.  If the standard can define routing and rendering
  58. protocols that can implement portals or some equivalent way of
  59. transiting between worlds, then the security features and everything
  60. else can be built on top of it.  If the standard specifies something
  61. silly like "all worlds the router knows about are accessible to
  62. everyone", it'll start breaking down once people actually begin
  63. rolling their own spaces.
  64.  
  65. John Eagan made some point about how all these otherdimensional,
  66. mathematically-hairy interpretations of cyberspace aren't needed.  I
  67. agree, to a point.  Any cyberspace standard needs to be internally
  68. consistent, so layers can be added on top of it without compromising
  69. the lower-level semantics, or creating a system which is easily
  70. crackable.  It's not trivial to design a secure open system, but
  71. that's what a good cyberspace has to be.  And finally, any cyberspace
  72. that does support these weird world-transit mechanisms will need a
  73. rigorous definition of how the virtual physics works, otherwise the
  74. whole thing will be spaghetti code that crashes the first time you
  75. try to toss an elephant through a hanky-size portal.
  76.  
  77. --
  78. Rob Jellinghaus                | "Next time you see a lie being spread or
  79. Autodesk, Inc.                 |  a bad decision being made out of sheer
  80. Internet: robertj@Autodesk.COM |  ignorance, pause, and think of hypertext."
  81. AMIX: RJELLINGHAUS             |    -- K. Eric Drexler, _Engines of Creation_
  82.