[cap-talk] Capability secure VR scripting

[Martin Scheffler]

Hi,

I am a student in my last year and I will do my diploma at the Virtual
Reality Systems Group of the Bauhaus University
(http://www.uni-weimar.de/medien/vr).
I plan to write my diploma thesis about object capability security and
its uses for virtual environment scripting. I want to focus on
creating a scripting api for manipulating nodes of a shared scene
graph in a capability secure way. Also I want to do work on creating a
GUI for managing capabilities, revokers, facets and other elements of
object capability security.

Our VR department is mostly focused on data visualization and UI
stuff. At this point, I have convinced my professor to about 80% that
capability security can be a win for VR scripting. What I need now are
"real life" scenarios showing the benefits of cap security over the
traditional ACL approach. When I have found those scenarios, I will
implement them in a basic VR environment (described later).

At this point this is the best scenario I can think of:

A company wants to simulate its manufacturing process using a virtual
environment. Goal is to optimize the assembly line. The company hires
a subcontractor that supplies an assembly robot. That robot is used to
attach electronic parts to the product. The subcontractor gets system
access to the virtual environment.
The subcontractor is able to view parts of the assembly line relevant
to his work. He gets the capability to create a limited number of
objects and a capability to add scripts to these objects. He also gets
caps to manipulate the simulated electronic parts and to attach
objects to the product.
The subcontractor can now create a simulation of his robot and use his
caps to attach the parts to the product.
Maybe he can now create a capability to program the robot and give
that to a sub-subcontractor with even more limited rights?

Other ideas:
* When two objects collide, they exchange rights, for example a tomato
collides with an avatar and gets the right to attach itself to the
avatar for some time
* Rights exchange on Line of sight or other physical events
* A user creates a part of the scene that only he can see. He can pass
refs to these parts to other users, these users can now incorporate
them into their view
* By entering a door, the user gets the rights to view the contents of
that room and looses the right to all other rooms (~=Den?)

Can you think of other, more interesting scenarios? I would love to do
something with the Horton protocol, as my professor and I talked about
the problems it addresses.

I have spent the last weeks implementing a basic VR environment with E
and the excellent java game engine JMonkey Engine
(http://www.jmonkeyengine.com). In a flash of creativity I have named
it EMonkey. I will release the code under a free license when it does
something interesting.
Here is a screenshot of the current state: http://flowdev.de/emonkey_shot.PNG

What the system can do at this point:

* Server stores the scene graph

* Client connects to the server
       *Client passes the server capability access to the local scene graph
       *Server creates proxies of all its nodes on client
       *Client gets a powerbox in return (unused at this point)

* In the client side 3D scene graph, each node holds a far ref to a
facet of its respective server node

* The client has tools to manipulate the nodes. At this point: Move,
scale, rotate. The tools works like this: A node is selected, the
contained far ref is used to obtain the capability to move the object
on the server. Only one user may manipulate an object at one time.
This is achieved by revoking the last movement cap when a new movement
cap is given out. (this was the first thing I implemented so I had an
actual use of capabilities to show to my professor)

* Users can attach E code to a node (not executed yet). This code will
have caps to manipulate the node and maybe its children, interact with
other nodes and other things I have not thought of yet.

What I plan to do next:

* let users and user scripts create nodes. The number of nodes a user
will be able to create will be limited to prevent "gray goo" attacks.
Maybe users can trade node creation options?
* Avatars. Will probably contain a "who".
* Create a server admin interface. Will be used interactively to give
additional capabilities to some users

I'm looking forward to your feedback, so please, if you have ideas or
suggestions, come forward.

Cheers,
Martin

P.S. I can't send to this list from my GMail.com address.
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066