Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Copybot solution? Let them eat plywood!
Shep Korvin
The Lucky Chair Guy
Join date: 30 Jun 2005
Posts: 305
11-16-2006 06:48
Here's something confusing me about the copybot:

It can copy prims. That's a given. I understand that it does this by intercepting the prim paramaters that arrive at the client, and sending back "build" messages to the server with exactly the same parameters. It's a bit like a human user rezzing a bunch of new prims... (albeit with ruthlessly fast accuracy and efficiency) - and I can see why it's not really feasible to put server-end guards against that kind of client behaviour.

Here's the bit that I don't get...

Having rezzed all these prims, the copybot then manages to attach texture asset IDs to the new items... texture IDs that a human operator, at the regular client, wouldn't have reproduction privilidges on.

Intinctively, this strikes me as a flaw. An exploit. A security fault at the server end of things. The server should _not_ be accepting requests from a client to associate a "prohibited" texture to a client-rezzed prim.

Do your servers blindly accept messages from a client to apply *any* texture to a prim? Did you assume the client wouldn't fall into enemy hands? ...and would always be well-behaved and only request prim textures that the user was entitled to request?

(OK, dumb question. We know this the kind of oversight that brought about the existance of megaprims)

If the security model was - hypothetically - less trusting, then the copybot would only be able to rez "plywood" copies of stuff. Yes, it's possible for copybot users to extract textures via other means, and to upload + apply them manually - but at least that would cost them L$, time and effort to do. It stops the copybot being a casual "drive-by" cloning device; that's what a lot of people fear.

Anyway, here's my questions:

1. Is the copybot using a security loophole to reproduce the textures when cloning items?

and if so:

2. Any chance you could... urm... close this loophole anytime soon? I'm sure many content creators would be a _little_ happier if the copybot was restricted to generating crappy plywood clones of their wares.

If (2) is viable... could you publish an ETA? Then content creators could make a sensible risk assessment / business decision about taking their prim wares off the market for a while, and putting them back out when your servers are fixed.

IMHO, this would be a *massive* step forward by LL in mitigating the hysteria surrounding this loophole, and restore a lot of faith from the content-creating community.

Shep K.
Kelly Linden
Linden Developer
Join date: 29 Mar 2004
Posts: 896
11-16-2006 11:24
All textures have an ID in Second Life, all everything has an ID. All objects reference the textures on each side by their ID, so this data must be sent in some form to the client. What form this takes and if it is something we can control enough to prevent copybot like applications from using existing textures is something that Linden Lab is discussing internally.

It is important to note that the sole benefit of this would be to put appropriate meta data on the objects and textures. No matter how much we hide or control the IDs at some point we send the texture to the video card. There exist many applications that excell at trivially copying textures out of video card buffers, where they are well beyond our control. Configuring a copybot like application to re-upload the needed textures would probably not be a difficult task. However there are advantages to forcing it to do so, and we realize this - primarily being able to add uploader ID and timestamp data.

This is not to say we have a solution or are working on this at this moment. It is still at the pre-design phase, we are still discussing what is possible.
_____________________
- Kelly Linden