1

WonderDAC: An Implementation of Discretionary Access Controlswithin the Project Wonderland CVE

Timothy E. Wright and Greg Madey

Computer Science & EngineeringUniversity of Notre Dame

Notre Dame, IN 46556Email: twright@nd.eduEmail: gmadey@nd.edu

Abstract

Both proprietary and open source collaborative virtualenvironments (CVEs) offer extensive means for social,scientific, and commercial collaboration. To safeguardthe objects and activities that comprise these virtualworlds, we have proposed, elsewhere, an in-world dis-cretionary access control (DAC) system called Won-derDAC. The simplicity and role-based nature of thissystem have already been demonstrated through a lim-ited prototype. In this paper, we continue our work byexpanding upon the WonderDAC prototype to builda more complete and functional DAC solution. Al-though integrated with the Project Wonderland CVE,WonderDAC’s concepts and design could be adaptedto any similar CVE platform.

Keywords: Virtual reality, collaborative virtual en-vironment, access control, discretionary access

1 Introduction

We begin with a reference to our previous workwherein we defined a collaborative virtual environ-ment (CVE) as a “graphical, virtual reality environ-

Digital Peer Publishing LicenceAny party may pass on this Work by electronicmeans and make it available for download underthe terms and conditions of the current versionof the Digital Peer Publishing Licence (DPPL).The text of the licence may be accessed andretrieved via Internet athttp://www.dipp.nrw.de/.

ment capable of operating on a typical, modern work-station [WM08].” A few well-known proprietaryCVEs include Second Life, There, and Activeworlds,while Project Wonderland (also referred to as Wonder-land) and Croquet are among the more popular opensource CVEs. Typical uses for these systems rangefrom socializing, education, and commerce, to gameplaying and scientific research.

Despite their flexibility, most CVE platforms lackin-world access controls that are simple in design,yet effective and encompassing in functionality. Pro-prietary systems, for example, offer extensive meansfor their subscribers to own, rent, and sell virtualland [Act08c] [Act08b] [Act08a] [Lin07b] [Lin08][Lin07a] [Mak04] [Mak08] [Mak06], but such con-trols are more limited with regard to other types ofobjects (e.g., of a non-spatial nature). Also, the userinterface to configure and manage access controls inthese CVEs can be complicated, requiring a certainlevel of expertise of the participant. For open sourceplatforms, such as Croquet and Wonderland, accesscontrols are generally relegated to protecting the userlogin activity alone.

To answer to these deficiencies, in our earlier workwe proposed the creation of a discretionary access con-trol (DAC) system specifically engineered for CVEs.Our system was intended to be easy to use and capa-ble of protecting any object found in a CVE, includ-ing, but not limited to, three-dimensional spaces andassets, still images, videos, sounds, and avatars. Inthis earlier work, we identified three CVE layers (seeFigure 1) where security controls should be applied,with the top two of these (in-world access and user ex-perience) affected by any DAC system. In addition toprotecting these two layers, the simplicity and ubiquity

2

User Experience

In-world Access

Network

Communications

Architectural layout;

Visibility of objects and information;

Audibility of conversations and other sound

Mutability of objects and places;

Spatial access;

Login access

Transmission stream encryption;

Non-repudiation

Figure 1: Layers of security in a CVE.

of our approach was intended to ensure that a partici-pant willingly and correctly employed access controls.Regarding this, we devised five use case scenarios tocapture the essence of what our DAC system should becapable, and then partially implemented the first twoscenarios in the form of a limited prototype. Restatedhere, for convenience, are the five use cases:

• Spatial Object Restrictions–access control forthree dimensional spaces

• Non-spatial Object Restrictions–access controlfor three and two dimensional assets, as wellas images, videos, and sound (excluding audiochats)

• Audio Conversation Restrictions–access controlfor audio chats

• Avatar Cloaking–access control for an avatar’simage (i.e., permit/deny others to see one’savatar)

• Permissions and Ownership Changes–user inter-face to effectively manage roles and permissionsfor all objects

We chose to implement our DAC prototype withinProject Wonderland, an open source, Java-based CVEmaintained by Sun Microsystems. There were twocompelling reasons behind this choice. First, Wonder-land utilizes a client-server model, which enables theserver end to act as an authority for the managementof access controls and protected resources. This is incontrast to a peer-to-peer model, such as Croquet’s,where each peer has a copy of the same data as everyother peer. Under the peer-to-peer model, a malicious

user could simply attack their own workstation to ob-tain unauthorized access to information and resources.Because of this, safeguarding such an environment isan inherently complicated problem [NPVS07]. Sec-ond, Wonderland is at a very early stage in its develop-ment life-cycle, making it relatively easy to integratea DAC system of the breadth and robustness we in-tended. Resulting from our use of Wonderland, weelected to name our prototype WonderDAC–a short-ened form of Wonderland Discretionary Access Con-trols.

Despite being available for only a short time (sinceJanuary 2007), Wonderland is founded atop other,more mature open source technologies and includesa variety of important features [Sun08c]. The mostsignificant example of this is found in Wonderland’suse of the Project Darkstar game server, which pro-vides a transaction-based virtual environment that isalso highly scalable and fault-tolerant. Another tech-nology, jVoiceBridge, equips Wonderland with spatial,stereo sound and the ability to place telephone callsthrough the Session Initiation Protocol (SIP) to theoutside world. Completing the list, Wonderland uti-lizes Java3D and Project Looking Glass to handle its3D visualizations.

By evolving the WonderDAC prototype into a fullimplementation, we demonstrate that an easy, encom-passing approach to CVE access control is viable.

The remainder of this paper is organized as follows:the next section summarizes related works; Section 3looks at the basics of how Wonderland and Wonder-DAC operate; Section 4 considers the role that net-work communications security plays relative to Won-derDAC, Section 5 presents several examples of Won-derDAC in use; and Section 6 ends the paper with sum-mary remarks and a consideration of future work.

2 Related Work

Though limited in number, efforts to manage in-world access controls for CVEs span a range of ap-proaches that cover the in-world access and userexperience layers from Figure 1. For example, ascheme based on the movement of a user’s avatar as-signs permissions to spaces through a so-called ac-cess graph [BB99]. Two other approaches exploitVR metaphors: one by using specific virtual ob-jects to enable and manage privacy [BBF98], andanother by leveraging structural divisions and socialconventions to guide participant behavior and privacy

3

