Protecting content in an open grid

Starting in September of 2007, there has been discussion on the sldev mailing list 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 transfer (give away or sell) what you got from me, but you can't make copies of it"
- "you can modify and copy but not transfer 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"
- "you can modify this object but only to repair it to work in future simulator software, or to create a derivative work for sale to citizens of Portugal" (this example serves to illustrate how complex real licenses can be)
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 (absent hardware features that aren't currently in place and seem unlikely, such as a shared secret between the server and the video card)
- 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 in control of it.

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. This is not necessarily fatal; an economy can work even when theft is possible. But it is a fundamental limitation to what we can do with technical solutions.

Linden Lab statement on content protection in interop

On 8 July 2008, a posting in the Second Life weblog entitled "IBM and Linden Lab Interoperability Announcement" included the following text:

Q: How will Linden Lab prevent property from being copied into other virtual worlds?

We’re paying extremely close attention to that question. We will be designing this with the Second Life community to ensure their needs are met. We want to stress that when it does become possible to move avatars between worlds, we will take the utmost care to protect the rights of Second Life property owners and creators. Linden Lab will not design a system that lets people openly violate the permissions of SL goods and take them to other worlds. We recognize that intellectual property is the engine that drives Second Life, and we are completely committed to preserving the qualities that make Second Life the unique, innovative and dynamic place that it is today.

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.

I think we ought to be more specific about just what kind of DRM we're referring to here. To the extent that the SL mod/copy/transfer bits are "DRM", we have good evidence that they work well enough to support an economy, even with the client opensourced. There's no reason to think that this kind of DRM can't work just as well in an open grid, or at least that subset of an open grid in which there are mutual and enforceable agreements in place about obeying the bits. I assume this "is not going to work" refers to trying to make the system strong enough that even a skilled and determined attacker can't get around the protections? The talk in the list didn't really call this out clearly I don't think... -- Dale Innis 08:33, 18 July 2008 (PDT)

Do away with permissions?

The current permission system works --- kind of. Objects and textures can be copied (by a modified SL client offering "right click->save as...", or by libsecondlife based "copybots"), while 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.

But 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 as 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

or alternately

you cannot modify that super-duper broomstick
you can make personal copies
you cannot transfer copies

So, yes, permissions are not perfectly enforceable by technical means --- but they make sense as a license digest. Technical means (code) can make it difficult or inconvenient to violate the license thus expressed, and can make it possible to detect violations so that other remedies can be employed when the technical protections fail.

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)

Other related extensions:
- allow transfer of the content to an indirectly-referenced list of trusted regions or domains (e.g. "the official list of Linden Lab Category A Partner Regions", or "Jared Hu's List of Regions Run by Friends", or whatever)
- allow transfer to some set of domains, but not some other set (exclusion as well as inclusion)

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. (We need to clarify this statement so it doesn't frighten people who read this without reading all the discussion. Dale Innis 08:45, 18 July 2008 (PDT) )
Permissions are here to stay, but these access constraints can hold only within the walls of specific managed grids. One grid can only assume that another grid will respect the constraints if there is trust (backed where appropriate by enforceable agreements) between the 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

Those are good thoughts. I would add to them the suggestion that, as well as marking intent and detecting violations of intent, the system can make violation less convenient. This is reasonably important; there may well be cases where an economy will work if intent-violation (e.g. copying contrary to the license digest) is possible but inconvenient, whereas it would be on the other side of the viability curve if intent violation is trivial (i.e. press "copy"). We should not let the (impossible) perfect be the enemy of the (possible) good. :)

- Dale Innis 08:49, 18 July 2008 (PDT)

Arms Race Can Be Fought or Pretended to Be Fought

The doctrine of the "arms race" in software needs to be challenged vigorously. In RL, countries engage in arms races out of necessity because there are other factors outside the immediate realm of the arms they are racing with that can contribute to a favourable outcome. For example, Reagan believed that by ordering Star Wars anti-missile defense to be built, he could trump the Soviets' SS 20s threatening Europe's Pershing missiles, which were there in turn to counter conventional weapons. He could then bankrupt the Soviets and impoverish them as they struggled to build a system against Star Wars (note: I'm describing a historical event, not endorsing a policy). Online, there's no reason to consider that arms races are endless by their nature merely because they are technical, and that other factors of attrition cannot enter in.

In the SL setting, it is (still) a small world, and griefers' groups wanting to bother with SL a small and known quantity. Arms-racing against some of them is a trivial matter; they are kids. So the pool of hackers becomes reduced, and sure, more try the next time and the process *may* invite opportunistic players in the arms race game, but generally each new effort to obfuscate or create dodges or feints or decoys or poison apples or red dye jets or whatever the methods are wins some, and reduces the ranks. It also begins to establish the concept of "we mean business and we will keep stopping you". It doesn't even have to work every day. The DRM can, as indicated, merely mark intent; it can, as said here by Zha, merely mark the violation to trigger remedies. But it is good in its own right to stop casual thefts: the DRM of c/m/t works wonderfully in SL and should not be retired or dumped in the interoperability gambit. An arms race in cyberspace doesn't threaten the lives and property of real people; it impoverishes griefers only in time and ingenuity. It is worth fighting; it is worth *pretending* to fight. Digital rights management is not about digital; it's about rights and about management.

- user:Prokofy Neva 7 November 2009

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)

No, DRM is Not a Fallacy

DRM is not a fallacy. That is an opinion of one extreme school of thought, and not a fact. As noted, arms races can be fought; can be pretended to be fought; can have partial or full valid outcomes. While submitting typical coder opinion to the wiki seems valid enough, no opinion of this nature should be portrayed as "fact" and enabled to shut off further discussion. Prokofy Neva 7 November 2009

Usecases

Security Related Usecases (more needed!)