Note that asset security is not an old issue.  It was one of the key
counter-arguments to OSMP, which was (is?) an attempt to create an
opensource SecondLife.  See relevant thread:

http://manageddreams.com/osmpbb/viewtopic.php?t=241

"From browsing the SL forums recently, it seems that a big issue that
surfaces when one discusses OpenSource metaverse projects (little o, little
p), is: IP Protection."  This was written April 14 2005.

Proposals to mitigate the issue are on the OSMP wiki:

http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security

My personal favorite solution, which is compatible with libsecondlife, is
server-based enforcement:

"In an online game, it's not enough to own the most l33t armor: you need
others to be able to see that you are wearing the most l33t armor.

Actually, we don't need necessarily to prevent people obtaining a copy of
objects and prims: but it could be enough to block them from the servers.

The way this works is that you register your newest creations centrally. The
sim server then checks objects regularly - or on demand - for similarity
with your registered creations.

Any object found to be too similar to your registered creation is wiped /
quarantined / signalled to an administrator / or similar.

When you "sell" an object to someone, you dont just transfer the physical
attributes of the object to the purchaser, but also the moral rights to use
and own that object. They purchase a licence, and the licence agreements are
stored centrally."
Here is the complete list:
Possible Intellectual Property Solutions

Some possibilities to enforce IP within OSMP are:

  - watermarking, or similar, of textures etc, prior to sending them to
  client
  - random modification/deterioration of textures, prims etc by server
  prior to send to client
  - Centralized IP repository and DMCA
  - Secure client and server
  - IP enforcement
  - Server-based IP enforcement

[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=6>
]
Watermarking of textures and so on prior to sending them to client

Watermarking means changing the least significant bits in the data of a
texture, so that you store a hidden image, readable using special software.

Advantages:

  - no assumption that client is secure
  - doesnt deteriorate the texture significantly visually

Disadvantages:

  - specific to items with a lot of data, such as textures
  - can be removed by compressing/decompressing the texture

[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=7>
]
Random modification/deterioration of textures, prims and so on by server
prior to sending to client

The attributes of a prim sent to the client wouldnt be quite those stored on
the server, but randomly modified slightly. This means that a copy of that
object would have different prim properties stored on the server than the
original, which could easily be detected.

It would also mean that a copy of a copy of a copy would be substantially
deteriorated compared to the original.

Of course, it would mean that the object that people see wouldnt be quite as
good as the original.

Advantages:

  - no assumption that client is secure
  - can be used with any data type, including prims and objects

Disadvantages:

  - what the client sees is deteriorated wrt the original object
  - possible to "fix" the deterioration manually; not perfect
  enforcement

[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=8>
]
Centralized IP Repository and DMCA

A central server can be used to register an object, texture and so on.

If there is a dispute over IP, one can check with that central server who
created the item first (who registered it first).

After that, DMCA or similar can be used to enforce the copyright legally.

Advantages:

  - no assumption that client is secure
  - technically simple

Disadvantages:

  - Need to be prepared to take someone to court to enforce your IP
  rights
  - Need to find a trusted server (or make one, and pursuade people to
  trust it)

[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=9>
]
Secure client and server

We've already agreed that the SecondLife client is probably not actually
technically secure, but it is legally secure. That is, whilst anyone who
does a little research could hack into it technically - and even distribute
an executable to allow others to do the same easily - both of these actions
would certainly be against ToS, and maybe that would make them illegal too,
since the ToS is generally considered a legal document (see Appendix A)

So, how did the SecondLife client become legally secure, and an OpenSource
client is not?

Well, because anyone can install the OSMP client simply by accepting the GPL
agreement, there is no ToS beyond that.

It may not be enough to simply distribute OSMP with a stronger ToS.

However, what we can do is to keep OSMP as OpenSource, GPL etc, and then
publish a secure client and server.

The secure client and server is identical to the opensource version, except
that we have incorporated a random crypto key, used to authenticate the
client to server, and possibly to encrypt network traffic (maybe not
necessary).

Then, to connect to the secure server, you must use the secure client, and
the secure client is only distributed with a click-through Eula forbidding
things like hacking the network stream, memory scanning, hacking the cache,
and reverse engineering.

