Pulling scripts from no-mod prims

[Auburne LittleBoots]

I have never noticed this before ... but is it just a fluke that I am experiencing?

I create an object that I set to copy-only. I add a script, and I set the script xfer-only. When I take it all back into my inventory, it will show no-mod/no-copy/no-transfer when I give it to someone ... because of the permissions mismatch between the prim and the script it contains.

BUT

That person can edit the object, remove the script, and give it to someone else, because the script has xfer permissions.

Is that what should happen? Maybe I'm just naive, but I thought no-mod meant they could not adjust the contents of the prim, either by adding or removing. But it seems they can actually remove the script, giving them an xfer-only script that is not contained in the prim I packaged it within.

 

[Perrie Juran]

---

Auburne LittleBoots wrote:

I have never noticed this before ... but is it just a fluke that I am experiencing?

I create an object that I set to copy-only. I add a script, and I set the script xfer-only. When I take it all back into my inventory, it will show no-mod/no-copy/no-transfer when I give it to someone ... because of the permissions mismatch between the prim and the script it contains.

BUT

That person can edit the object, remove the script, and give it to someone else, because the script has xfer permissions.

Is that what should happen? Maybe I'm just naive, but I thought no-mod meant they could not adjust the contents of the prim, either by adding or removing. But it seems they can actually remove the script, giving them an xfer-only script that is not contained in the prim I packaged it within.

 

---

Even if the object is No Mod you can still pull any content out of it.  And that content will have the permission you set it to.

However, if the object was No Mod you wouldn't be able to put the content back in.

It could be in one sense looked at as the one weakness in the permissions system. 

One thing here, if the script was 'no copy,' when they rezzed the object itself, even if it was set to copy, when they rezzed it it would no longer have been in their inventory.  After removing the script, all they will have left is an 'empty shell.'  That empty shell they could copy all day.

I hope I've stated this clearly enough.

[Perrie Juran]

Adding here:

"The copy property applies outward. If an inventory item inside of an object is no-copy, the object itself cannot be copied until that item is removed. Conversely, if an object is no-copy, that does not imply that the contents are no-copy . "

http://wiki.secondlife.com/wiki/Permission

[Auburne LittleBoots]

Well, the problem is that I created an item that, when rezzed, communicates with a server and gets an ID# associated with that object. If someone else wants one, they will have to get their own item.

But if the script can be removed and copied, then that individual gets multiple ID#s, when they put the copies of the script in different prims. Or if the script is transferable, then they remove the script and give it to someone else, who gets their own ID#. Because those scripts, extracted from the prims, will behave like a new script when they are instantiated in-world.

That creates an issue for scripts that should obtain an ID# to be used only with that script. I guess I could put in "safeguards," like checking to see that the prim the script resides in was created by me, or something like that. But it is clearly something I discovered unexpectedly.

[Rolig Loon]

It would be very nice if we had an OBJECT_PREVIOUS_OWNER option in llGetObjectDetails, but we don't.   Failing that, you can write your own complicated system for safeguarding against the sort of problem you're facing.

One way is to write something like

default{    state_entry()    {        key owner = llList2Key(llGetLinkPrimitiveParams(3,[OBJECT_DESC]),0);        if (owner == llGetCreator())        {            state NewOwner();        }        else if (owner != llGetOwner())        {            llDie();        }        else        {            state running;        }    }}state NewOwner{    state_entry()    {        llSetLinkPrimitiveParams(3,[OBJECT_DESC,(string)llGetOwner()]);        state running;    }}state running{    // The rest of your script}

 Then you store your own UUID in the Description field of link #3 (which can be a tiny transparent prim inside your object).  Every time the YOU rez a copy of the object, it simply recognizes that the stored UUID matches your own as the object's creator, so the UUID in that Description field doesn't change and control passes through state NewOwner to state running. 

When you give the object to someone else and that person rezzes it for the first time, your UUID is still in the Description field, so the first if test in state default is satisfied.  Control passes to state NewOwner and the description field changes to hold the new owner's UUID. After that first time, every time that the new owner rezzes a copy, the first if test fails but the second one recognizes his/her UUID and lets control pass directly to state running.

If the new owner transfers the object to a third person, however, THAT person's UUID will not pass either of the two if tests in state default, so the object will die. 

It's not foolproof and it's not the only way to solve the problem, but it works.

 

       

[Auburne LittleBoots]

Thank you, Rolig. That approach could be helpful.

I did think of something else, working with my partner on this issue. I can start by checking (a) the script is in a prim created by me and (b) the script is in a no-mod prim. If so, it will work. But if they removed the script and put it in another prim, it won't do anything (or will llDie), because they cannot put the script in a no-mod prim created by me.

So, for anyone else reading the thread, that is another alternative for preventing someone from extracing the script and adding it to other prims.

[Rolig Loon]

Yup.  That would do the trick too.  Once, years ago, there was a thread in the former forums in which we traded schemes for defeating the second owner.  We also had a nice discussion about ways to defeat most of the schemes.  There were some really good ideas. I wish I had saved that thread, because I can't seem to find it now. 

[Perrie Juran]

---

Rolig Loon wrote:

It would be very nice if we had an OBJECT_PREVIOUS_OWNER option in

llGetObjectDetails

, but we don't.   Failing that, you can write your own complicated system for safeguarding against the sort of problem you're facing.

 

       

---

I'm just thinking out loud here but am wondering if a reason we don't have this is because then people could abuse it to defeat the "Right of First Sale."

 

Right of First Sale

The right of first sale applies when an item is transferred without next owner copy. Since you are allowed to specify no derivative works by specifying next owner cannot modify, this right is interpreted as next owner can always transfer that single instance of the item to anyone else.

http://wiki.secondlife.com/wiki/Permission

And that could get into some touchy legal issues.

I know, we could get into a long side discussion on this.