The Forder Foundation

Content theft is a serious issue.

So, by the way, is the problem of saleable appearance-related content that can’t be adjusted by the purchaser. I’ll admit to considering using CopyBot for some of the no-modify prim attachments I’ve purchased that simply could not be twisted or manipulated to fit my AV. (And btw, designers, those “adjustment” scripts you put in your objects so you can sell them no-mod are worse than useless. If your item is no-transfer, don’t make it no-modify, please.)

The level of disinformation regarding copying of content in SecondLife is stunning. Many content providers turn epileptic when the subject comes up. In the interest of clarity, I offer the following points:

• Any object that is rendered by the SecondLife viewer is sent to your computer. If you look at the build dialog, you can see all of the attributes of a prim, except in those cases where the SL permissions system prevents you from modifying them. But even if you can’t see those attributes, a copy of those attributes has been sent to your computer. If you know where to look, there’s a file on your hard disk somewhere for most of the prims you’ve looked at this week.
• Any texture that’s applied to the surface of a prim within the radius of your draw distance is copied to your computer. Period. It doesn’t matter what the permissions on the texture are set to or who the owner is. Again, if you know where to look, a digital copy is in your texture cache.
• You don’t need any special tools to “copy” objects to your computer from SL. You just need to understand how the caches are indexed and the file formats for the objects that are cached. Since the viewer source code is available, that information is public knowledge.
• It would be a trivial exercise to write a cache miner that let you inspect prims and textures offline. I used to have a similar tool to mine the Safari cache on my Mac; it revealed the HTML, CSS and image content that was left on my disk after browsing a website.
• It would be a similar trivial exercise to write a program that downloads the attributes of an object and creates a new object with those same attributes. That, in fact, is what CopyBot is: a modified SL viewer that captures the data from the prims for a particular build (a prim or set of prims) and creates a new build that replicates the first build.
• There is no digital rights management technology in SecondLife. What passes for DRM in SL is actually
• A server-side object permissions scheme that flags the attributes of a prim to mark whether the object can be copied, modified, or transfered between agents and allows/prevents those actions in-world.
• Some code in the client that respects the “no modify” bit on an object to prevent the stock SL viewer from displaying the attributes of an object within the viewer when that object is edited. (Reemmber, though,that the attributes have already been copied from LL’s servers onto the computer where the viewer is running.)
• A protocol for uploading textures, sounds and animations (but NOT objects) to the LL asset servers that allows LL to charge a per-item fee for each of those items stored.

All of the above are part of the genius of SecondLife. Nothing is pre-rendered, which is why you have to wait for a place to “rez” after you’ve teleported (and also why distant objects “spring” into view when you approach them.)

Current DRM implementations are all variations of the following:

1. The object that is downloaded to the viewer’s system is encrpted in some way.
2. The viewer for that object stores autentication for the purchaser of the content.
3. When the object is viewed, the viewer contacts some service via the net to validate the authentication credentials for the viewer and determine if the viewer is authorized to reveal the content
4. The response from the authentication server is what allows the viewer to decrypt the content, so that it can be rendered into a form that the viewer can display.

Substitute “player” and “listen” as appropriate for audio objects. This is somewhat over-simplified, but it covers the concepts.

Now consider: if we inject true DRM into SecondLife, every prim you see has to go through the DRM process before it can be rendered. Even allowing for caching, there are a huge amount of additional network bandwidth, client-sde processing, and server usage required to keep up. How many prims are visible within 64m of your avatar? Within 128m? Within 512m?

The real reason LL doesn’t implement DRM for objects in SecondLife isn’t that they don’t care about content theft. It’s not that the problem is too difficult to solve technically. It’s that any system for object-level DRM that they could implement would have a drastic impact on the in-world experience for viewers.  Some avatar hair goes to 300 prims. Applying DRM to groups of objects rather than individual prims simply moves the processing overhead from the client to the server. Bear in mind that the asset servers are already one of the most notoriously fragile aspects of SecondLife.

Besides, do we really want a world where you have to pay for every prim? How much content would there be, realistically, if the same charge for uploading a texture applied to every prim you rez?

LL has its internal issues, and SL is far from a perfect platform. I’m hardly the person to comment on what LL’s internal discussion of this issue has been, but it’s hard to believe it’s not on their radar. I’m just not sure there’s anything that they can do about it without drastically changing the SecondLife experience.