Re: [ogpx] The Role of Policy and Processing Expectations inProtocol Development

[Morgaine <[e-mail]>]

On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <[e-mail]>wrote;wrote:

morgaine. redefining terms does not make fundamental issues go away.

I couldn't have put it better myself.  And this is why the redefinition of
cross-world interop as taking place in the "same virtual world" will not
make the issues of cross-world interop go away.  We have to face those
issues anyway.  Adding that language achieved nothing and just obscured the
intent.  Clear intent is important.

These problems aren't rocket science, but they do require concentrating on
the actual technical details surrounding asset flow between worlds rather
than handwaving them away with weak, non-technical, non-scalable, and
non-enforceable policy agreements *that are not actual entities in the
protocol*.

The sooner we start addressing the cross-world details at the protocol
level, the closer we will be to an OGP that can actually provide cross-world
interop.  Every mention of trust agreements just waves a magic wand at this
instead of addressing it.

Certificate technology is a given.  It's great for identifying endpoints and
securing sessions, but that's all it does.  It doesn't add magic, and it
doesn't address cross-world interop at all except at the trivial
"no-interop" point.  All the hard work still remains to be done.

A stronger focus on actual networking protocol elements and less
redefinition of non-protocol elements would get us a long way.

Morgaine.







================================

On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <[e-mail]>wrote;wrote:

> morgaine. redefining terms does not make fundamental issues go away.
>
> the simple fact of the matter is, many of us are interested in
> implementing virtual spaces that may be comprised of systems with
> multiple owners. some virtual land owners / administrators might not
> like some avatars. some users / agent domains may not like some
> regions or region domains. whether we define them as all being in the
> same "virtual world" or distinct virtual worlds, it doesn't matter,
> deployers still need to manage that policy, implementers need to
> persist information about policy between protocol interactions and
> protocol developers need to identify where policy should be applied.
>
> -meadhbh / infinity
>
> On Sat, Aug 22, 2009 at 4:27 PM, Morgaine<[e-mail]>
> wrote:
> > Separation of policy and mechanism is motherhood and apple pie to us
> here.
> > The problem lies in achieving it, and avoiding any one party imposing
> their
> > own policy by shackling the mechanism and denying it the ability to
> > implement other policies.
> >
> > Here's an example of it happening as an artifact of design:
> >
> > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[e-mail]
> >
> > wrote:
> >
> > 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.
> >
> > That's a problem of your own making.  Carlo and I and every open grid
> > operator understands that all these grids are independent virtual worlds
> > that have separate policies.  Yet you choose to invent a new meaning for
> > "virtual world" in which all communicating parties create a "same virtual
> > world", and then you wonder why you have a problem of varying policies
> > within your fictitious "same virtual world".
> >
> > That's the hub of the matter.  It's not the same virtual world.  It's two
> > separate virtual worlds with naturally separate policies that are seeking
> to
> > interoperate.  You've created the problem yourself by defining them to be
> > the "same virtual world".
> >
> > The "same virtual world" terminology in the current OGP documents is
> > actually bleeding policy into mechanism, the exact opposite of the
> > separation we desire.
> >
> > It expects uniformity of policies across participating worlds using trust
> > relationships as tokens of policy conformity.  That's neither feasible on
> > principle (because the grids have distinct policies by design), nor is it
> > feasible technically, because it doesn't scale to Internet sizes in a
> highly
> > diverse and multi-jurisdictional physical world.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> >
> > ================================
> >
> > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[e-mail]
> >
> > wrote:
> >>
> >> 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
> >> _______________________________________________
> >> ogpx mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>