[HD96] [HTK+97b][HTK+97a][MAIO97] . And stillother means of access control operate through mes-sage passing (to gain access to resources) [PM01],embodied interaction (where the state of an objectand the avatar, along with the programmed function-ality of the virtual environment determine access)[CW00], and simple, static authorization granted at lo-gin [MZHO07][MCM06].

Subscription-based CVEs including Second Life,There, and Activeworlds generally offer an accesscontrol list (ACL) approach to securing in-world re-sources. As was noted in Section 1 above, such con-trols are full-featured regarding the management ofvirtual land, but can often be complex to apply andlimited with regard to other VR assets. AlthoughWonderDAC is also ACL-based, it differs significantlyfrom access controls found in commercial CVEs dueto its simplicity and homogeneous application to vir-tual objects.

A noteworthy alternative to the in-world access con-trol solutions discussed here is object-capability secu-rity [SSF08]. An object capability may be thought ofas a key that can open a lock: the possession of an ob-ject’s capability allows a user to interact with that ob-ject in some specific manner. Capabilities can enablediscretionary access control by being exchanged, as-signed, and removed as users see fit. Object-capabilitysecurity attempts to resolve some of the problems andshortcomings of traditional ACL solutions, for exam-ple: ACL-based security is server-bound and, thus, apotential bottleneck, participants cannot react dynam-ically to ACL changes, authentication is required forACL solutions, and ACLs cannot operate at a fine-grained level without incurring noticeable overhead(related to the bottleneck issue).

We agree that object-capability security holdspromise and should be explored further. However, wealso believe that WonderDAC’s use of ACLs remainspractical and viable. First, although ACL-based se-curity is server-bound, this does not necessarily makeit a bottleneck. Wonderland uses the Darkstar gameserver in which “work is broken into small units, eachcorresponding to one action in a game, and each ofwhich can be processed anywhere on the server-sidenetwork. Individual actions are then automatically dis-tributed across all available threads and any numberof server machines for parallel execution [Sun08a].”Next, in the case of WonderDAC, changes to the ACLsof any VR object (a “cell” in Wonderland) have an im-mediate, dynamic affect on nearby users and the envi-

ronment. For example, if a participant loses or gainspermissions to interact with a cell, they will imme-diately see the cell disappear or materialize, respec-tively. Regarding the need for authentication in ACLsolutions, object-capability security must grapple withforged and re-played capabilities, that is: a maliciousparty could generate fake capabilities or monitor com-munications and steal copies of capabilities for lateruse. Encryption and digital signatures are a naturalway to deal with these issues, but require that somesort of public key infrastructure be established andmaintained. Not only is this solution authentication-based, it also leads to the overhead and central author-ity that object-capability security hopes to avoid. Fi-nally, on the point of fine-grained operation, Wonder-DAC is applicable at the level of a Wonderland cell,where a cell can be a single, 3D virtual asset, or a mas-sive hierarchy of other cells. As a result, WonderDACapplies equally to the smallest and largest dimensionsof Wonderland.

3 WonderDAC Basics

3.1 System Architecture

Our discussion of WonderDAC begins with a high-level view of Wonderland’s system architecture. Fig-ure 2 shows us a diagram of components that include:

• Wonderland Server–Provides the underlyingCVE core mechanisms; WonderDAC is imple-mented, here

• jVoiceBridge–Handles Wonderland’s sound con-tent, including audio chat

• LDAP Server–Maintains all user and system ac-counts, including related DAC information

• Web Server–Stores and serves model and texturefiles to Wonderland clients via hypertext transferprotocol (HTTP); any standard Web server can beused

• Client–The client application that enables a userto interact with Wonderland

It is noteworthy that Wonderland’s design enablesits major services to be distributed among multipleserver machines: in the figure, we see a different iconfor Darkstar, jVoiceBridge, an LDAP database, and aWeb server. Although not depicted in the figure, it is

4

Client

Web Server

LDAP Server

Wonderland Server

(DarkStar)

Wonderland

Communications

Model and

Texture Files

User Account

Data

jVoiceBridge ServerSpatial Sound and

Audio Chat Data

jVoiceBridge

Communications

Figure 2: A typical Wonderland architecture configu-ration.

also possible for Darkstar to be deployed across mul-tiple servers (as noted at the end of Section 2). Ofcourse, all of these services may just as easily resideon one physical machine, if that is desired.

WonderDAC leverages Wonderland’s client-serverarrangement in order to keep a participant from be-ing in direct contact with the DAC programming. OurDAC “authority,” then, is free to be situated on oneor more secured hosts, enabling a high degree of as-surance to be associated with the Wonderland server.Moreover, by maintaining our DAC solution in onelogically central place, it becomes trivial to managemultiple perspectives of the same virtual world. Forexample, different levels of access may cause partic-ipants to see and interact with their surroundings dif-ferently. On the other hand, a decentralized CVE ap-proach, such as that found in a peer-to-peer environ-ment, would have inherent difficulties securing DACmechanisms and enabling participants to see differentversions of the same virtual world simultaneously. Inthe absence of centralized management, the ability tohandle DAC and state must be pushed to CVE partici-pants. For access controls, this means an increased riskof tampering; and for state, it means somehow gov-erning what is seen by participants who have differentprivileges in the same virtual environment.

As we have just noted, our implementation of Won-derDAC’s critical components takes place only withinserver code. Nevertheless, a client-side to Wonder-DAC does exist–it’s function, however, is purely cos-metic. Specifically, it prevents the participant from

making changes to their local representation of the vir-tual world, if these changes would not also be allowedin a global context. This client-side code is never re-lied upon for DAC purposes; if a malicious participantwere to tamper with their client, they would be lim-ited to altering their own, private representation of theCVE (they would not be able to change the server’scopy of their access control profile).

3.2 System Walkthrough

A simplified narrative of how Wonderland functions(without the WonderDAC modifications) should proveuseful at this juncture. The client begins by trans-mitting a username and password to the Wonderlandserver. In response, the server consults an LDAP di-rectory to lookup the participant and validate the givenpassword. If the credentials are invalid or the partici-pant doesn’t exist, the client is given two more chancesto log in before their connection to the Wonderlandserver is closed.

Upon validation of the username and password,the Wonderland server communicates back and forthwith the client to instantiate server- and correspondingclient-side Java objects. These represent the partici-pant’s avatar and all of the Wonderland cells visiblein the participant’s view of the virtual world. More-over, they transmit messages between one and otherto facilitate the activities of a given cell. This stepalso includes the establishment of a session betweenthe client and jVoiceBridge server, enabling the par-ticipant to hear sound and engage in audio chats. Asthe client builds a representation of the virtual world,it queries a Web server to retrieve model and texturefiles for rendering.

