August 1, 2008

Protocol, Software, Trust and Worlds

Posted in AWG, Musings, SecondLife at 9:56 pm by zhaewry

After reading some comments and hearing some questions in person I want to dive a little deeper into some of the topics I posted in my last entry. I think its important to be as clear as possible about: how specific parts of this technology works, how interoperability and software work, how implementations of software interact, and exactly why this can’t be simply solved by writing software. I want to explore some of the technical limits of software, and then how we can augment software with the legal and policy frameworks, to enable what I think are desirable properties in an emerging virtual worlds ecosystem.

Since I’m going to be talking about some legal issues and some policy issues, the usual disclaimers. I am not a Lawyer. I don’t represent Linden Lab.™ I’m discussing the technical issues and how they intersect policy. I do work for IBM but I am not speaking for IBM, or setting IBM policy. This discussion is reflection of my opinions on a work in progress. Most of these ideas have been discussed in Zero Linden’s office hours, or at AWGroupies meetings. Contents may have settled during shipping. Only the consumer should remove this tag.

Protocol, Software and Trust

There seems to be a some confusion about how interoperability could or could not protect content. Some of this seems anchored in a misconception that somehow its just a matter of writing software one way or the other and it will all be solved. The core of doing secure interoperability is understanding what can and cannot be done with software. There are unavoidable constraints when managing security and trust between independently controlled software components. The essence of which is we can never force another, independent component to be trustworthy via technical means. Given this constraint, we need to anchor inter component trust, not in pure software, but in a combination of legal and technical solutions.

Protocol, not software

The Architecture Working Group isn’t designing software, it is designing a suite of protocols. These protocols will be built into software. Hopefully lots of software. They will describe how software which wants to interoperate has to behave, in order for the desired interoperation to occur. It doesn’t dictate the interior of the software, but rather the points at which the software interacts with other software.

I am writing software which implements the protocols, as is Linden Lab, and the Python Open Grid Protocol ( PYGOP ) testing team, and people in the community. The protocol work is directly informed by what we learn from implementing the test cases, but the design happens at the protocol level.

This is not a casual point; this is the essence of the task. ANY software which follows the protocol should be capable of interoperation. The AWG is designing not one bit of software, or two or three, but a set of rules of engagement which tells software developers how they can write software which will work together. Note: Following a protocol permits interoperation, it does not enforce or require it. A service built on software which follows the protocol, should be able to work with other services following the protocol. They may or may not actually interoperate, based on whether they chose to accept requests from each other. The protocol says how they may work together, not that they must, or will accept requests from other services; that is a choice of the service providers. In fact, parts of the protocol are about managing those choices.

Trusting other software

A basic assumption of distributed computing is that there are concrete mathematical limits to how much you can trust remote software. From the outside you can’t tell what software is doing inside itself, nor can you force behavior on it. Understanding this limit and managing it is a key task of building a large distributed system. Take for example, the desire to have a simple handshake which says “This bit of code enforces Linden Lab style protection bits.” On its own, that handshake is meaningless. Why? because anyone can code the handshake and we have no mechanism for knowing if the code actually does that. We can code a complete permissions management system and contribute it to OpenSim, and someone can change a few lines of code, recompile the software and run an OpenSim that claims to match that spec, but doesn’t.

Fortunately while we can’t trust other systems to implement what we want them to, there are some nice approaches which permit us to verify the identity of a remote system. We can use these techniques to know *who* is making requests. Better still, we can use such tools to issue partners ways of proving they are who they claim to be. Just as we have formalisms which show us why we can’t trust software to do what it says it does, we have a set of formalisms, which allow software to prove to us within careful limits, it is being run by a trusted partner. For those interested in the topic, a look at public key cryptography as well as digital signatures would be worthwhile. Including a digital signature in the handshake, gives us a basis for trusting that the remote software is being run by the party it claims to be run by.


So.. if we can’t ensure by technical means that a server we want to talk will honor our desires, how can we trust it? In the end, I suspect, we will fall back to the very simple mechanism of having a legal contract which specifies the rules of engagement for both parties. A terms of service, as it were, for a service provider to access another service provider’s resources.

