Subject: Re: [mmox] Owning one's data and non-authoritative caching

From: Morgaine <[email-masked]>
Date: Mon, 2 Mar 2009 01:49:52 +0000

It's worth noting that the ability to "own" one's data not only in the
copyright sense but also in the "hold authoritative copy" sense can and
should work not only in P2P world scenarios but also in centralized provider
ones, if the customer requires it.

It is perfectly viable to design "VW providers" that are big-iron but
non-authoritative persistent caches.  A small PC world could purchase the
muscle and scalability of the big-iron provider as a service to support
crowds of visitors to the cached world, which if handled on the small world
directly would cause PC meltdown and broadband congestion.  Yet, the PC
world could still be authoritative in this scenario, refreshing the
provider's persistent cache whenever anything in the authoritative PC world
changes.

This could even be retrofitted to existing worlds like SL.  There is no
particular reason why a given asset in LL's world database has to be
authoritative.  Once we have an interop protocol, clients could just as
easily hold authoritative copies of certain objects themselves, with
automatic upstream reflection.  This would be a very appropriate model for
object developers.

*Indeed, this is a very interesting use case for our protocol.*

(It also happens to be one of the proposals I made on the SL forums a few
years back.)

Morgaine.

On Thu, Feb 26, 2009 at 11:37 PM, Christian Scholz <[email-masked]> wrote:

> Jon Watte schrieb:
>
>> Christian Scholz wrote:
>>
>>> Jon Watte schrieb:
>>>
>>>  That's right! Incidentally, this matches almost exactly the "connected
>>>> server peers" model that I've been proposing.
>>>>
>>>> However, the objects themselves are owned by one of those N providers
>>>> (or else why is the provider supplying authoritative state for it?)
>>>>
>>>
>>> But I want to own my data :-)
>>>
>>
>> Sorry, I'm confusing the terminology here. The server "owns" the object in
>> the sense that it is the authoritative source of property values for that
>> object. I did not mean to imply any ownership in the IP sense, because that
>> discussion does not apply to the particular technical details we're talking
>> about; it's handled at a different layer.
>>
>
> Ok, we should define some terminology at some point anyway.
>
>  So there could even be simple hosting servers which are dumb regarding the
>>> whole VW thing and simply host objects without ever doing any simulation.
>>> And I can simply put those URLs into my users's service catalogue to be
>>> discovered by some simulator.
>>>
>>>
>> Unfortunately, simulators use different scripting languages, execution
>> environments, APIs and architectures. Thus, you may be able to have a dumb
>> server (like a web server), but it could only serve an object to, say, a
>> Second Life-compatible server, or a Metaverse-compatible server, unless the
>> behavior of the object was re-developed for each simulation platform.
>>
>
> Or it could provide different versions. Sort of like content negotiation.
>
>
> -- Christian
>
>
>
>
> --
> Christian Scholz
> Blog: http://mrtopf.de/blog
> Company: http://comlounge.net
> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de
>

---

From: Jesrad <[email-masked]>
Date: Mon, 2 Mar 2009 12:52:14 +0100

There is also another sense for "owning" data, and that's owning an
access to it. Caching data is not functionnally the same as having
access, since the former does not imply any processing of the data
like the latter.

>From the economics of creation and distribution of intellectual works
/ information, it's apparent the single requirement for this activity
is that individuals can trade their own accesses to information with
other individuals - that's the one thing necessary for having anything
from copyright-based commerce to open source to other alternative
businesses develop and maintain. Since a grid / VW is not a single
individual but connects many people, it needs a mechanism for
restricting access to information on an individual basis, and that
includes middle men in the transmission chain, from the authoritative
copy host to the end user. A choice of "either everyone or no one can
access it" is not acceptable in my opinion, and is probably illegal in
some jurisdictions (as in my country where the right to have your data
removed from any private database is permanent and non-transferable),
outside of all copyright considerations.

Fortunately, as above, the transmission, replication and storage
involve no processing to be done on the data, so only the endpoint
requires what I understand as "access to the data", while the rest of
the transmission chain is merely a vehicle (contrast with DRM cases,
where the endpoint is supposed to be restricted and have access both
at the same time). Since MMOX will be P2P, it might be good to see how
distributed filesystems or datastores do it. I remember that Freenet
encrypts the local caches of its nodes so that an host does not even
know what it is caching. Though in our case we'll certainly want that
cache servers can identify the data (= access the associated
metadata), that method looks good to me.

I think the authoritative characteristic of an host (= its superior
position relative to the rest of the transmission chain) may transfer
or extend down to other hosts, but such an "authority chain" has to
double up as a trust chain then: it's better implemented on a P2P
basis between existing VWs, and that's probably out of our scope at
the moment even if it makes sense to include it in the protocol as a
seperate domain.