Once logged in and initialized, the client communi-cates with the Wonderland server through both directand publish/subscribe channels, and with other clientsthrough publish/subscribe channels. All of these chan-nels exist on the Wonderland server; however, datafor sound and audio chat flow between clients and thejVoiceBridge server.

As the participant guides their avatar about the vir-tual world, the server tracks which cells become visi-ble and which fall outside of the client’s perspective.Newly visible cells are configured on the server andclient, and then rendered in the client’s display or, ifaudio-related, played over the client’s speakers.

When the client exits Wonderland, the participantdeparts from all of the communication channels joined

5

earlier, and an orderly disposal of the Java objectstracking their state and avatar takes place.

3.3 The Wonderland Cell

As mentioned above in Section 2, the virtual worldin Wonderland is comprised of cells, where each cell“represents a 3D volume in the world [Sun08b].” Be-cause cells are hierarchical, one root cell correspondsto the entire virtual world, while child cells through-out the hierarchy are associated with more fine-grainedelements (or assets) of that world. By adding DACattributes and methods to the basic Wonderland cellclass (CellGLO.java), we are able to apply access con-trol in a truly homogeneous and ubiquitous manner.This is key to maintaining the simplicity of our DACsolution throughout Wonderland.

The Wonderland cell hierarchy itself is imple-mented as another hierarchy of XML files. Storedon the Wonderland server or elsewhere, these files de-scribe the layout of the virtual world and are collec-tively referred to as the Wonderland file system (WFS)[Sun08d]. For the purpose of testing WonderDAC, wedevised the WFS depicted in Figure 3. As with thecomposition of all WFS hierarchies, our test WFS in-cludes a root directory with a name ending in the-wfssuffix, child directories with names that end in the-wld suffix, and XML cell files with names ending in-wlc.xml. It is not the case that one cell file must cor-respond to only one object within the virtual world. In-stead, an array of object models can be included withina cell’s XML specification, thereby enabling more ef-ficient handling of all the objects involved. Of course,WonderDAC operates at the level of a cell, so a multi-model cell’s objects would be protected as a group un-der one access control arrangement.

All XML cell files are serializations of a Java beancalled BasicCellGLOSetup. This bean is responsiblefor the fundamentals of building a generic cell, and,so, has been modified by WonderDAC to include sev-eral basic access control elements, each represented bya Java String object: accessOwner, accessGroup, ac-cessGroupPermissions, and accessOtherPermissions.The first String, accessOwner, denotes the participantwho owns a cell in question; this account implicitlyhas full control over the cell. The next String, access-Group, denotes the group that is assigned to the cell.Stored in the third String, accessGroupPermissions,are the permissions that determine how group mem-bers can access the cell. Similarly, the final String, ac-

Figure 3: The Test World WFS Hierarchy.

cessOtherPermissions, maintains the permissions thatdetermine how those who are neither the owner normembers of the cell’s group may access the cell. Per-missions are specified as numeric values between 0and 3 (see the table in Subsection 3.4.1 for an expla-nation of what these numbers denote). Figure 4 showsan excerpt from an XML file with these four Stringsincluded. The CellGLO.java class also includes mod-ifications that mirror the Java String objects found inBasicCellGLOSetup.

Regarding cell hierarchies, if the parent of a groupof cells is made inaccessible to a participant, then allof the cells underneath that parent also become inac-cessible, regardless of how their permissions are con-figured. For example, suppose a participant can ac-cess a room and the virtual objects contained therein,and the room’s cell is the hierarchical parent for thoseobjects. Losing access to the room would immedi-ately cause the entire space (including the containedobjects) to disappear from the participant’s local per-spective of the virtual world. Only by restoring accessto the room’s cell would the room and its objects be-come visible again. Although not an intuitive virtualworld design, the room’s objects could have a parentother than the room’s cell; in this circumstance, the ob-

6

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_13" class="java.beans.XMLDecoder"> <object class="org.jdesktop.lg3d.wonderland.darkstar.server.setup.BasicCellGLOSetup"> ... <void property="accessOwner"> <string>twright</string> </void> <void property="accessGroup"> <string>world</string> </void> <void property="accessGroupPermissions"> <string>2</string> </void> <void property="accessOtherPermissions"> <string>0</string> </void>... </object> </java>

Figure 4: An excerpt from a sample XML cell file.

jects would not necessarily disappear if access to theroom were lost.

An important characteristic of Wonderland cells thathas not yet been discussed is that they may overlap inthe virtual world. For spatial cells, this turns out tohave significant consequences regarding a DAC solu-tion. For example, how do we determine access rightsfor a virtual room that falls partially or completely in-side another space with different permissions? In thespirit of simplicity, we elected to use the following ap-proach with WonderDAC.

When a participant’s avatar moves into an area ofoverlapping spatial cells, the group and permissionsfor the most restrictive cell at that location are appliedto the avatar for the time spent in the area. Avatarsare similar to other cells in that they are subject to thesame DAC treatment. By dynamically assigning theirpermissions, the avatars of participants who can ac-cess a space will be invisible to those who cannot ac-cess the same space. For example, if avatar X entersa spatial cell that avatar Y’s participant cannot access,then avatar X will become invisible to avatar Y’s par-ticipant. Avatar X will reappear only if it moves intoa space accessible to avatar Y’s participant. (See fig-ures 6 and 6.) When overlapping spatial cells have thesame permissions, the dynamic assignment of a groupand permissions to an avatar is handled in the follow-ing order:

1. If a space is owned by the participant, the partic-ipant’s avatar takes that spatial cell’s group andpermissions

2. If a participant does not own any of the overlap-ping cells, but belongs to one of the cells’ groups,

the participant’s avatar takes that cell’s group andpermissions

3. Otherwise, the participant’s avatar takes thegroup and permissions of the first spatial cell ex-amined

When entering a non-overlapping space, an avataradopts that space’s group and permissions straightaway.

3.4 Roles and Permissions

The approach embodied by WonderDAC is patternedafter an idealized form of UNIX file system accesscontrol. A Wonderland cell may be thought of as a filesystem entity to which we assign roles with permis-sions. In keeping with our theme of simplicity, thereare only three roles (owner, group, and other) withtwo permissions (interact andalter) per role possible.While this design may seem overly blunt (e.g., limitinghow finely the attributes and capabilities of a cell maybe restricted), we believe that a more complex solutionwould either be avoided or used incorrectly by partic-ipants, and, thus, negate the whole purpose of havinga DAC implementation. Because the basic tenets ofUNIX file system access controls have become so en-grained in modern operating systems, WonderDAC’sapproach should seem natural and familiar to anyonewho has had a reasonable level of interaction with atypical workstation.