One such pattern might require a legal contract that both parties would honor DMCA takedown requests, an augmented Linden permissions system, and use the Lindex as a common currency. Another pattern might be a simple agreement to only share publicly released content. Another might be a formal “wild west” pattern which says, effectively, “This service doesn’t enforce any rules.” As a protocol, we want to enable a broad range of possible policies and allow the greater community to explore which policies prove attractive and useful and which prove less desirable.

Blending technical and legal techniques

Now lets look at how we could blend together the technical with the legal. The technical is the set of protocols which allow grids to use public keys to establish, provably, they are who they are. The technical is also being able to mark which policies they care to share. This can be as simple as using null keys and policies and allowing non-secure operation. This could be as complex as having a legal contract defining what policies they want to follow.

Key exchanges and the associated policies would provide a mechanism to tie the technical trust to the legal framework for each service to trust the other as much or as little as they chose. As we are looking to enable a broad range of possible connections between services, the protocols need to admit a range of possible relationships. I expect we will see a small set of common ones and a much larger set of less common ones. The goal, in many ways, will be to enable exploration of a rich set of possible connections. In general, permitting a range of possible solutions and letting real world experience show us which ones prove valuable feels right to me.

To recap. In this model trust is anchored in real world legal agreements. Based on those agreements parties can issue each other digital keys which allow proof that they are who they say they are and that they are legally obligated by the contracts associated with the issuance of those keys. Those who don’t feel the need for such comprehensive measures can publish keys which permit access at a less trusted level. A whole range of possible relationships is the goal, not one single relationship.

Related concepts and issues

I want to run through some related concepts which came up in reading people’s comments, and listening to various people’s concerns and questions.

Permissions, and Copyright

Some people in the Second Life community seem to believe that the current system of “Copy/No Copy, Mod/No Mod, Transfer/No Transfer” within the current Second Life implementation forms a digital rights scheme, or a way to manage copyright and licensing. This seems very odd to me. Nothing in the scheme speaks to license, copyright or use. Linden Lab’s uses the permissions bits as exactly that. They form a set of permissions that the software follows. While I’m not a lawyer, as I see it, permissions aren’t a license and don’t convey copyright. I can’t see how a content creator would either surrender rights, nor protect them because of the permission bits they set inside second life. The license grant, which covers use of material in Second Life, would seem to be pretty firmly in the Terms of Service, not in the permissions bits. I highly encourage anyone reading this entry who wants to understand where the copyright grant to use content happens at the moment, to read the TOS.

Virtual worlds, and web content

A parallel is often raised to content in the web. This roughly is asserted as, “why can’t I simply apply the same range of choices to protect my content in a virtual world, as I can in the web.” The rough answer, is. well, you could use any scheme you wanted to encode textures, but only people sharing the scheme would be able to see the textures. If you wanted to go deeper into content encoding, note that you would need a common scheme which was also supported by the region simulators, as without being able to decode the scheme, you couldn’t actually manage the physical simulation which is at the heart of a virtual world. Unlike a web page, the contents of a region are managed as much by the server as a client. When you want your prim boots to be seen by all the other avatars in your virtual space, you need to share the description of those boots with the server and the other clients. When you want your prim tree to be part of the landscape, you need to actually hand it’s description to the region simulator to manage.

Deep Digital Rights Management (DRM)

Digital Rights Management covers a lot of space. When I say, that deep DRM isn’t in scope for what we’re doing with the AWG, i specifically mean the form of DRM where you have a provably sealed cryptographically managed path from the content source to the end of the consumption chain. This is the sort of thing which attempts to prevent a DVD from being copied on your computer, or you making copies of your music downloads. When you dig through all the technical details, this sort of DRM turns into an exercise in trying to give you a copy of the digital content that isn’t a copy of the digital content. That is the essence of the problem. “Here, consumer, you can have this song, so you can play it, but you can’t have this song so you can copy it.” In order to make this happen, you end up with very draconian software which controls every aspect of the process of using the music. This works in some settings. Apple manages, in the context of very good, very closed hardware, and even in the itunes space, there are programs available for cracking the copy protected music, and the option of burning and re-ripping disks. For a world of user created content, the bar is higher, as you need to provide users with a way to upload and put content under a secure key, which opens up series of “known plaintext” attacks.