Advantages:

  - It's basically how SL's security works, so tried and tested
  - Independent of data-type, eg works for textures, prims, objects, and
  so on.
  - Fairly easy to do

Disadvantages:

  - Not technically secure, only legally secure
  - Need to have the will and the means to enforce the ToS
  - Need to trust the person/organization who creates the secure
  client/server

Appendix A: enforceability of ToS

The ToS in SecondLife is probably a legal contract. Legal contracts usually
(but not always, eg shrinkwrapped software) require "consideration".
"Consideration" means both parties must gain something from the action of
agreeing to the contract. Clicking on the "OK" creates a binding contract,
because you gain the right to use SecondLife (you didnt have it before
clicking Ok, unlike shrinkwrapped software), and SecondLife gains a
subscriber.

Disclaimer: I'm not a lawyer, I just read this on Slashdot one day. You use
this information at your own risk; it could be completely wrong.
[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=10>
]
Server-based IP enforcement

In an online game, it's not enough to own the most l33t armor: you need
others to be able to [i]see[/i] that you are wearing the most l33t armor.

Actually, we don't need necessarily to prevent people obtaining a copy of
objects and prims: but it could be enough to block them from the servers.

The way this works is that you register your newest creations centrally. The
sim server then checks objects regularly - or on demand - for similarity
with your registered creations.

Any object found to be too similar to your registered creation is wiped /
quarantined / signalled to an administrator / or similar.

When you "sell" an object to someone, you dont just transfer the physical
attributes of the object to the purchaser, but also the moral rights to use
and own that object. They purchase a licence, and the licence agreements are
stored centrally.

So, when the sim scans through objects for infringement against your
registrations, it ignores those people who have purchased a licence from you
for those objects.

The advantage of this is:

  - no requirements for legal intervention
  - potentially automatic, or at least semi-automatic
  - no assumption of client-side security

disadvantages:

  - need to trust the server
  - doesnt prevent people stealing items, just using them

Note that it could be combined with DMCA-type legal enforcement for two
layers of protection.

Server-based IP enforcement can be implemented in two way:

  - sim-based
  - centralized

Sim-based means the IP registrations are on a per-sim basis. This has the
advantage that there is no single server that can compromise everything you
own, but on the other hand maybe each server is less trustworthy than a
highly trusted single central server?

Looking at centralized IP enforcement, the way this would work is that there
is an IP server (or several?) independent of the sim servers. The
sim-servers check regularly - or on demand - with the centralized servers,
and deal with (delete / quarantine etc) any objects that are unlicenced.

Centralized IP enforcement means you only have to register in a few places,
but on the other hand you need to really trust those centralized servers.
[edit<http://manageddreams.com/osmpwiki/index.php?title=Intellectual_Property_Security&action=edit&section=11>
]
Alternate server-based IP enforcement

Content that's licensed under an open license (public domain, Creative
Commons, BSD, GPL, GFDL, etc.) doesn't need protection, just some way of
indicating the license it's under, and for some licenses, a history of who
modified it. It can be stored on the client in an open format, on one or
more sim servers, or on a central server. It doesn't matter. We could
implement support for all of these.

Content that's under a closed license (ie. simple copyright) needs
sufficient protection that casual copying can't take place. This can be done
by storing on the client in an encrypted form, with either a sim or a
third-party server to decrypt the content and send it to the sim.
Alternatively, it can be stored on a third-party server, and a "recept" of
some sort stored on the client to indicate ownership.

Under this system, when someone rezzes a protected object into a sim, the
client sends what it knows about the object (either the receipt or the
encrypted blob) to the sim. The sim checks the data header for the asset
server for this object, and sends the data on to it. The asset server checks
to see if the user really is allowed to rez the object, and if the sim is a
safe place to rez it. If so, it decrypts the data or retrieves it out of its
internal storage, and sends the result back to the sim, possibly after
degrading or watermarking the information. The sim then passes those parts
the client needs to know about (textures, objects, etc) to its clients, and
keeps the parts they don't need to know (scripts, physics) on the server.
_______________________________________________
Libsecondlife-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/libsecondlife-dev

Reply via email to