We consider the WonderDAC permissions first andthen the roles.

3.4.1 Permissions

The interact permission is an analog to the read andexecute UNIX file system privileges, while thealterpermission is an analog to write.Interactallows a par-ticipant to see and, in a limited sense, use a cell,1 whilealter enables the participant to make changes to thecell. For example, if a participant hasinteractpermis-sion for a whiteboard cell, they will be able to see thewhiteboard and any image drawn there. If, in addition,the participant hasalter permission, they will be ableto draw upon or erase the whiteboard cell. Havingal-ter permission without simultaneously havinginteractpermission for a cell is logically the same as having no

1Another way to view theinteractpermission is that it enablesan participant’s local representation of the virtual worldto receivea cell’s updates.

7

permissions. This is because it is impossible to makechanges to a cell with which one cannot be in contact.

WonderDAC permissions are programmaticallyrepresented by numeric values in the following man-ner:

Table 1: WonderDAC Permissions

Permissions Numeric Value

IA 3I - 2- A 1

None 0

3.4.2 Roles

The owner role implicitly maintains full control of agiven cell. Simply put, a cell’s owner always hasin-teractandalter permissions for the cell. The only timethis can change is when ownership is willingly trans-fered to a different participant, whereupon the newowner implicitly and immediately assumes full controlover the cell.

The group role is both static and dynamic in na-ture. The static part of this duality includes three sys-tem groups (admin, users, andworld) that help man-age access along administrative, regular user, and fullypublic fronts, respectively. Wonderland users onlybecome members of these groups through the actionof the system administrator.2 In fact, these groupsare not hardcoded in WonderDAC, but exist entirelywithin the Wonderland LDAP user account database.For this reason, any number of of other/additional ap-propriately named static groups may be employed.3

The only requirement is that referential integrity bemaintained among all of the user accounts and systemgroups.

Regarding the dynamic nature of groups, Wonder-DAC supports the ability for participants to create andmanage their own ad hoc, personal groups. These maybe applied to any cells owned by a given user, and,thus, enhance the discretionary element of access con-trol. A participant may create an ad hoc group by nam-ing the group and adding at least one other user; the

2The unique, dummy accounts generated by Wonderland’sbuilt-in test mechanism (e.g., Bench-1, Bench-2, ..., Bench-N) areautomatically added to theworld group.

3Although WonderDAC does not hardcode group names, itdoes include specifications for name composition: no more than15 alpha-numeric characters and no spaces.

moment a personal group contains no users it is auto-matically deleted by the Wonderland server–any cellsthat employ a defunct personal group must be assignedto a different group by the owner.

The other role is simply a catch-all that applies tothose participants who are neither the owner nor groupmembers of a given cell.

Finally, the permissions assigned to WonderDACroles are mutually exclusive: a participant can only re-side in one role with respect to any given cell. Duringaccess checks, a user is determined to be the owner ofan object, a member of the object’s group, or part ofthe other role. This enables roles to enforce the ad-dition or removal of privileges for specific groups ofparticipants regarding a particular cell.

3.5 System Walkthrough Redux

Returning to our earlier narrative of how Wonderlandfunctions (Subsection 3.2), we are now ready to in-clude WonderDAC in our walkthrough.

The client begins by transmitting a username andpassword to the Wonderland server. In response, theserver consults an LDAP directory to lookup the par-ticipant and validate the given password. If the cre-dentials are invalid or the participant doesn’t exist, theclient is given two more chances to log in before theirconnection to the Wonderland server is closed. Uponvalidation of the username and password, the partici-pant’s group membership information is obtained fromthe LDAP directory and stored on the Wonderlandserver in a user profile.

Communication between the server and client thentakes place to instantiate server- and correspondingclient-side Java objects. These represent the partici-pant’s avatar and all of the Wonderland cells visiblefrom the participant’s view of the virtual world. More-over, they transmit messages between one and otherto facilitate the activities of a given cell. However,these messages can be ignored by the server when theparticipant does not havealter permission for the cellin question. As the server discovers cells that mightbe visible to the client, it determines the participant’slevel of access; only cells for which the participant hasinteractpermission are setup. During all of this initial-ization, the client also establishes a session with thejVoiceBridge server, enabling the participant to hearsound and participate in audio chats. As the clientbuilds a representation of the virtual world, it queries aWeb server to retrieve model and texture files for ren-

8

dering.Once logged in and initialized, the client communi-

cates with the Wonderland server through both directand publish/subscribe channels, and with other clientsthrough publish/subscribe channels. All of these chan-nels exist on the Wonderland server; however, soundand audio chat data flow exclusively between clientsand the jVoiceBridge server.

While the participant guides their avatar about thevirtual world, the server tracks which cells becomevisible and which fall outside of the client’s perspec-tive. As in the initial setup of the virtual world, onlythose cells with which the participant can interact aremade available to and rendered by the client. Cells thatbecome inaccessible are immediately removed fromthe client’s and server’s representations of the virtualworld for the participant. Newly visible cells are con-figured on the server and client, and then rendered inthe client’s display or, if audio-related, played over theclient’s speakers.

When the client exits Wonderland, the participantdeparts from all of the communication channels joinedearlier, and an orderly disposal of the Java objectstracking their state and avatar takes place.

4 Network Communications Security

It is important to bear in mind that WonderDAC op-erates at the top two layers (in-world access and userexperience) depicted in Figure 1. This isn’t to suggestthat network communications, the bottom layer, hasnothing to do with access control. At this layer, en-cryption and non-repudiation would each play a crit-ical role: respectively, assuring that data transmittedwithin the Wonderland system maintain their privacyand integrity, and guaranteeing that client and serverendpoints are who they claim. Wonderland does notcurrently support such controls, making it vulnerableto eavesdropping, spoofing (where a malicious agentpretends to be another participant), and integrity loss.More to the point, WonderDAC could be subverted bya malicious participant who wished to carry out anyof these attacks. Hence, it would seem natural to addnetwork communications controls to Wonderland insupport of WonderDAC. Although we have elected tofocus solely on WonderDAC in our work, we believethat enhancing Wonderland at the network communi-cations layer is a conceptually straight-forward task asFigure 5 shows.

The central idea behind this figure is to use asym-

Client

Web Server

LDAP Server(Account data

Include public

Keys)