To put it simply: there are compelling legal and economical reasons
for restricting transmissions of assets to only those transmissions
authorised by the authoritative host. To this effect I propose that in
MMOX the only caching of data, outside of specific cross-agreements of
trust between VWs, be encrypted in a way that prevents the cache
server from understanding what it is caching, as is done in existing
distributed data stores.

Please note this concerns just the MMOX endpoints between themselves,
any internal policy for data access inside a given VW is a seperate
matter both ethically and technically. Also, the mechanism for
filtering access to data can also filter the edition of that data -
being the able to edit your stuff from another grid is most probably a
valid use case for interoperability, as well as stopping others from
editing it.

On Mon, Mar 2, 2009 at 2:49 AM, Morgaine <[email-masked]> wrote:
> Indeed, this is a very interesting use case for our protocol.
>
>>> Sorry, I'm confusing the terminology here. The server "owns" the object
>>> in the sense that it is the authoritative source of property values for that
>>>> So there could even be simple hosting servers which are dumb regarding
>>>> the whole VW thing and simply host objects without ever doing any
>>>> simulation.
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 10:45:55 -0800

> server from understanding what it is caching, as is done in existing

I think that's one very valid model. In the proposal of a unifying IP 
model I made last week, I allowed for this as one model (and I allowed 
for originating hosts to verify that the policy would be enforced down 
the line through out-of-band means). However, there exists many use 
cases where that does not have to be enforced. If the content is 
creative commons or public domain, no enforcement is needed. If the 
interop is between two "known entities," then enforcement can be handled 
out of band.

Thus, I believe that we need a way to carry licensing metadata with all 
content (where license may include things like the "sticky bit" of 
copy-lefted content), and a way to allow connections to be validated as 
able to enforce (or not willing to enforce) certain types of licenses, 
and the originating system can then make a decision on what data to 
provide, and whether to provide it.

Sincerely,

jw

---

From: Jesrad <[email-masked]>
Date: Tue, 3 Mar 2009 13:53:45 +0100

> copy-lefted content), and a way to allow connections to be validated as able
> to enforce (or not willing to enforce) certain types of licenses

It seems to make more sense, if we're to integrate this sort of
mechanism in the protocol, to specify such "licensing" in terms not of
legalities, but directly of technicalities applicable to the data. For
example, a GPL-ized asset is checked as "can be cached with NULL
encryption" while a proprietary or other forms of licenses can
restrict the encodings.

We will know exactly what the protocol can do, but not what terms of
licensing people may want to use for themselves in their use of the
protocol, so it is best we limit this to what the protocol actually
does and provide a way for the endpoint to select from it. Trying to
provide all-reaching extensibility here is very premature IMO.

On Mon, Mar 2, 2009 at 7:45 PM, Jon Watte <[email-masked]> wrote:
> I think that's one very valid model. In the proposal of a unifying IP model
> I made last week, I allowed for this as one model (and I allowed for
> originating hosts to verify that the policy would be enforced down the line
> through out-of-band means). However, there exists many use cases where that
> does not have to be enforced. If the content is creative commons or public
> domain, no enforcement is needed. If the interop is between two "known
> entities," then enforcement can be handled out of band.
>
> copy-lefted content), and a way to allow connections to be validated as able
> to enforce (or not willing to enforce) certain types of licenses, and the
> originating system can then make a decision on what data to provide, and
> whether to provide it.
>
> Sincerely,
>
> jw
>
>
>

---

From: Morgaine <[email-masked]>
Date: Tue, 3 Mar 2009 13:08:02 +0000

Jesrad,

Those are excellent points you make.   In effect, once objects no longer
inhabit a single managed world but migrate out into the interoperating
metaverse, the mechanisms for access sharing need to retain their former
flexibility (or even broaden it), and not narrow it down to all-or-nothing
access for one single authoritative party.

This has important ramifications for any design based on the persistent
cache metaphor, since updates from multiple authoritative parties need to be
considered.

What's more, as you said there are trust chains involved, and in a
component-oriented VW in which objects are hierarchical, that further means
that authority and trust can potentially vary up and down the object
hierarchy.  The access permitted for one component may be quite different to
that for another.  An all-or-nothing approach at the inter-VW interop
gateway doesn't capture that semantic.

To use a car analogy, export and border controls can determine whether a
vehicle may enter a country, but they are insufficient to control who may
purchase it (it could be a tank), nor to control which parts a middleman can
customize or refit (paint, radio, tyres), nor to control what the end user
is permitted to do (refuel, add nodding dogs).  Consequently inter-VW trust
barriers are not a sufficient mechanism to ensure correct operation of
user-access controls for objects under interop:  they merely apply a weak
precondition that is additional to any per-object constraints.

We all know the purpose of per-object constraints, but the role of inter-VW
trust barriers is a new one, so we'll have to think about them a lot more to
make their purpose clear in the VW context.

That was a pretty good insight, thanks Jesrad. :-)

Morgaine.

On Mon, Mar 2, 2009 at 11:52 AM, Jesrad <[email-masked]> wrote:

> - Show quoted text -