Difference between revisions of "Protecting content in an open grid"

Revision as of 05:52, 26 September 2007

Protecting content in an open grid

On the sldev mailing list a discussion is taking place about how to protect content (objects, textures, scripts) in a future open grid (that is, a large grid that is an interconnection of grids operated by different companies, organisations, and individuals).

Basically we face the following challenges:

content creators want the ability to specify rules about how the content they make available can be used; fore example,
- "you can modify and copy but not transfer (sell) what you got from me (for money or for free)"
- "you can modify, copy, and transfer but not sell what you got from me"
- "you can do whatever you want with what you got from me"
- "you can take what you got from me with you to all grids that are trusted by Linden Labs"
content is basically just a series of bits; that is, a sequence of 0s and 1s. as such it is copyable. any SL client will by necessity have a copy of the visual part of content (including sound) as it has to render the content to the user
- with an open source viewer/client you can always copy the visual part of content
- scripts are (currently at least) running on the grid servers and can be protected that way (i.e., the server does not hand over the script to the client if the permissions do not allow this): in an open grid we will have grid servers that are not under the control of LL (that is the whole purpose of the open grid) and thus a grid server could very well provide copies of scripts to anyone

so, basically the challenge is that content providers want to specify rules for the content they create and at the same time with an open grid and with open source SL clients we cannot guarantee those rules.

DRM?

The challenge we face is the same as faced by digital content providers in the real world; for example, MP3 music outlets. The temptation is to try and go the same route that has been tried by those RL content providers: DRM (digital rights management)

There are a couple of problems with DRM systems:

DRM systems in the past have almost always been cracked
DRM systems tend to be rather complex and thus expensive to maintain
in the end the content has to be displayed: couple that with an open source client and the DRM effort is nullified.

The consensus on the mailing (and also one voiced by LL) is that DRM is not going to work in an open source, open grid environment.

Do away with permissions?

The current permission system "works" --- kind of. Objects and textures can be copied (modified SL client offering "right click->save as...", libsecondlife based "copybots"), scripts are protected by the grid servers.

So, we could make the argument that in an open grid environment we cannot guarantee that an attached foreign grid or an attached client cannot by-pass the permission system nor that they cannot make use of content that contradicts the intentions of the content creator --- thus, we could argue that we can just forget about permissions and not bother.

Let's step back for a moment and look at the permission system from a different angle: we can also view the sets of permissions an object has a license digest. this license digest communicates what rights the content creator wants to give the content consumer. instead of having a 100 page EULA to go along with that super-duper flying broomstick you have a fairly compact set of permissions that tell you...

you can modify that super-duper broomstick
you can make personal copies
you can transfer copies
you are not allowed to charge for it

so, yes, permissions are not technically enforcable --- but they make sense as a license digest.

Extending the current permission system

Two extensions have been suggested to the current permission system:

transfer to trusted region --- that would allow the content creator either
- to allow transfer of the content to a list of trusted regions, or
- to allow transfer to all those regions that are trusted by a list of regions that she trusts
sticky permissions --- permissions that cannot be changed down the food chain; for example,
- sticky transfer permission and sticky price tag: you can transfer the object, but you cannot take away the transfer permission, you should also not charge for the object.

Dr Scofield 04:29, 26 September 2007 (PDT)

Discussion on the mailing list

Unfortunately the archive messed up and the permission thread is all over the place, but here are some link from which you might want to follow downwards the stream: (probably also happens due to keyword juggling in the subject)

Basically it's the September archive.

Summary

I think all participants are more or less agreeing on the fact that a strong(er) DRM is not possible to be implemented.
Permissions are here to stay, but these access constraints can hold only within the walls of specific managed grids.
New permissions might be needed such as:
- allow an asset only to be used inside one region domain
- allow an asset only to be used inside one grid (= list of trusted region domains)
- allow an asset only to be used inside a set of region domains
  - For example, using signed certificates and revocation lists (possible implementation)
It should also possible to create full-perm assets that stay full perm (such as a GPL-style license).
It should be possible to make your intent more clear.
- Additional specific flags indicating certain permissions, even if they can't be enforced to serve as notice.
- An additional license field for license and copyright text, similar to land covenants (for e.g. CC licenses)

Thought on DRM

This is a personal thought, but rooted in some fairly deep considerations. Given the real world nature of a distributed application and security, DRM becomes a perpetual arms race, and not one any standard is likely to win. We can, and should, however, try to make sure the system can aid in marking intent and in detecting theft and abuse, so that people can use other remedies when the theft hits levels where that matters.

A second, related thought, is that, we can, and should ensure that what we build permits marking content such that a sub cluster with a trusted set of services and trusted clients and keep content within that space, while allowing public hosted content to be used.

- user:Zha Ewry 9/25/2007

Related Jira Entry

VRW-2571 : Copyleft/share-alike permission for SL Items

@@ Line 1: / Line 1: @@
+[[Image:slarch.jpg]]
 ==Protecting content in an open grid==
@@ Line 95: / Line 97: @@
 [https://jira.secondlife.com/browse/VWR-2571 VRW-2571 : Copyleft/share-alike permission for SL Items]
+[[Category:Architecture Working Group]]