Wonderland Server

(DarkStar)

Wonderland

Communications

(encrypted)

Model and

Texture Files

(encrypted)

User Account

Data (ecrypted)

jVoiceBridge ServerSpatial Sound and

Audio Chat Data (encrypted)

jVoiceBridge

Communications

(encrypted)

Web Server

Communications

(encrypted)

Figure 5: A typical Wonderland architecture configu-ration with secure network communications.

metric key cryptography to protect lines of communi-cation and identify users and services. Presumably, aprotocol such as secure sockets layer (SSL) or trans-port layer security (TLS) could be used to authenti-cate clients and servers to one and other and negotiatesymmetric keys for data stream encryption. For con-venience, the LDAP server could store public keys aspart of user account records (private keys would haveto be securely maintained by participants and Won-derland system administrators, respectively). Finally,the Web server would need to be capable of commu-nicating with the Wonderland server to prevent unau-thorized access to model and texture files (i.e., theWeb server could validate access attempts using pre-existing WonderDAC mechanisms). Thus, a new com-munications channel, indicated by a dashed connectorline in Figure 5, would have to be established betweenthese two servers.

5 WonderDAC by Example

Prior to the implementation of the WonderDAC pro-totype, we discerned five areas that needed to be ad-dressed by any successful CVE DAC solution. Thesewere captured as the use case scenarios listed in Sec-tion 1, and only partially treated by the prototype.The following subsections reiterate these scenarios (inslanted text), as they were stated in our earlier work,and include brief technical discussions and examplesof how each scenario is now handled by WonderDAC.

9

5.1 Use Case 1: Spatial Object Restrictions

A participant should only be able to enter, hear, andsee into a virtual space if they are the owner of thespace, a member of the space’s group (and the grouphas interact permission), or the space is defined withinteractpermission for theother role. When a partic-ipant’s avatar has entered a space, the avatar shouldonly be visible and heard by other participants whoalso haveinteractpermission (but may or may not beinside the space).

A participant should only be able to change a vir-tual space (by speaking in, or deleting/updating thespace) if they are the owner of the space, a memberof the space’s group (and the group has alter permis-sion), or the space is defined withalter permission forthe other role. Although it is possible for a space tohave only thealter permission assigned to thegroupor otherroles, the result of such a configuration wouldbe meaningless, since non-owners would be incapableof entering the space to begin with.

In WonderDAC, spatial cells are identified as oneof two server-side classes: SimpleTerrainCellGLO orMultiModelCellGLO (both extend another class calledStationaryCellGLO, which represents cells that can-not move). As noted in Subsection 3.3, WonderDACneeds to detect where a participant’s avatar is locatedin order to manage access to spaces. Both the detec-tion and the DAC assessment take place in a methodcalled revalidate, which belongs to the server-sideclass UserCellCacheGLO. This method is very impor-tant to WonderDAC’s implementation: not only doesit deal with spatial access control, it reviews all othercells visible to the participant and determines thosecells’ interact and alter accessibility. Each Wonder-land participant has an associated UserCellCacheGLOobject that builds, maintains, and prunes all of the vis-ible (and, therefore, accessible) cells comprising thatparticipant’s local perspective of the virtual world.

When a participant lacksinteract permission for aspatial cell, that cell isn’t made available to the partic-ipant’s client for rendering, or, if already rendered, itis removed from the cache of cells associated with theclient. If the participant lacksalter permission for aspatial cell they become muted when their avatar re-sides in that space.

In figures 6 and 7 we see the result of a private space(a second floor loft) being made accessible relative totwo participants. Initially, these partcipants can seeneither the space, nor the TWright avatar residing inthe space. Once both participants are grantedinter-

Figure 6: Because their participants do not haveinter-act permission for the loft, the JUser and Bench-415avatars cannot see the loft stairs or the TWright avatar.

act permission, however, the space and avatar becomevisible.

5.2 Use Case 2: Non-spatial Object Restric-tions

A participant should only be able to view and, if ap-plicable, hear a non-spatial object (e.g., a whiteboard,phone, or X Window application) if they are the ownerof the object, a member of the object’s group (and thegroup hasinteractpermission), or the object is definedwith interactpermission for theother role. For exam-ple, a participant with onlyinteract permission for awhiteboard can view the whiteboard and its contents,but cannot change or add to those contents. Similarly,a participant with onlyinteract permission for a con-ference phone, can view and hear the phone, but can-not join in the conversation.

A participant should only be able to change/utilize anon-spatial object if they are the owner of the object, a

10

Figure 7: Now granted the appropriate permission,the loft and TWright avatar appear for the JUser andBench-415 participants.

member of the object’s group (and the group hasalterpermission), or the object is defined withalter permis-sion for theotherrole. Similar to Use Case 1, althoughit is possible for a non-spatial object to have only thealter permission assigned to thegroupandotherroles,such a configuration is meaningless since non-ownerswould be unable to view/hear the object in the firstplace.

Between this and the first scenario, almost all pos-sible Wonderland cell types are covered. As in thefirst use case, a participant’s access to a non-spatialcell is determined by therevalidatemethod found inthe UserCellCacheGLO class. Unlike spatial cells,however, non-spatial cells require additional handlingmechanisms on the client-side. For example, Won-derland’s PDF viewer, video viewer, and VNC clientcells can all be shared by multiple, simultaneous par-ticipants; removinginteractpermission for some userswhile they are working with these cells means havingto deal with server-side control and synchronizationissues. Also, as discussed in Subsection 3.1, Wonder-DAC’s client-side handles cosmetic issues that resultwhenalter permission is not granted for a non-spatialcell. For example, this prevents a user from drawingon their local copy of a Wonderland whiteboard whenthey do not have permission to update the whiteboardglobally.

Figures 8 and 9 demonstrate how WonderDAC canrestrict access to a whiteboard cell. The same principleapplies equally to all other Wonderland cells.

5.3 Use Case 3: Audio Conversation Restric-tions

Two or more participants engaged in audio chat shouldbe able to restrict their conversation to themselves(somewhat like having a “cone of silence” at their dis-posal). Other participants should be able to solicit theinitial group to join in the conversation if the groupwishes. This amounts to a specialized version of UseCase 1 except that an ephemeral, invisible space is cre-ated around the participants:

1. A temporary group role, to which all of the con-versation participants belong, is created and as-signed to the invisible space

2. Interactandalter permissions are assigned to thespace’s group role

3. New participants may be added to the temporarygroup role as desired by the initial conversation

11

