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

Revision as of 07:25, 12 October 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, organizations, 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; for 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 enforceable --- 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

The fallacy of DRM

It's worth pointing out somewhere, just in case it hasn't come across, that the failure of DRM doesn't hinge on arms races or cleverness of crackers or anything like that. It stems from a failure to understand that encryption was designed to protect communications between Alice and Bob from the evil Eve, and not to handle the case where Bob and Eve are the same person. DRM proponents are trying to give Bob access to an item without giving him access to the item ... which isn't logical, Captain, and is always doomed to eventual failure. The Lindens do understand that, so all credit to them for not going down a path of self-delusion. --Morgaine Dinova 12:27, 2 October 2007 (PDT)

Related Jira Entry

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

The Jira discussion finally coalesced into some sort of general agreement that it would be A Good Thing for authors to be able to express their intentions with respect to downstream use of their work. This is true even under the inevitable "fallacy of DRM" ... in other words, it is worthwhile for an author to be able to express her intentions even in the absence of any guarantees. --Morgaine Dinova 11:55, 3 October 2007 (PDT)

Revision as of 07:23, 12 October 2007 (view source) Dr Scofield (talk \| contribs) m (→‎Related Jira Entry) ← Older edit		Revision as of 07:25, 12 October 2007 (view source) Dr Scofield (talk \| contribs) (→‎Related Jira Entry) Newer edit →
Line 103:		Line 103:

	[[Category:Architecture Working Group]]		[[Category:Architecture Working Group]]
	[[Category:~~AW Groupies~~]]		[[Category:AWGroupies]]