Adam Frisby has some useful comments in his blog here. The core issue is that, deep, cryptographic DRM of the digital assets being used in a virtual world trips over the need to let all clients in the world see that content. This is nothing new and has been discussed at length. Doing a deep DRM solution would require a closed client, a closed operating system, secured device drivers, and indeed proprietary hardware. Computers are, by their nature general purpose computing devices. Forcing them to behave as non general devices is hard, and most such schemes end up cracked. You can raise the difficulty in cracking such schemes, generally in direct cost of special purpose hardware, and end user complexity.

Policy, Software, services and the creation of virtual spaces

One last point, for a long, and complex set of topics. It is important to keep in mind that there are many layers and parts involved in this space. At the bottom, there is software, which creates a set of services, those services can be composed to simulate a space. Deploying these services, in various ways, allows people to create virtual space, with content, avatars, and interactions between them. Second Life today, consists of one set of services and spaces arranged to produce one style of virtual world.

OpenSim is a platform which allows the creation of services which can be arranged to be very similar to Second Life. It is, however, a software platform, not a virtual world. A reasonable analogy would be the difference between one of those Lego kits which comes with a pile of normal lego blocks and some special blocks, and a pretty picture of the cool car you can make.

OpenSim, is a collection of lego blocks. Some are very general purpose, some are quite specilaized. Out of the box, you can trivially build a standalone server which hosts a small number of regions. With slightly more effort you can hook up your region to one of several existing grids, and with increasingly large amounts of added effort, build grids, run shared asset servers, and provide more and more features which approach a complete virtual world.

Plenty of people have created isolated virtual spaces using OpenSim. Some have built grids, such as OSGrid, CentralGrid, and many others, listed here.

The actual creation of the specific services, the composition of those services into virtual spaces, and the management and policies of such a virtual space, is not set by OpenSim, but rather the people building these spaces and grids using the OpenSim platform. Some of these virtual spaces will form full up virtual worlds of their own. Others, will be used for very specific and narrow purposes, private pocket worlds, for the use of their creators. People will modify the code, extend it, add and delete features, and create variations as they build their grids and spaces.

