Re: [ogpx] Limits to interoperability of scripted objects

[Joshua Bell <[e-mail]>]

On Mon, Nov 9, 2009 at 8:32 PM, Lawson English <[e-mail]> wrote:

> Morgaine has seen me hype this many types, but perhaps Joshua and others
> have not not:
>
> http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion ...
>
>
Nifty stuff. What do you think needs to be exposed at a protocol level to
enable these scenarios, and do you think that fits into any of the currently
sketched out drafts or forms a part of an as-yet unidentified draft? It
sounds like much of it is captured by the use case: clients are able to
manipulate simulation state for avatars and other objects.

  At the other end is the Croquet/Cobalt case where clients act as servers
> for their own private worlds that are, in principle, P2P in nature. While
> the VWRAP scenario assumes more Second Life-ish scenarios, there's plenty of
> room for more Croquet-like situations,  IMHO.


No disagreement. It's also interesting to think about stretching the VWRAP
model towards P2P scenarios. The model dictates that there is an
authoritative service for a region, but it's conceivable that if I invite
you to my space, I have a single application on my personal host that is
providing both the agent services and region services, and negotiates with
your personal host's agent service.


> There's no reason to assume ANY limitations save those required for
> security/trust issues, and those will need to be applied on the server side
> for any realistically secure scenario (assuming that the client-side
> plug-ins are trustworthy for the end-user's purposes, of course)
>

...which points out there are at least two scenarios for client-side dynamic
code: stuff that runs with effectively full trust of the user (basically has
unfettered access to agent and region services on the user's behalf) and
stuff that must be sandboxed. The former category would include the client
application itself as well as "Greasemonkey"-style extensions. The latter
would include content from arbitrary objects, much like JavaScript within a
web page running within the browser security context. Intriguing... it seems
like the Same Origin Policy from the web could apply directly to any set of
VWRAP services as well, although if the logic is coming from user-generated
content rather than the region authority itself, this runs into the same
exciting world that Google and others face with advertisement-hosted scripts
which need to be further sandboxed so that ads can't monkey with your
account, despite being served from the same domain.