Figure 8: Configuring a Wonderland whiteboard toprevent updates from everyone but the owner.

Figure 9: Using a Wonderland whiteboard; onlyTWright, the owner, is able to alter the whiteboard’scontents.

12

participants

It should be possible to assign/remove theinteractand alter permissions for the invisible space’sotherrole. This could enable, through the assignment ofonly the interact permission, members of the tempo-rary group to converse, while all others can listen butnot interrupt. The use ofalter permissions alone forthe invisible space’sother role may or may not makesense, depending on the desires of the conversationparticipants: a participant in theother role would beable to speak in, but unable to hear, the conversation.

Ultimately, this use case was handled by coalesc-ing two elements: our implementation of the first sce-nario (spatial object restrictions) and Wonderland 0.4’sintroduction of an actual cone-of-silence cell.4 Byadding roles and ad hoc groups to the newly availablecone-of-silence cell, it becomes possible to restrict au-dio conversations in the way we desire. However, mi-nor differences between this and our third use casespecifications do exist. For example, Wonderland’scone-of-silence is not an ephemeral, invisible space,as prescribed by the use case scenario; it is a translu-cent cone that stays suspended over the floor to markoff an area for protected audio chats.5 In addition, allparticipants of a protected chat must haveinteractper-mission for the cone-of-silence cell, or the cell will notexist in their client-side representation of the virtualworld. With only interact permission (i.e., noalterpermission), a participant will see the cone-of-silenceobject, but be unable to hear or speak in the protectedaudio chat. This is the most significant departure fromthe use case, which specifies that a participant may beable to speak in a conversation they cannot also hear.Because the need for this ability is, at best, rare, andsimplicity is served by streamlining functionality, wedecided to drop this part of the use case implementa-tion.

Figures 10, 11, and 12 demonstrate how an adhoc group may be created and assigned to a cone-of-silence cell in order to enabled a private conversa-tion among two participants (others, of course, may beadded to the group and conversation as desired).

To configure a space that simply allows one or moreparticipants to speak while others can only listen, thecone-of-silence is not an appropriate tool. Instead,

4The cone-of-silence cell is implemented on the server by theConeOfSilenceCellGLO class, which extends the EnterExitCell-GLO class. EnterExitCellGLO is a child of StationaryCellGLO.

5Participants inside the cone-of-silence can only hear eachother, while those outside cannot hear inside the cone-of-silence.

Figure 10: Creating an ad hoc group to manage a Won-derland cone-of-silence.

Figure 11: Assigning an ad hoc group to a cone-of-silence.

Figure 12: Having a private conversation inside acone-of-silence.

13

Figure 13: Muted avatars being addressed by a speak-ing avatar.

such an area is created by enabling a spatial cell’sin-teract andalter permissions for a group of speakers,and just theinteract permission for the cell’sotherrole. A space of this type could facilitate user presen-tation’s. Following a presentation, questions could beasked of the presenter by enabling thealter permissionfor the spatial cell’sother role. Figure 13 depicts theavatar TWright addressing two other avatars who arenot allowed to speak in the area where they reside (asindicated by the square brackets around their names).

5.4 Use Case 4: Avatar Cloaking

A participant should be able to disguise their avatar’sappearance. Each avatar should have agroup role thatis unique to its owner. By assigning or removing in-teract permissions to this group or to the avatar’sotherrole, the appearance of the avatar should be control-lable by its owner. A participant should be able tosee an avatar’s true image if they are a member of theavatar’s group (and the group hasinteractpermission),or the avatar is defined withinteract permission forthe other role. Otherwise, a generic image should bedisplayed by the avatar. The use ofalter permissionsshould be ignored, here: only the owner should be per-mitted to make changes to an avatar’s appearance.

As with the last use case, our implementation ofthis scenario departs somewhat from the specificationsgiven; there are two issues driving this. First, we dis-covered that Wonderland uses participant IDs whennaming some of the communication channels createdbetween clients and the server. Because of this, a ma-licious participant could monitor communications be-tween their Wonderland client and the server to figure

out the identity of a cloaked individual. Second, man-dating that an avatar have a group role unique to itsowner seemed unnecessarily strict: as with all Won-derland cells, an owner should be able to assign anygroup they wish to their avatar.

Our answer to the above issues is, as always, guidedby our mantra of simplicity: we treat the avatar likeany other cell. If a participant does not haveinteractpermission for a particular avatar, that avatar will notexist in the participant’s local perspective of the virtualworld. This entails removing (or never establishing)all traces of the avatar and its participant, includingrelated communication channels, relative to unautho-rized participants. Thegroup role issue is resolved asa natural consequence of treating an avatar like otherWonderland cells and enables a participant to apply adhoc groups to their avatar, as well.

An interesting side effect of being able to handle thespatial access control situations outlined at the end ofSubsection 3.3, is that we need two sets of roles foreach avatar. One set helps WonderDAC sort throughaccess to spaces that may or may not overlap, whilethe other handles avatar cloaking.

Figures 14 and 15 demonstrate how an avatar cloakmay be configured–in this case, the TWright avatarseems to disappear completely from the virtual world,as far as the other participants are concerned.

5.5 Use Case 5: Permissions and OwnershipChanges

All participants should be able to determine the owner-ship of a VR object. Also, a participant should be ableto change permissions for thegroupandotherroles ofany object they own, or, if desired, assign ownershipof the object to another participant/group. The inter-face to carry out these activities should be simple andaccessible through mouse interactions with the objectin question.

This use case is handled as stated, but with an addi-tional interface to permit the creation and managementof ad hoc groups. For the purpose of confidentiality,when a participant who is not the owner of a cell re-views that cell’s DAC configuration, they will only seeagrouprole name if they happen to be a member of thegroup. This is a matter of “least privileges,” wherebya user can access only the information and resourcesneeded to carry out their authorized activities. Also,WonderDAC handles all user input sanity checking onthe server, although, for convenience, the Wonderland

14

Figure 14: Configuring an avatar cloak. Figure 15: Deploying an avatar cloak.

15

Figure 16: The Wonderland client’s Tools menu, in-cluding the newly added Avatar Cloak and Ad HocGroup options.

Figure 17: The Avatar Cloak dialog box.

client engages in simple composition checks of any-thing the participant enters in the interface dialogs.

Figure 16 shows the Wonderland client’s Toolsmenu, where two WonderDAC options have beenadded: Avatar Cloak and Ad Hoc Groups. Sample dia-log box images for both are provided in figures 17 and18.

The Avatar Cloak dialog box (Figure 17) is the sim-plest of the WonderDAC interfaces. The participantcan apply any group they wish (system or ad hoc) totheir avatar, and then configure theinteractpermissionfor this group and theother role as desired.

The Ad Hoc Group dialog box (Figure 18) enables aparticipant to manage any pre-existing ad hoc groupsor create new ones. Management consists of adding

Figure 18: The Ad Hoc Group dialog box.

users to or removing users from a particular group. Byentering a name in the “New Group” text box, an adhoc group can be started; adding at least one user tothe group and clicking the “Save” button will createand store the group on the LDAP server. As soon asan ad hoc has no members it is automatically removedby Wonderland server–it is up to the owner of any cellsusing a defunct group to assign new groups as appro-priate. All Wonderland user accounts have a built-inad hoc group named after the user ID; this group cannever be removed.

The WonderDAC configuration dialog box (Figure19) is invoked by a right mouse click on whatever cella participant wishes to manage or review. More specif-ically, two-dimensional windows (e.g., PDF viewer,movie viewer, whiteboard, VNC client, X Window ap-plication) have a small, translucent, yellow button intheir upper-left corner that opens this dialog upon aright mouse click; all other Wonderland cells respondto a right mouse click anywhere within their bound-ary. The contents of the WonderDAC configuration di-alog include the current owner and group for the cell inquestion, along with permissions settings for thegroupandother roles. There is also a “Recursive” checkboxto indicate whether or not a new DAC configurationshould be applied to the cell and its children.6 When-ever a new owner is selected for a cell, the group isautomatically forced to be “world.” This ensures thatthe cell is never assigned to a group in which the newowner is not a member.

6In the current version of WonderDAC, only one level of chil-dren is recursively updated.

16

Figure 19: The WonderDAC configuration dialog box.

5.6 Summary Use Case Table

Table 2 summarizes the use case scenarios discussedabove, including the semantics of permissions settings.

6 Conclusion and Future Work

WonderDAC is intended to address a serious defi-ciency in state-of-the-art CVEs: the lack of a func-tional, comprehensive, yet simple means of discre-tionary access control. Although some commercialCVE systems offer DAC capabilities, their controls areoften limited in scope (e.g., oriented toward the man-agement of virtual land) and somewhat complex in na-ture. Open source CVEs are arguably worse in thatthey tend to offer little if any DAC capabilities.

Patterned after idealized, UNIX file system accesscontrols, WonderDAC extends Project Wonderland 0.4by introducing role-based access controls at the levelof a Wonderland cell. Access to a cell is handled ac-cording three roles:owner, group, and other. Twopermissions,interactandalter, may be enabled or dis-abled for thegroup andother roles, while theownerrole always maintains full control over a given cell.Five use case scenarios were defined and partially im-plemented for the WonderDAC prototype we createdearlier. In moving from prototype to full solution wehave had to adjust and streamline our application ofthe third and fourth use cases (Audio Conversation Re-strictions, and Avatar Cloaking, respectively); the re-maining use cases, however, have been implementedas specified.

Despite the broad scope and relative completenessof WonderDAC’s current iteration, much work re-mains. First, Wonderland 0.4’s integration of shared XWindow applications, while functional, is not optimal.This has led to constraints for WonderDAC, such asthe inability to control who is allowed to start or stopan X Window application within a given space. Next,WonderDAC’s user interface should eventually be mi-grated from Java Swing to something that is renderedwithin the Wonderland client window. Finally, a vari-ety of administrative tools need to be created for Won-derDAC to more easily enable activities such as pass-word changes and account management (at the mo-ment, all such undertakings are handled by the Won-derland/WonderDAC administrator through an LDAPbrowser/editor).

17Table 2: Summary of Access Control Use Cases

Use Case Permissions Meaning for Group Role Meaning for Other Role

Spatial Object I A Any member of the ob-ject’s group can enter, see,and hear into the space.All such constituents canspeak within and change thespace, too.

All participants who arenot members of the ob-ject’s group can enter, see,and hear into the space.All such constituents canspeak within and change thespace, too.

I - Any member of the object’sgroup can enter, see, andhear into the space. Allsuch constituents are unableto speak within and changethe space.

All participants who arenot members of the object’sgroup can enter, see, andhear into the space. Allsuch constituents are unableto speak within and changethe space.

- A Meaningless: a memberof the object’s group canspeak within and change thespace, but they are unable toenter the space.

Meaningless: all partici-pants who are not membersof the object’s group canspeak within and change thespace, but they are unable toenter the space.

- - No member of the object’sgroup can enter, see, or hearinto the space. All suchconstituents are unable tospeak within and change thespace.

All participants who arenot members of the object’sgroup cannot enter, see, orhear into the space. Allsuch constituents are unableto speak within and changethe space.

18Table 2:Continued

Use Case Permissions Meaning for Group Role Meaning for Other Role

Non-spatial Ob-ject

I A Any member of the object’sgroup can see and, if ap-plicable, hear the object.All such constituents canchange the object, too.

All participants who arenot members of the object’sgroup can see and, if ap-plicable, hear the object.All such constituents canchange the object, too.

I - Any member of the object’sgroup can see and, if appli-cable, hear the object. Allsuch constituents are unableto change the object.

All participants who arenot members of the object’sgroup can see and, if appli-cable, hear the object. Allsuch constituents are unableto change the object.

- A Meaningless: a memberof the object’s group canchange the object, but theyare unable to see or, if ap-plicable, hear the object.

Meaningless: all partici-pants who are not membersof the object’s group canchange the object, but theyare unable to see or, if ap-plicable, hear the object.

- - No member of the object’sgroup can see, change, or, ifapplicable, hear the object.

All participants who arenot members of the ob-ject’s group cannot enter,see, change, or, if applica-ble, hear the object.

Audio Conver-sation

I A All member of the cone-of-silence’s group can hear andspeak in the conversation.

All participants who are notmembers of the cone-of-silence’s temporary groupcan hear and speak in theconversation.

19Table 2:Continued

Use Case Permissions Meaning for Group Role Meaning for Other Role

I - All members of the cone-of-silence’s temporary groupcan see the cone-of-silencecell, but cannot use the cell.

All participants who are notmembers of the cone-of-silence’s temporary groupcan see the cone-of-silencecell, but cannot use the cell.

- A Meaningless: all membersof the cone-of-silence’stemporary group cannot seeor use the cone-of-silencecell. This would prevent aprivate conversation fromtaking place.

All participants who are notmembers of the cone-of-silence’s temporary groupcannot see or use the cone-of-silence cell. This wouldprevent a private conversa-tion from taking place.

- - No member of the cone-of-silence’s group can see anduse the cell.

All participants who are notmembers of the cone-of-silence cell cannot see anduse the cell.

Avatar Cloak I A Any member of the object’sgroup can see and interactwith the avatar. The al-ter permission is ignored:only the owner is allowed tochange an avatar.

All participants who arenot members of the avatar’sgroup can see and interactwith the avatar. The al-ter permission is ignored:only the owner is allowed tochange an avatar.

I - Any member of the object’sgroup can see and interactwith the avatar. (Effectivelythe same asI A permissionsabove)

All participants who arenot members of the avatar’sgroup can see and interactwith the avatar. (Effectivelythe same asI A permissionsabove)

20Table 2:Continued

Use Case Permissions Meaning for Group Role Meaning for Other Role

- A No member of the avatar’sgroup can see or interactwith the avatar. The al-ter permission is ignored:only the owner is allowed tochange an avatar.

All participants who arenot members of the avatar’sgroup cannot see or inter-act with the avatar. Thealter permission is ignored:only the owner is allowed tochange an avatar.

- - No member of the avatar’sgroup can see or interactwith the avatar. (Effectivelythe same as- A permissionsabove)

All participants who arenot members of the avatar’sgroup cannot see or interactwith the avatar. (Effectivelythe same as- A permissionsabove)

21

References

[Act08a] Activeworlds, Inc.,Online help manual:Shared privileges, Found on the WorldWide Web, April 2008.

[Act08b] , Online help manual: World ad-min features dialog, Found on the WorldWide Web, April 2008.

[Act08c] , Online help manual: World ad-min rights dialog, Found on the WorldWide Web, April 2008.

[BB99] Adrian Bullock and Steve Benford,Anaccess control framework for multi-usercollaborative environments, GROUP’99: Proceedings of the internationalACM SIGGROUP conference on Sup-porting group work (New York, NY,USA), ACM, 1999, pp. 140–149.

[BBF98] Andreas Butz, Clifford Beshers, andSteven Feiner,Of vampire mirrors andprivacy lamps: privacy managementin multi-user augmented environments,UIST ’98: Proceedings of the 11th an-nual ACM symposium on User interfacesoftware and technology (New York, NY,USA), ACM, 1998, pp. 171–172.

[CW00] Elisabeth Cuddihy and Deborah Walters,Embodied interaction in social virtualenvironments, CVE ’00: Proceedingsof the third international conference onCollaborative virtual environments (NewYork, NY, USA), ACM, 2000, pp. 181–188.

[HD96] Steve Harrison and Paul Dourish,Re-place-ing space: the roles of place andspace in collaborative systems, CSCW’96: Proceedings of the 1996 ACM con-ference on Computer supported coopera-tive work (New York, NY, USA), ACM,1996, pp. 67–76.

[HTK+97a] S. Honda, H. Tomioka, T. Kimura,T. Ohsama, K. Okada, and Y. Matsushita,A virtual office environment for home of-fice worker based on 3d virtual space,Virtual Systems and MultiMedia, 1997.VSMM ’97. Proceedings., InternationalConference on (10-12 Sep 1997), 38–47.

[HTK+97b] Shinkuro Honda, Hironari Tomioka,Takaaki Kimura, Takaharu Ohsawa,Kenichi Okada, and Yutaka Matsushita,A virtual office environment based on ashared room realizing awareness spaceand transmitting awareness information,UIST ’97: Proceedings of the 10th an-nual ACM symposium on User interfacesoftware and technology (New York, NY,USA), ACM, 1997, pp. 199–207.

[Lin07a] Linden Research, Inc.,Knowledge base:Inworld issue (cooperative object edit-ing), Found on the World Wide Web,April 2007.

[Lin07b] , Knowledge base: Permissions,Found on the World Wide Web, April2007.

[Lin08] , Knowledge base: Land and thelinden dollar economy, Found on theWorld Wide Web, February 2008.

[MAIO97] Elizabeth D. Mynatt, Annette Adler,Mizuko Ito, and Vicki L. O’Day, De-sign for network communities, CHI ’97:Proceedings of the SIGCHI conferenceon Human factors in computing systems(New York, NY, USA), ACM, 1997,pp. 210–217.

[Mak04] Makena Technologies, Inc.,Gettingaround: Understanding permissions,Found on the World Wide Web, August2004.

[Mak06] , Giving and receiving, Found onthe World Wide Web, May 2006.

[Mak08] , Development lot setup manual,Found on the World Wide Web, March2008.

[MCM06] Liliane S. Machado, Thaise K. L. Costa,and Ronei M. Moraes,A 3d intelligentcampus to support distance learning, In-formation Technology Based Higher Ed-ucation and Training, 2006. ITHET ’06.7th International Conference on (2006),792–799.

[MZHO07] Wenjun Ma, Ying Zhu, R.W. Harrison,and G.S. Owen,Ammp-extn: Managing

22

user privacy and cooperation demand ina collaborative molecule modeling vir-tual system, Virtual Reality Conference,2007. VR ’07. IEEE (2007), 301–302.

[NPVS07] Christoph Neumann, Nicolas Prigent,Matteo Varvello, and Kyoungwon Suh,Challenges in peer-to-peer gaming, SIG-COMM Comput. Commun. Rev.37(2007), no. 1, 79–82.

[PM01] S. Pettifer and J. Marsh,Collaborativeaccess model for shared virtual environ-ments, Enabling Technologies: Infras-tructure for Collaborative Enterprises,2001. WET ICE 2001. Proceedings.Tenth IEEE International Workshops on(2001), 257–262.

[SSF08] M. Scheffler, J.P. Springer, andB. Froehlich, Object-capability se-curity in virtual environments, VirtualReality Conference, 2008. VR ’08. IEEE(2008), 51–58.

[Sun08a] Sun Microsystems,Project darkstar faq,Found on the World Wide Web, 2008.

[Sun08b] , Project wonderland softwarearchitecture, Found on the World WideWeb, 2008.

[Sun08c] , Project wonderland web site,Found on the World Wide Web, 2008.

[Sun08d] , Tutorial: How to create a worldusing a wonderland filesystem (wfs),Found on the World Wide Web, January2008.

[WM08] Timothy E. Wright and Gregory Madey,Discretionary access controls for a col-laborative virtual environment, Tech.Report TR 2008-12, University of NotreDame, College of Engineering, Univer-sity of Notre Dame, Notre Dame, IN46556, September 2008.