Interoperation, is at its core, about creating an ecosystem, in which a great many people will innovate. OpenSim, as a platform, enable people to explore different ways of creating and managing virtual space. Many of the virtual spaces people build on top of OpenSim will probably end up interoperating. Some will do so in very broad ways, creating large grids with broad swaths of virtual land. Others will do so in very small ways, allowing a select group of regions to work together. Some parts of the ecosystem will thrive, others will die off. Successful innovations will be picked up and shared, while others will fail to thrive. How parts of this ecosystem connect up, and how broadly and deeply regions share users, data and policies will be determined, by the people who host the services, the people who use the services, and the choices they make. My goal for interoperation, is to make the set of possible choices as broad as possible, so that we can see as wide a set of ecosystems emerge.



  1. […] Protocol, Software, Trust and Worlds « Zha’s Virtual Musings Blogged with the Flock Browser Filed under: Uncategorized   |   […]

  2. Alex said,

    Hi, Zha,
    Some of the language you used is… mmm… incorrect 🙂 or at least inaccurate.
    “We can use these techniques to know *who* is making requests.” – no, you can not.:) You can only know that SOME mmm… let’s call it ‘party’ POSESSES THE PRIVATE KEY AT THE MOMENT OF THE REQUEST !!! Which (the private key) could have been stolen, resold several times and then used from one of the hacked computers in a bot-net, I hope you’ve heard about them, also the IP addresses would be just spoofed or a hacked router and proxy server would be used… WHO is making requests would be quite a mystery, believe me. 🙂
    That’s how it happens in Real Life, I’m not sure wikipedia describes thoroughly enough these aspects of Real Life and Internet. 🙂

    “Better still, we can use such tools to issue partners ways of proving they are who they claim to be. ” – I presume you mean a PKI (Publick Key Infrastructure) solution. They DO NOT exist right now for a strong enough public key cryptography I’m not even talking about those for worldwide use. I think you’ve heard why: 1. Export restrictions 2. Absence of legal framework for DIGITAL signatures and use of cryptography in B2B interactions (not to be mixed with ‘electronic’ signatures). It also has something to do with the example I gave you before. Why bother when the Internet itself allows so many ways to hack and forge everything (servers ‘behind the firewalls too’)? Why bother when operating systems are provided to users on ‘AS IS’ basis (have you ever read all these ‘disclaimers’ stating that the MS company and others don’t guarantee ANYTHING?).

    ” In this model trust is anchored in real world legal agreements. Based on those agreements parties can issue each other digital keys which allow proof that they are who they say they are and that they are legally obligated by the contracts associated with the issuance of those keys.” – if you are talking about the public key cryptography this is incorrect. Parties don’t ‘issue’ keys to each other, they generate key pairs ON THEIR COMPUTERS and send the Public key openly through the open channel of communications to another party. What you are saying is about PRIVATE key cryptography. Also, you are talking about ‘legal agreements’ as if they exist and are widely used… I have to tell you that THEY DON’T EXIST in the present legal system. The legal framework for a B2B agreement like this HAS NOT BEEN DEVELOPED yet (in the US in particular).

    The last one:
    “For a world of user created content, the bar is higher, as you need to provide users with a way to upload and put content under a secure key, which opens up series of “known plaintext” attacks.” – no, you don’t. The content would be encrypted on the PUBLIC key of the service if you use the Public Key Cryptography, no private keys of the service would be necessary.

    I completely agree with you on ‘permissions’ – it’s just a phony-baloney which has nothing to do with ANY legal arrangement. These setting DO NOT affect or amend the TOS which governs ALL relationships in regard of the content.


    P.S. I disagree that other worlds will use Linden $ as a currency. I can even explain why it will NEVER happen.

  3. Prokofy Neva said,

    Well, this supposedly “phony-baloney” has sustained the Second Life economy and copyright regime for 5 years, and made it something even attractive for IBM and their copyleftist friends at OpenSim to want to even crack open and reverse engineer in the name of “open standards”.

    Laws are meaningless in the abstract; naturally laws have embodiment and concrete implementation that give them effect. There is nothing intrinsically wrong with this. Crude or imperfect DRM in the c/m/t regime in SL doesn’t make it cease to be a DRM, and one that in fact has worked.

    I’ve rebutted the rest of Zha’s post here:

    Never say never. The Lindens never planned their currency or economy, either, and would have told you in horror that it was against their hippie sharing ideals of Burning Man. But nNormal people came and made it without them, at GOM, because normal people always walk around abstractions and do things that are practical. When the Lindens saw how successful it was, they GOM’d the GOM to get a piece of it. This will replicate with each new world and hook-up.

  4. cold calling said,

    Hello to all, it’s truly a good for me to visit this web site, it consists of useful Information.

  5. Helen said,

    Hello just wanted to give you a quick heads up. The text
    in your post seem to be running off the screen
    in Firefox. I’m not sure if this is a formatting issue or something to do with web browser compatibility but I thought I’d post
    to let you know. The design look great though! Hope you get the issue fixed
    soon. Many thanks

  6. Hey! This is kind of off topic but I need some help from an established blog.
    Is it very hard to set up your own blog? I’m not very techincal but I can figure things out pretty fast. I’m thinking about setting up my own but I’m not sure where to begin. Do you have any points or suggestions? Many thanks

  7. Anthony said,

    Its not my first time to pay a visit this web site, i am
    visiting this web site dailly and obtain pleasant facts from here all the time.

  8. Wow, fantastic blog layout! How long have you been blogging for?
    you made blogging look easy. The overall look of your website is
    great, let alone the content!

  9. I have read so many articles or reviews on the topic of the blogger lovers
    except this post is actually a good article, keep it up.

  10. Pants meant for using are made in aparticular fashion that lets the rider

  11. YourNSFWPorn said,

    I think everything said was actually very logical. But,
    what about this? suppose you composed a catchier post title?
    I ain’t suggesting your information is not good, however what if
    you added a post title that grabbed people’s attention? I mean Protocol, Software, Trust and Worlds |
    Zha’s Virtual Musings is kinda boring. You ought to peek at Yahoo’s home page and watch how they write post titles to grab viewers to open the links.
    You might add a related video or a pic or two to get readers interested
    about everything’ve got to say. In my opinion, it would make your posts
    a little livelier.

  12. There is certainly a lot to find out about this subject.
    I really like all of the points you’ve made.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: