VWRAP essentials : capabilities

so i recently got an email from a VWRAP document reviewer asking if web capabilities could be considered "security by obscurity." the simple answer is, "no. as long as you treat a web capability as a one time use password for a resource, you should be fine."

but i realized then there are a number of people who don't grok caps. if you're unfamiliar with the terms "capabilities" or "caps" or "webcaps," this blog post may be for you. (note, i'm cribbing a lot of the text of this post from an earlier message i wrote on the OGPX mailing list )

what are capabilities anyway?

in general, "capabilities" are authorization tokens designed so that possession of the token implies the authority to perform a specific action.

consider a file handle in POSIX like systems; when you open a file, you get back an integer representing the open file. you only get this file handle back if you have access rights to the file. when you spawn a new child process, the child inherits your open file handles and it too can access those files via the file handle, even though the child process lives in a completely different process space. later versions of *nix even allow you to move open file handles between unrelated processes. so the takeaway here is, it's an opaque bit of data (i.e. - a token) and if you have it, it means you have the authority to use it. and, you can pass it around if need be.

capabilities on the web extend the concept. in addition to the token implying authorization to access some resource, it usually also provides the address to access the resource. in other words, a web capability is a URL possessed by a client that the client may use to create, read, update or delete a resource.

a web capabilities in VWRAP are in the form of a "well known" portion of a URL (something like "http://service.example.org/s/") and a large, unguessable, randomly generated string (like "CE7A3EA0-2948-405D-A699-AA9F6293BDFE".) putting them together, you get a valid URL a client can use to access a resource via HTTP. In this example, that URL would be "http://service.example.org/s/CE7A3EA0-2948-405D-A699-AA9F6293BDFE".

why the heck would i ever want to do that !?

no doubt about it, this is not a "standard pattern" for web services. normally, if you have a resource, you publish a well known resource for it and if it's sensitive you require the client to log in prior to being granted access.

for example, you might have a RESTful resource at "http://service.example.org/s/group/AWGroupies" representing the group "AWGroupies". you define an API that says if you want to post a message to the group, you use HTTP POST with data (XML, JSON or whatever) implying the semantic "post this message to this group". for the sake of discussion, let's say the message looks like:

  {
 from: "Meadhbh Oh",
 message: "I'm giving 50 L$ to anyone who IMs me in the next 5 minutes!"
}

authentication is in order here, but this is a well known problem, i simply use HTTP digest auth over HTTPS (or something similar) and we're done. this is a perfectly acceptable solution.

but there are a couple of issues with this solution.

most notably, every service that presents an interface to a sensitive resource MUST understand authentication. so not only does "http://service.example.org/s/group/AWGroupies" need to understand authentication, so does "http://service.example.org/s/user/Oh/Meadhbh" and

"http://service.example.org/s/parcel/Levenhall/Infinity%20is%20full%20of%stars" and so on.

it's not a problem really, until you start adding new authentication techniques. one day your boss comes to you and tells you.. "hey! we're using Secure/IDs for everything now!" ugh. but it's

still not that painful. you've probably abstracted out authentication, so you have a map of service URLs to authentication techniques and common libraries that actually authenticate requests throughout your system.

this works until the day that your boss comes in and says... "hey! we just bought our competitor cthulhos.com! we're going to integrate their FooWidget service into our service offering! isn't it great!" and then you get that sinking feeling cause you know that this means you've got to figure a way to get their service to talk to your identity provider so their service can authenticate your customers. people who have gonethrough this know that depending on the technology this can turn out to be a bag full of pain.

the standard way of doing this is something like:

1. service request come into http://service.example.org/s/foo/Meadhbh
2. http://service.example.org/s/foo/ redirects with a 302 to http://foo.cthulhos.com/Meadhbh
3. http://foo.cthulhos.com/Meadhbh responds with a 401 getting the client to resubmit the request with a WWW-Authenticate: header.
4. the client resubmits to http://foo.cthulhos.com/Meadhbh with the proper WWW-Authenticate: header, but remember, these are example.org's customers, so
5. http://foo.cthulhos.com/Meadhbh sends a message to a private interface on example.org, asking it to authenticate the user credentials.
6. assuming the client is using valid credentials, example.org responds to cthulhos.com with the digital equivalent of a thumbs up, and finally...
7. http://foo.cthulhos.com/Meadhbh responds to the request.

and this works pretty well up until the point that the new CIO comes in and says, "infocard! we're moving everything to infocard!" there's nothing wrong with infocard, of course, but in this situation you've got to implement it at both example.org and cthulhos.com. and when we start adding to the mix the fact that the biz dev people keep trying to buy new companies and you get a new CIO every 18 months who wants a new user authentication technology, things can get out of hand.

and i didn't even talk about the fact that each time you change the authentication scheme, thick client developers have to go through the code, looking for every place a request is made.

web capabilities are not a magic panacea, but they can help out in this situation. rather than having each request authenticated, the user's identity is authenticated once at a central location (like example.org.) it coordinates with it's services (cthulhos.com) to provide a unique, unguessable URL (the capability) known only to that specific client and trusted systems (example.org and cthulhos.com)

so the flow would be something like...

1. a client logs in at http://service.example.org/s/authme and asks for a capability to use a particular service
2. http://service.example.org/s/authme verifies the user's credentials and verifies the user can access that service
3. http://service.example.org/s/authme sends a request to a private interface on cthulhos.com asking for the capability.
4. cthulhos.com generates the unguessable capability http://foo.cthulhos.com/EE409B12-6E9B-4F5B-90BF-161AE5DE410C and returns it to http://service.example.org/s/authme
5. http://service.example.org/s/authme returns the capability http://foo.cthulhos.com/EE409B12-6E9B-4F5B-90BF-161AE5DE410C to the client
6. the client uses the capability http://foo.cthulhos.com/EE409B12-6E9B-4F5B-90BF-161AE5DE410C to access the sensitive resource.

both approaches require establishing a trusted interface between example.org and cthulhos.com, but in the case of the capability example, only service.example.org has to know about the specific details of user authentication. thick client developers may also notice that they access the capability as if it were a public resource; that is, they don't need to authenticate each request.

another benefit to capabilities is that they are pre-authorized. if you have a resource that is accessed frequently (like maybe "get the next 10 inventory items" or "check to see if there are any messages on the event queue for me") you don't have to do the username -> permissions look up each time the server receives a request. for environments where the server makes a network request for each permissions check, this can lead to reduced request latency.

capabilities are not magic panaceas. there's still some work involved in implementing them and they start making a lot more sense when you have a cluster of machines offering service to a client, but deployers want identity and identity to permissions mapping functions to live elsewhere in the network than the machine offering a service. (i.e. - "the cloud" or "the grid".)

but how do i provision a capability ?

there are several ways to provision capabilities, but the approach we take in VWRAP is to use the "seed capability."

like many other distributed protocols involving sensitive resources, VWRAP interactions begin with user authentication. this is not strictly true; i'm ignoring the case where two machines want to communicate outside the context of a user request, but let me hand wave that use case away for the moment while we talk about using seed caps.

the process begins with user authentication. the VWRAP authentication specification describes this process; the client sends an avatar name and a password to an authentication server. assuming the authentication request can be validated, the server returns a "seed cap." the client then sends a list of capability names to the seed cap and awaits the response.

what the host behind the seed cap is doing while the client waits for a reply is verifying the requested capability exists and the user is permitted to perform the operation implied by the capability. (and it does this for each capability requested.)

so, for example, let's say you are a client that only wants to update a user profile and send/receive group messages. the protocol interaction might look something like this...

a. authentication : client -> server at https://example.org/login

  {
 agent_name: "Meadhbh Oh",
 authenticator: {
   type: "hash",
   algorithm: "md5",
   secret: "i1J8B0rOmekRn8ydeup6Dg=="
 }
}

b. auth response : server -> client

  {
 condition: "success",
 agent_seed_capability: "https://example.org/s/CF577955-3E0D-4299-8D13-F28345D843F3"
}

c. asking the seed for the other caps : client -> server at

https://s.example.org/s/CF577955-3E0D-4299-8D13-F28345D843F3

  {
 capabilities : [
   "profile/update",
   "groups/search"
 ]
}

d. the response with the URIs for the caps : server -> client

  {
 capabilities : {
   profile/update : "http://service.example.org/user/35A59C5D-315C-4D50-B78D-A38D41D2C90A",
   groups/search : "http://cthulhos.com/8579CE1F-9C05-43E8-8677-A645859DCD64"
 }
}

expiring capabilities

readers may notice that there is a potential "TOCTOU vulnerability." TOCTOU stands for "time of check, time of use," and refers to a common security problem. what happens if the permissions on an object change between the time the code managing the resource checks the permission and the time it performs an operation on the resource.

this is a common problem with many systems, including POSIX file descriptors. (seriously.. if you change the permissions on a file to disallow writing AFTER the file has been opened, subsequent writes on the file descriptor will not fail in many POSIX systems.)

VWRAP addresses this problem by expiring capabilities when they get old. so if you request a capability, then wait a LONG time before you access it, you may find you get a 404 response. The VWRAP specifications do not require all caps to expire, but the do require servers to signal their expiration by removing them (thus the 404 response) and require clients to understand what to do when a capability has been expired. in most cases, the appropriate response is to re-request the capability from the seed cap. if the seed cap is expired, clients should re-authenticate.

capabilities may also "expire after first use." Also called "single shot capabilities," they are used to communicate sensitive or highly volatile information to the client.

current practice is to include an Expires: header in the response from the server so the client will know when the resource expires.

introspection on capabilities

finally, RESTful resources represented by a capability are described by an abstract interface (like LLIDL), the interface description language described in the VWRAP Abstract Type System draft. several people have requested introspection so clients may request the LLIDL description of a capability and more accurately reason about the semantics of its use.

the proposed solution to this problem for VWRAP messages carried over HTTP is to use the OPTIONS method when accessing the capability (instead of GET, POST, PUT or DELETE.) upon receipt of the OPTIONS request, the server should respond with the LLIDL describing the resource.

conclusion

capabilities are cool, especially in clouds or grids.

references

A pair of Google Tech Talks at:

http://video.google.com/videoplay?docid=-8527120258517176598 , and

http://video.google.com/videoplay?docid=8799856896828158583

provide a pretty good technical introduction to the concept of capabilities.

VWRAP's description of capabilities is at:

http://tools.ietf.org/html/draft-ietf-vwrap-foundation-00#section-2.3

VWRAP uses capabilities to access RESTful resources. Roy Fielding's

paper on REST is at:

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

abstract resource definitions vs. LLIDL

so i've been noodling on LLIDL and LLSD for a couple years now, and i think i've figured something out. i like the concept of an "abstract resource definition" a lot more than i like an "interface description language." (if you have no idea what i'm talking about, you may want to read my previous blog post "VWRAP Essentials : an abstract type system? hunh?." advanced students can take a look at the internet draft: draft-ieft-vwrap-type-system-00.)

the background

the objective of the abstract type system is simple and well defined: it provides system independent type semantics for structured data developed by protocol designers. that is, it defines types that are common to popular implementation languages. and it does it in a way that developers know the details of the types. like whether integers are 32 or 64 bits and whether radix 10 is supported in floats and so forth. the LLSD abstract type system describes how a small set of fundamental types work so implementers know how their "concretized" implementations should behave. and this is a good thing.

the problem

but after having mulled LLIDL around, i'm starting to see some issues with it. the main problem i have with it is that the interface is hopelessly entangled with the resource it describes. that is, you can't define an abstract resource without defining a method of access. for example, the current spec describes a way to say something like this:

 &info = {
name : string,
status_uri : uri
enroll_uri : uri
login_uri : uri
}

%% site_info << &info

in this example, the &info named type describes a structure that includes a string and three URIs. but the only context you can use the &info named type in is when you use a HTTP GET to access it. i think this is wrong.

it's wrong because it links the declaration of the structure of a resource with the transport used to access it. i have no problem with accessing resources over HTTP(S), but i do have a problem with ONLY accessing them over HTTP(S).

i think there's sufficient interest in the VWRAP working group to support the concept of making resource definition and access orthogonal. i would personally want to be able to have the option of using XMPP and (S)RTP when characteristics of those protocols are advantageous. but i don't want to have to create a new data definition language every time i want to go access a resource over a new transport.

furthermore, there are still open questions regarding content negotiation over HTTP(S). suzy deffeyes, john hurliman and i have reached a rough consensus on how to handle content negotiation, but we need to put it in an internet draft so other people can comment on it and implement it without having to refer to random email archives and IRC logs.

a proposed solution

i propose we layer an abstract resource definition on top of the abstract type system. the abstract resource definition can then be used to describe a transfer syntax (aka serialization scheme) for resources. we can then describe how each transport (HTTP(S), XMPP, etc.) carries serialized resource data. we can then describe interaction semantics independent of resource definition.

the benefit of this is it makes it easier to create systems that are transport-neutral. some of the lessons we learned from Second Life™ and the Linden Lab Legacy Protocol are that there's a LOT of stuff that's not "real time" data. I suspect that moving forward, we'll discover there are a lot of interactions that are modeled with the request-response pattern. i am proposing a solution that would offer deployers and protocol designers the ability to describe a resource without describing the method in which it is accessed.

more details

this proposal describes five components: the abstract type system, the abstract resource definition, the transfer syntax, the abstract interaction definition and the transfer mapping.

abstract type system

as mentioned above, the abstract type system defines a core set of types and type behavior. types are intended to be "concretized" in programming languages like C, Java, Python, whatever. we create an "abstract" type system so we're free to define the type behavior we want while not being tied to type behavior of a particular implementation language. individual implementers are responsible for ensuring that type semantics are consistent with the spec.

for example, imagine you were developing an application using an embedded 8 bit microprocessor and there was a protocol flow that involved incrementing an integer. a client might send you a 32 bit integer, assuming you would increment it. you would be responsible for modeling the behavior of a 32 bit integer despite the fact your micro-controller probably only natively knows about 16 bit ints.

abstract resource definition

the abstract resource definition is sort of like the abstract type system for collections. we define a resource as being either an individual item (a boolean, integer, etc.) or we define it as being a map or an array. the abstract resource definition system allows protocol developers to define the "shape" of resources. but because they are dynamic, implementations must allow for the type of a resource to differ from it's definition and for elements in map to be added and removed.

for example, you may want to define the following resource to describe an user logged into a system:

  RESOURCE agent {
 name string,
 identifier uri,
 current_location uri
}

the abstract resource definition is used to group named data elements together into a dynamic structure. these structures will later be used by the abstract interaction definition.

transfer syntax (aka serialization scheme)

these are basically the three serialization schemes defined in the type-system draft: XML, JSON and Binary. they define how structured data is serialized into an octet string in preparation for transmission across a network. for example, the resource defined above might be serialized like this:

  <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC
"+//IDN meadhbh.org//xxdsd 0.1//EN"
"http://home.meadhbh.org/xml/xxdsd/0.1/xxdsd.dtd">
<map>
<key>name</key>
<string>Meadhbh Oh</string>
<key>identifier</key>
<uri>http://world.secondlife.com/resident/6e7477a7-2de5-4660-bc83-4a47096a18f0</uri>
<key>current_location</key>
<uri>http://world.secondlife.com/place/65f385f0-691c-5755-9ef0-15f3bb05c8b7</uri>
</map>

abstract interaction definition

LLIDL currently defines access verb sets that are tied to HTTP verbs. if we want to be able to access resources using multiple transports, this is wrong. i propose we define an abstract interaction description "language" that is later mapped to a particular transport.

i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DELETE and EVENT. the first four should be pretty straight forward. They're used to create resources, read and write them and then maybe delete them. the last verb, EVENT, is used to define a resource an entity may receive without requesting it. things like object updates, incoming message session requests, etc.

transport mapping

the transport mapping maps abstract verbs from the abstract interaction description language to concretized protocol flows in the transport. so, for instance, you may use this to say that CREATE abstract access methods map to a POST verb in HTTP or that an EVENT message is delivered via the HTTP event queue.

conclusion

i'm going to wrap as much of this as i can into an internet draft and create some example code. but i figured i would get this idea out there so people can comment on it. just lemme know what you think...

new VWRAP internet drafts published

hey peeps! this is just a quick note to let you know that i just pushed out several new versions of the following VWRAP Internet Drafts:

VWRAP : Introduction and Goals

this is the draft that's intended to be a "gentle introduction" to our kind of virtual world, the protocol and the documents. (for a very short intro, you can review my earlier blog post, "what's the Virtual World Region Agent Protocol?") i believe it is "very close" to being fully baked. based on feedback from the mailing list and face to face meetings, i added a section on deployment patterns (without using the terms "Second Life" or "OpenSim",) removed the archaic concepts of agent and region domains, added a document roadmap and added a few terms in the glossary. also, i fixed up the references in the back so they *should* be pointing to the most recent revisions of things.

if you're new to VWRAP, you may want to read the VWRAP Working Group Charter, VWRAP for Virtual Worlds Interoperability [PDF] and notes on the history of the VWRAP Working Group.

VWRAP : Abstract Type System for the Transmission of Dynamic Structured Data

this one still needs a little bit of work and is essentially the same as the version published last february. however, we seemed to be hurtling towards consensus on this one.

if you're unfamiliar with why the working group is developing an abstract type system, you may want to peruse "VWRAP essentials : an abstract type system? hunh?" first.

VWRAP : Foundation

this is the old draft written by Mark Lentczner before leaving linden. it describes capabilities and the event queue. personally, i would like to rewrite this one. i would like to add a discussion on: event queue over web sockets, content negotiation and caching for accessing resources over HTTP, expiry of capabilities, etc.

VWRAP : Trust Model and User Authentication

i added references to the CALM draft, and removed the legacy bit about agent id's. it's now all account ids, which is what i think we all said we wanted. MD5 is still in the draft 'cause i wasn't completely sure we all agreed to remove it. i need to add some more verbiage about the "trust model," and possibly remove the MD5 references if that's what the working group wants to do.

VWRAP : Client Application Launch Message

this is the draft that describes how we send a message from a web site to the viewer to launch the viewer. it's intended to support web-based auth schemes like OpenID and OAuth. i added a little more verbiage regarding the use of a web capability as the location for an agent_login resource and tried to make sure the references were pointing to the right place.

so... i encourage everyone to take a look at these docs and let me know if you see anything wrong with them.

second life : there can be only one?

the foreground lights dim as the camera closes in on philip linden (portrayed by christopher lambert.) viewable only in silhouette now, we see an exhausted fighter, his sword already falling from his hands. the decapitated heads of vivaty, metaplace and forterra are still rolling as the bodies that once supported them fall in slow motion to the ground. lightning dances around the industrial setting, lighting philip's face for a moment. queen's "princes of the metaverse" plays in the background as the words of mitch kapor (played by sean connery) echo in the ears of our protagonist... "there can be only one."

or at least that's the image i sometimes get when i hear when about virtual worlds failing. a lot of people have been trying to extract cash from the virtual world, but it's a tough market. and a number of people have commented lately that in the post-hype world, second life™ may be hurting, but it's at the head of the pack and has the market for social virtual worlds more or less locked up.

but is that true? can there be only one?

just to clarify, i'm talking really about public, social virtual worlds. i'm not talking about virtual world platforms or small, departmental virtual meeting rooms. i'm talking about full-on massively multi-participant experiences.

OpenSim is an excellent project; as is SimianGrid. both are open source projects intended to replicate the functionality of linden's server software. the former seeks to maintain compatibility with linden's existing protocols while the later is more focused on next generation VWRAP protocols.

but neither are virtual worlds as much as they are open source software projects. they are both excellent projects, but they both explore the "solution space" of the virtual world domain and not the "problem domain."

no... what i'm talking about is public virtual worlds, with's lots of space for a bunch of people to hang out in world and do those things that virtual people do. this sort of knocks out Croquet / OpenCobalt (which is also mostly a "project") and (sadly) vastpark and teleplace. they're not bad concepts, they're just not massive.

if you look over at the OpenSim Grid List, you see that there are several grids out there, but the number of people visiting them is tiny. why is this? why is it that OSGrid, the largest of the OpenSim grids listed, is only attracting one 200th of SL user base?

my guess is it comes down to functionality, economy and community.

kvetching about features OpenSim lacks out of the box seems to be a popular sport these days. but it probably doesn't do much for the world to repeat some of the more extreme arguments. at the end of the day, some people like the second life permissions system and some people don't. some people like in-game currency, other people don't. but it seems that of the people willing to pay money for virtual space, most people either want those features (so they can do commerce) or don't really care if it's there or not. it seems that few customers are actively opposed to operating in a virtual world with cash and permissions.

without a turnkey system for starting a grid with cash transactions and a robust permissions system, the cost of implementing these features falls to the grid operator. without the virtual economy, it's a little harder to attract people to your virtual experience, and thus your community remains small.

so what can you do to grow OpenSim or Simian or OWL based virtual worlds into mega-monster avatar playgrounds? simple. stop trying to be second life™.

i think the answer to the question "can there be only one second life?" is yes; there really can only be one. but you can go on to have a lot of virtual experiences that are noticeably different from SL, and in many ways product differentiators. so let's not talk about things in terms of second life, and start thinking in terms of "next generation virtual worlds."

the obvious one that everyone is talking about is, "make second life run in a browser." there are enough people out there talking about Unity3D, WebGL and OnLive that a quick round of googling can find you a depth of opinion. (for extra fun, search for "+rezzable +unity3d +opensim".)

the next obvious one is, "make your virtual world more social." it's clear from linden lab's recent moves that they've heard this one. they interpret it to mean "follow the money, integrate with facebook."

another differentiator that is near and dear to my heart is "let info flow in and out of the virtual world." Linden Lab introduced an amazing new feature recently with it's media on a prim and shared browsing experience. but the truth is, putting a web page up in a virtual world isn't exactly new. heck, even sirikata did it. NanoCosm was doing it back in the late 90's. but that's the simplest way to get info into the virtual world.

how 'bout we let in-world groups map to facebook groups and twitter groups? why can't i easily see my facebook friends and twitter followers in world? for that matter, why can't i just log in using my twitter credentials. they _do_ support OAuth, after all.

and assets. Second Life's asset system requires you to upload images and what-not to their servers. why couldn't i just point to a texture or a COLLADA .dae file out on the web somewhere and say: "when i drag this item out of my inventory, i want you to go out to the web to get the data used to render it."

so i think my key point here is... don't try to recreate second life. it's been done. it attracted a fair number of people and a lot of hype. move on, do something better.

the next five years of SL : or, yet another rambling blog post about second life

so the recent tumult at linden lab got me thinking about the lab, second life™, virtual worlds in general, people's brains and business. and apple; i live in the bay area, so when the subject turns to "turn around stories" we start talking about apple.

yes, you know.. apple. the people who make the iPad, iPod, iPhone, iTouch and iEverythingElse. it's hard to believe, but there was a time when apple products were the domain of artists, students and assorted nut-cases like me who just wanted to be annoyingly different. before the iPod, apple's profits came from selling half-rate knock-offs of the Xerox Alto system software wrapped around well designed, but marginally manufactured hardware. (that is until they started selling half-rate knock-offs of the Xerox Alto system software wrapped around Avi Tevanian's master's thesis micro-kernel wrapped around well designed, but not completely marginally manufactured hardware.)

now don't get me wrong, i'm not a wintel bigot; nor am i an apple hater. i'm just telling it a little bit like it is to make a point. in the 1990's and early 2000's, you were a fool to waste time with macintosh products. they were temperamental, expensive closed boxes and using them set you off from the wider community of PC users and the bazillion programs you could run under windows.

as much as guy kawasaki likes talking about how the early mac team was trying to build something "insanely great," the mac operating system rested too much on it's laurels. throughout the late 1980's and 1990's, apple's steve-jobs-less leadership frittered away it's leadership position shuffling business units, preparing them to be the "next new thing." while the public was introduced to a stream of "interesting" products like the newton, powerCD, quicktake, cyberdog, opendoc, pippin and macintoshTV.

so by the mid-90's, apple's arch-nemesis to the north was nipping on their heels with Window95 and MS Office. the good news for apple was the decision to build user centered software with GUIs instead of crufty command sequences was vindicated. the bad news was that the courts allowed microsoft to rip off apple's look and feel.

and then steve jobs returned from the corporate hinterland, slashing projects, killing divisions and laying off staff. at the time, apple employees had a term for it, it was called "steve-ing." as in... "wow. they laid off the kitchen staff for mariani 1, i think imaging products division is going to get steved."

so jobs came back, turned apple around and today iPads are flying off the shelf and jobs hob-nobs with guys who can launch nuclear missiles at the google campus.

but what changed? why are apple products now cool? (yes, this is where we start talking about second life)

apple products are cool because apple products appeal to both a user's need for functionality AND the user's emotional closeness to the experience of using those products. apple products are cool. they delight. when you use them, they treat you like a movie star. they make you the center of their little device universe. they are cool and that coolness rubs off on you. so no matter how much of a dork you are, if you're using an iPhone, you feel like one of the cool kids.

can we say that about linden lab products now?

okay. loaded question. let me ask it another way. how does second life have to change to bring back that sense of emotional closeness?

waaaaaay back in 2005 and 2006, the hype cycle was in full swing. everyone was convinced that this was the wave of the future and we would soon all be virtually working in our virtual offices. so you couldn't teleport or you crashed every 15 minutes or the whole grid had to reboot every thursday. it wasn't a problem because you were experiencing "the future." and when you participated in the future, it made you cool.

but the future was a reasonably crappy place to work. prototyping real products in SL was annoying at best, and often impossible. you could have a virtual PC on top of your virtual desk in your virtual office, but it was just a prop. you couldn't use it to collaboratively edit documents with people in your virtual crib until very, very recently.

second life was a taste of the future; distance would soon be a thing of the past. we would have meaningful human interaction virtually.

but the promise of second life wasn't enough to keep the broader community of technology innovators "emotionally engaged." that a core group of enthusiasts drove the content creation economy with such primitive tools is testament to the creativity and ability of second life's residents.

for the broader community of content designers who wanted to use SL to build things that would interact with the outside world, or even live mostly in the reified world, the time to frustration was often much shorter than the time to delight. and when you have a tool that frustrates you more than it delights, it's hard to have emotional engagement.

and that's where we're at now... second life is a pretty cool niche with a comparatively small community of people using it to build engaging experiences. for the last several years the business guys at linden have been trying to figure out how to break out of that niche.

philip rosedale's return to the helm of linden has invigorated the community, and everyone seems to have a different opinion of how the world went wrong and a different narrative for restoring it to its former glory.

some view SL as a "platform." that is, linden's value lies in it software. either as a service (as it is now) or as a product (like SL/Enterprise), they say that untold riches await the lab if they could just figure out how to market it properly. to grow adoption, you simply reduce costs, develop new markets and watch the cash roll in.

others view SL as a "community." that is, it's value lies in it's community, waiting to be monetized with search and ad sales. make it easier for facebook and twitter users to convert into SL users and watch the cash roll in.

and some people point to steve jobs' success in converting apple from a maker of second-rate computers into a consumer electronics powerhouse and say the lab should adopt an "experience" strategy. "engage customers and give them an experience that is emotionally meaningful for them." perhaps that means enhancing the graphics capability or enhancing in-world music events.

but the truth is, none of these approaches will work by itself. linden and second life are at an inflection point, much like apple was in 1996 when steve jobs returned to re-orient the company. apple had it's strategic re-organization that involved layoffs and management changes.

but one thing to consider is it took steve jobs about five years from the time he returned to the time the iPod was released. so even if linden is pointing in the right direction, it could be years before we see the next big thing out of the lab.

VWRAP still seems to draw breath, despite linden's reduced participation

so a couple hours ago, josh bell (aka joshua linden) sent out an email indicating linden lab (makers of the Second Life™ virtual world) no longer has the capability to actively participate in (or lead) the VWRAP working group within the Internet Engineering Task Force (IETF).

from josh's email message:

Linden has reduced engineering resources tasked specifically with implementing the standards emerging through the VWRAP WG process. Linden will continue to be engaged on efforts that directly align with business goals and current development needs, and in fostering the ecosystem around Second Life ... For the near term, however, Linden will not be explicitly funding production of specifications or implementations related to virtual world interoperability. Linden Lab continues to be supportive of the standardization process and we hope to be able to be more actively involved at some point in the future.

josh goes on to say that he'll be continuing to serve as working group co-chair, but will participate as an individual, not as a linden employee.

I plan to volunteer my personal time to mediate discussions as co-chair of the working group, as long as there remains interest in tackling issues within the VWRAP WG charter. As individuals, many other Linden Lab employees are and continue to be involved in standardization efforts, around virtual worlds and other IETF efforts.

so... does this mean that VWRAP is dead? i think the answer would be "no, not dead, but it's definitely a metaphorical gut punch."

at the end of the day, corporations do not participate in IETF activities, individuals do. so linden's decision to pull resources from it's participation in VWRAP does not automatically shut the group down. but, it's no secret that linden sponsored many of the activities, instructing it's employees to participate in the standards development process on company time.

but it's hard to sugar coat this pill; the loss of a large commercial interest is going to cause a bit of confusion in the near term. individuals are likely to still participate, but without linden it's unclear who would be deploying VWRAP based services. at the end of the day, we can specify whatever we want; but if no one actually uses the specs, what's the point?

but all is not lost; the business motivations that led to the formation of the VWRAP working group are still there. there is still a market in virtual worlds for education, enterprise and entertainment. specifying protocols for virtual world services is still useful for driving down the costs of virtual world hosting and for supporting innovative ecosystems. in short, the fundamentals are still sound.

but there's now a bit of an "influence vacuum." the 800 lb. gorilla has quietly exited the tent, leaving a couple 300 lb. gorillas and a number of consultants. so, it will be interesting to see if any of the remaining players steps up to take a leading role.

our efforts in VWRAP are still useful, but the individuals involved in the standardization effort are no doubt interested in whose business requirements will drive the effort: IBM? Intel? Reaction Grid?

so... anyone interested in driving a low-mileage, late-model IETF working group?

Second Life : Hits and Misses

Word on the street is Linden Lab, makers of the Second Life™ virtual world, is in the process of laying off staff and shuttering remote offices. The few stories have surfaced over the last couple days are fueled by rumor and inductive reasoning. ( See Tateru Nino's story "Linden Lab Laying Off Staff, Closing Singapore Office" at massively.com for an example. ) Tateru's narrative is well told, but as of yet, Linden hasn't commented publicly regarding staff reductions. Reports of instability in the Linden Dollar exchange, the departure of key employees [*] and a failure to meet resident growth expectations have been feeding rumors of Second Life's demise.

But I'm not ready write off Second Life just quite yet. A lot of cool stuff came out of Linden Lab and even if the rumors of lay-offs are true, there will remain a nucleus of highly competent people delivering innovative new services.

So while we're waiting to hear an official word from Linden about staff changes, let's take a quick look at some of the Linden Lab hits and misses.

1. *HIT* User Generated Content (aka UGC)

Linden didn't invent the concept of "user generated content," but they were one of the first groups to really run with it. While universes like There.Com and ActiveWorlds also allowed UGC, Second Life allowed users to upload textures and build content in-world without prior editorial constraint.

We're in a world of "remix culture" where content innovation is fueled by the never ending stream of ubiquitous, culturally relevant media. In other words, we create meaning by reworking existing context in new and better contexts. Whether it's an artist that places a virtual Gandhi avatar in a virtual jail cell or simply a group of people gathering in world to discuss ideas, society as a whole benefits from the understanding and insight that comes from placing old media in a new context.

In the future, Second Life will be remembered as the first popular virtual world that understood this interplay between media and context and made it easy for participants to communicate "insight" by means of radical juxtaposition of common, socially relevant symbols.

2. *MISS* User Generated Content (aka UGC)

But it's not all goodness and light out there on the grid. There are serious issues with content theft and misappropriation of digital assets. Linden's process for dealing with IP theft follows guidelines established after passage of the Digital Millennium Copyright Act (DMCA.) While the Linden process appears in accord with US law, it does little (if anything) to prevent IP theft. Instead it provides a mechanism to repair damage already done; it requires IP owners to police the entire virtual world looking for infringers.

UGC is Second Life's "raison d'être." Without it, it would be an exceedingly bland experience. Some would argue that this virtual world is based on a system that ultimately discounts real world IPR by making infringement laughably easy.

3. *MISS* Pornography

The most obvious issue with the lack of prior editorial control on user generated content is the presence of pornography and obscene adult materials on Second Life's main grid. Expression of every carnal delight may be found in second life, ranging from "mildly unusual" to "outright obscene." Second Life is very clearly an "adults only" space; do not leave your children here unattended.

4. *HIT* Pornography

One person's obscenity is another's harmless fantasy. People are sexual creatures and stigmatizing physically pleasurable activities as being "dirty" or "obscene" does little to advance society and culture. Providing a space where individuals may come to terms with potentially embarrassing fantasies in an anonymous manner might actually have mental health benefits. Members of the transgender and fetish communities may experience very real emotional distress that prevents them from exploring taboo subjects in real life. The virtual world provides a safe, anonymous space to develop an understanding of the sexual self. This is in no way a bad thing.

The virtual world can also be a place where the disabled are able to explore their sexual persona. In the west, we sometimes force disabled people into a very non-sexual corner.; sex and disability can be a taboo subject in mainstream culture. For many disabled people, creating a sexually explicitly avatar in a virtual world can be liberating; especially as they have direct control over the degree to which their "real life" disability is expressed in the virtual world.

5. *HIT* Group Building

Most virtual experiences use assets created by a single person on a single desktop machine. Sure, digital assets can be created by groups of talented artists, and I'm guessing that most are. At the end of the day, there's only one person with one mouse altering one copy of the digital asset. Once the change is complete, the asset is saved in a file and distributed to other participants in the creative process.

Second Life's model is different. Building is an inherently social experience. Assets are created in the same virtual world participants inhabit. In fact, it's quite easy to find groups of people collaboratively building virtual things in one of the many "sandboxes" spread throughout SL's main grid.

The Second Life build system is the 3D equivalent of tools like Google Docs or Etherpad, when one person rotates a piece of an object being built, everyone with an avatar in the vicinity immediately sees the result. Everyone can immediately critique (or approve) the change.

6. *HIT* Digital Economy

To be sure, selling things in Second Life can be a pain. But over the last several years it's gotten increasingly less painful. In many online virtual worlds and MMORPGs, you can only buy content from the company running the experience. Turning the virtual world into a venue for individual-to-individual transactions is a true "hit."

Transactions totaling millions of US Dollars are executed annually. Real people are making real money selling bits; and that's a beautiful thing.

7. *MISS* Land and Object Backups

In an ideal (virtual) world, the content you create would stand as an eternal testament to your creative prowess. Sadly, we live in a real world where software bugs, database failures and system crashes conspire to delete the fruits of your online labor. In Second Life, you build on the live system. While there are backups occasionally, it is all to easy for your content to mysteriously disappear.

Products like Second Inventory allow individual content creators to explicitly save their creations. Linden Lab appears to have an "uneasy truce" with services like Second Inventory. You may find some Lindens privately acknowledge the utility of backing up content, but no one will go on the record publicly praising or damning the service. Second Inventory (and similar utilities in third party viewers) can too easily be corrupted into a tool that could allow unauthorized content copying. Supporting such a tool would not be a move welcomed by Second Life's content creation community.

So a content backup tool, which would be of great utility to content creators, could also be perverted into a weapon that could destroy the livelihood of that same community. Maybe someday there will be a tool that gives people the ability to backup and restore content they own, and only content they own. But until that facility is perfected this feature is probably going to remain too dangerous for general deployment.

8. *HIT* Spatial Voice Chat

A fair amount of attention has been paid to virtual worlds as venues for education and business events. Whether you're talking about using the virtual world to teach classes or meet with your business partners, the experience is still pretty compelling.

A lot of people ask, however, "how is Second Life different than a chat room or a WebEX presentation?" And you'll get a lot of different answers to this question. But I recently had the opportunity to watch new users learn a bit about the virtual world. These were people who were technically savvy, but not "Virtual Worlds People." I was a little surprised to discover that after they learned the interface, they found the experience "reasonably compelling." When asked why, their response was... "it was easy to figure out who was talking."

So... virtual meeting planners take note: real people like it when it's obvious who's avatar is speaking.

9. *MISS* Walled Garden

Second Life has aspects of other great online systems: it has the social networking of Facebook and Twitter; it has the ability to host content like Flickr; and it has the ability to host group conversations like IRC or Google Chat. But Second Life is not Facebook or Twitter or Flickr or Google Chat. It doesn't do any of these things nearly as well as these sites.

And maybe that's okay. Second Life is about creating immersive 3D experiences. It is not about image hosting or IRC chat sessions. The 3D experience creates an engaging social context that you just can't get from the 2D web. It's okay for Second Life to not be as good as Twitter or Facebook on the whole social networking thing.

But what isn't okay is that I can't link my Second Life identity with my Twitter identity or my LinkedIn identity. My FaceBook friends are not automatically my Second Life friends, and that's a problem. The "friction" involved in engaging my external accounts in the virtual world means it will never have the size and scope Linden's executives keep talking about.

Until Linden breaks down the garden walls and allows virtual land, assets and identities to be hosted by external organizations, Second Life will remain a pleasantly curious island in the sea of internet commerce and communication.

Conclusion

So there we have it, my short list of Second Life's "greatest hits and misses." What are yours?

* In the interest of full-disclosure, I should remind readers that I worked for Linden recently, though my role probably didn't qualify me as a "key" employee.