[ogpx] The Role of Policy and Processing Expectations in Protocol Development

[Infinity Linden <[e-mail]>]

So I too recently wrote a long, rambling narrative in response to
Carlo's recent message where I tried to concisely explain how we got
to where we are in the definition of terms like "virtual world" and
"region domain." But it was pretty long and rambling and took a long
time to come to the point. I figured I would just come right out and
get to the point.

We want to separate mechanism from policy in OGP.

A bunch of us have been saying it a lot, but I figured it might be a
good idea to clearly explain what I think that means. When I say
"mechanism," I mean things like protocol message formats and
processing expectations; things like, "if you want to login to such
and such a virtual world, you send this message with these fields to
some server out on the network. if the server wants to let you on, it
will send you this message. if it doesn't, it will send you that
message."

Here's an auth protocol exchange example from HTTP:

client: hey! server! gimme the resource at
http://example.org/make/me/a/sandwich.xml
server: no can do, client. that resource is protected. fear my 401!
client: what if i give you my super secret password that i swear i
didn't sniff from another session!?
server: okay. in that case, sure... 200!

Policy, on the other hand, describes the decision making process
protocol participants go through to decide which response to give you.
Returning to the example above, when the server gets an auth request,
it might have the policy of "I will only let people in who give me a
valid avatar or account name and password." Yes! that's policy. It's a
valid idea to let people into a virtual world without a username and
password; web sites do it all the time. For many applications of
virtual worlds, it's a very bad idea, but it's the height of conceit
for me, as a protocol developer, to claim to know the mind of every
virtual world deployer throughout the world.

But, experience tells me that very bad things can happen in some
communities when you add anonymity and an audience. But hey, that's
_your_ call. It could be that your virtual world is only accessible by
two people in the office, so you always have a good idea who the other
"anonymous" participant is. Or maybe you work for an old skool company
where people would never think to be jerks to their fellow employees
in their "behind the firewall" virtual world. The point is... this
decision is up to you, the deployer.

Other examples of policy (again on auth) might include things like:
  * i don't trust MD5, so i'll only accept logins that use SHA1 in some way, or
  * i'll only let you online if i think you've agreed to my "terms of
service" document, or
  * i think i don't want anyone to login between 10PM and 7:30AM
because i'm a BOFH and i need my rest.

There's another term you hear from time to time: "processing
expectations." This is a term I heard first in the SGML / document
processing community. I've seen people attempt to give a formal
definition of this term. My informal definition is... "I know I can't
force you to do this, but everyone sort of expects this is what you're
going to do with the data i give you and it would be really nice if
you would play along, but if you really, really, really need to do
something else with the data, that's cool. KTHXBAI."

An example of a processing expectation might be: "when the server
receives a message with a SHA1 hashed password, it will compare the
hashed password provided with the hashed password stored in the
database." As a client there's absolutely no way I can force the
server to actually do this, but assuming servers do want to maintain
the confidentiality of their users' data, they probably will.

Processing Expectations and Policies are protocol developers' ways of
saying, "krikey! i have no idea what the deployer will want to do
here." or "if the other side wanted to be evil, they could be. look
here! we're trusting them to 'do the right thing.'"

So why do we care?

In the virtual world, one of the things we're really big on is
consistency of presentation. It's considered "a good idea" for you to
see largely the same thing the avatar next to you is seeing.
Otherwise, the utility of the virtual world is diminished.

Some virtual worlds allow user developed content and allow the content
creator to place copy restrictions on that content. (we're not naming
names here, *cough*Second Life*cough*)  Operators of these virtual
worlds have a strong belief it is in their best interest to maintain
those copy restrictions. So... they have a POLICY that says, "when the
client sends me the message to copy a digital asset and put it in
their virtual pocket, i'm going to check if the creator of that asset
says that's okay." The protocol message from the client says "give me
a copy, please" and the server has to decide whether this is a good
idea. If the server thinks it's a good idea, it will do it. If not, it
won't.

Other virtual worlds may be pre-stocked with assets and may not allow
users to create new ones. (i'm thinking this is what sametime 3d does,
but i may be wrong.) Still other virtual worlds may be bastions of
free culture coolness and mark everything with a creative commons
license that allows copying, but leaves it up to the participants to
ensure they're not violating the terms of the license.

I think we have general agreement that people who deploy OGP based
virtual worlds should be free to implement whatever policy they want
to implement. The problem comes when we start talking about allowing
avatars to move between region domains in the same virtual world that
MAY have different policies. Linden Lab, the makers of Second Life,
would want some seriously strong assurances from other region domains
that they promise to honor the permissions metadata attached to a
digital asset. Our hypothetical free culture region domain operators
might want assurances that other region domains will not let assets
with a no commercial use CC license  be used to create things that are
sold.

How will we ever resolve this problem? One way people have tried to
resolve it in the past is by sitting down and writing up legal
agreements. That's because it's a POLICY issue. It's very, very hard
for a server to guarantee by technical means that a client is using
content only in a way the content's rights-holder allows. So we punt,
and just say something like.. "if you sign a contract and let me sue
you if you don't honor my policies, i'll let you interact with my
systems."

As protocol developers all we have to do now is figure a way to tag
content and interfaces with sufficient meta-data that systems in peer
domains have a good chance of making an informed decision when the
client asks to do something that might violate the license. Or, you
might just deny access to service interfaces to people you don't think
you can trust. But again, it's a POLICY decision. As protocol
developers, our responsibility is to specify meta-data sufficient for
making informed decisions and for defining processes for identifying
trusted peers in the networks.

And.. I'm not making an exhaustive list of "policy issues," merely
asserting that there are a reasonably small number of them, and that
we can identify them using a consensus process. By defining these
decisions as "policy issues," it allows us to develop protocol
mechanisms that are appropriate for all supported use cases. Thus we
can all collaborate on producing a specification that works for all of
us, but allows each of us to address our specific needs.

I know Prokofy Neva has made statements disagreeing with this approach
in the past, and that she would prefer a virtual worlds protocol that
mandates all virtual worlds adopt second life's C/M/T permissions
model. I believe her justification is that it's too easy for a
misunderstanding or misconfiguration to lead to content leakage.

My counter argument to this is that by developing the protocol in
public, we get more eyeballs looking at the problem domain and we get
more edge cases considered. Because there's a higher probability that
problematic edge cases will be identified earlier, we'll get a more
robust protocol.

Is there anyone on the list that takes serious issue with anything
i've said here?

-cheers
-meadhbh