[#SVC-1656] Add a new next owner permission: Scriptable

2. Second Life Service - SVC

Add a new next owner permission: Scriptable

Created: 22/Feb/08 03:26 PM Updated: 12/Aug/08 04:36 PM

Return to search

Component/s:

Permissions

Affects Version/s:

None

Fix Version/s:

None

Environment:

Minimum Secondlife client hardware requirements and above

Issue Links:

Relates

This issue Relates to:

~~SVC-1581~~ Modify llGetPrimitiveParams behavior to fail if copyright conditions are not met

SVC-676 Stopping texture theft and stop spreading of stolen items

This issue is related to by:

SVC-2621 Meta-Issue: New/modified permissions

Description

« Hide

Idea of scriptable: Does the next owner have permission to run their own lsl scripts within the content they received?

Default value of Scriptable: on

When object is non-scriptable:
Next owner cannot add their scripts to other's digital ip. This prevents possibly harmful scripts from interfacing with a creator's digital IP

When object is scriptable:
Granted the object is also moddable, end user can run their scripts within others digital ip.

Benefit of adding this new permission:
Content creators can limit scripted theft and exploits in-world. The lsl system will not require any changes or degradations for others to use lsl functions in a respectable manner. Having an item like a skirt that is (copy/mod/no-transfer/no-scriptable) ensures the creator of the skirt that their creation will not get copied by a script. To the end user, having mod permission allows them to customize their creation to fit their needs without the assistance of laggy scripts. As a content creator of complex scripted objects, scriptable permissions will ensure the end user doesn't bug the system with scripts that listen for any communications protocol or bypass script security. Granted, with mod perms, end users can change the shape, texture, and add their own content to the system. Its just that they can't "cheat" by using lsl scripts irresponsibly.

What this new permission will not affect: Any item that cannot contain scripted inventory.

Concerning remote script uploads:
The use of remotely loading scripts into a non-scriptable object is up for discussion. While others may want to allow for such a function while the object is non-scriptable, I see any way to get unauthorized scripts into a non-scriptable object as a possibility for exploit. I reccomend that only scripts with the same creator be allowed for remote uploading while other scripts not created by the creator of the non-scripted object silently fail.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

miss hera added a comment - 27/Feb/08 04:58 PM

good idea.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 15/Mar/08 09:28 AM

This would be better than ~~SVC-1581~~, but it better be possible to determine that this restriction is in place BEFORE buying the product.

It would, by the way, not provide any meaningful protection against copying, since anything that can be read by a script can be read by libsl, but I supose it would make reverse-engineering of some scripted content harder. It would be better to avoid passing secrets unencrypted in the first place, though.

[ Permlink | « Hide ]

ilobmirt tenk added a comment - 15/Mar/08 10:41 AM

That is quite understandable. With Secondlife out in the open, anyone can be free to use its libraries for malicious purposes.

As for the later comment about script security, not many scripters are savvy enough to protect sensitive data. Besides, the current implementation of encryption functions are a joke. Also, lets not forget about implementing authentication. If done properly, an effective user-made encrypted/authenticated communication system between scripts will outweigh its positives through its use of system resources.

Even when lsl reaches the mono platform, I have a feeling that its functionality will not change. And as of now, I fail to find a proper authentication system for linked messages besides simple encryption. If implemented, this feature could help save resources while protecting the ip of scripters. (it's just geometry that can be intercepted by libsl right? scripts don't go to the SL client anymore?) While it can't stop copying geometry altogether, this can stop one means of copying.

The reason I placed this on a normal priority instead of critical and above is because this is in a way already implemented through the no-modify property. However, that would mean that the end product is not user configurable. I among other users would like to customize the things that they buy. It would be great to see this property added among scriptable objects sometime in the future. For now though, its just my suggestion and is pretty much optional to have this feature added in later releases.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 15/Mar/08 12:36 PM

The real solution for script security is to not pass secrets between scripts at all. If you need to store multiple texture keys such as texture IDs, keep them in the scripts and just pass commands to switch to "texture #n"... that is, use a code rather than a cipher.

I prefer to do that and actually document the link message API. Many of my scripts are open source or have open source control scripts so that people can customize the behavior of the products without needing access to textures and the like.

[ Permlink | « Hide ]

Gordon Wendt added a comment - 15/Mar/08 02:16 PM - edited

I have 2 words why this is a bad idea... fair use, unless you want me to define fair use I think that is enough to be very wary of this idea.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 16/Mar/08 09:47 AM

Second Life's permission system does not have support for "fair use" exceptions to begin with, so while I am definitely in sympathy I do not believe that's enough by itself to oppose this proposal. I think you need to go into more detail.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 09/Jul/08 09:07 AM - edited

I'm not really comfortable with having this implemented. My concern is the damage it does to Fair Use.

There are two main arguments for this feature suggestion
1) Stop third party script cloning.
2) Stop third party script interference.

1) As previously pointed out stopping script based cloning won't stop cloning. Script cloning is inexact and not fully featured, people rarely properly serialize their floats, vectors & rotation and llGetPrimitiveParams cannot cope with prim torture. Anyone looking to do cloning will just use the latest CopyBot produced by PN. Of the types of cloning, the easiest to detect is script cloning, regardless of what we do people will always try and clone objects, we should thus be encouraging people to use the type that can be most easily detected. The lesson we can take away from Orwell's 1984 is that if you want to stay in power, run the resistance, make it easy to detect cloning. Cloning isn't the big problem, it's the transference of clones that is the problem; it's the sale of clones.

2) There aren't many applications for scripted modifiable objects where you care about the integrity of the scripts. The rare exceptions are AOs which almost all use GPL code and distribution of those as no-mod is pretty much a violation of the GPL. Other scripts of interest are those clickable sex attachments (who's name alludes me at the moment), the designers of them are very disinterested in open interoperability.

Which brings us to the issue of interoperability. When it comes to script interop, people either don't want it, or they don't want interference. Interference falls into two classes, inappropriate access of private features and indecipherable/corrupt communications. The first is can be avoided by ensuring that all requests to private features are properly signed. The second is harder to script around but if you publish your comm specifications then the third party scripter will know how to write valid requests and how to add their own comms that won't interfere. Not wanting any interop can also be solved with message signing. Message signing isn't complicated and doesn't have to be all that slow.

There are even fewer applications where you have a mod object that needs encrypted communications between scripts; I just don't see there being enough demand for such a feature when there are workarounds in place.

[ Show » ]

Strife Onizuka added a comment - 09/Jul/08 09:07 AM - edited I'm not really comfortable with having this implemented. My concern is the damage it does to Fair Use. There are two main arguments for this feature suggestion 1) Stop third party script cloning. 2) Stop third party script interference. 1) As previously pointed out stopping script based cloning won't stop cloning. Script cloning is inexact and not fully featured, people rarely properly serialize their floats, vectors & rotation and llGetPrimitiveParams cannot cope with prim torture. Anyone looking to do cloning will just use the latest CopyBot produced by PN. Of the types of cloning, the easiest to detect is script cloning, regardless of what we do people will always try and clone objects, we should thus be encouraging people to use the type that can be most easily detected. The lesson we can take away from Orwell's 1984 is that if you want to stay in power, run the resistance, make it easy to detect cloning. Cloning isn't the big problem, it's the transference of clones that is the problem; it's the sale of clones. 2) There aren't many applications for scripted modifiable objects where you care about the integrity of the scripts. The rare exceptions are AOs which almost all use GPL code and distribution of those as no-mod is pretty much a violation of the GPL. Other scripts of interest are those clickable sex attachments (who's name alludes me at the moment), the designers of them are very disinterested in open interoperability. Which brings us to the issue of interoperability. When it comes to script interop, people either don't want it, or they don't want interference. Interference falls into two classes, inappropriate access of private features and indecipherable/corrupt communications. The first is can be avoided by ensuring that all requests to private features are properly signed. The second is harder to script around but if you publish your comm specifications then the third party scripter will know how to write valid requests and how to add their own comms that won't interfere. Not wanting any interop can also be solved with message signing. Message signing isn't complicated and doesn't have to be all that slow. There are even fewer applications where you have a mod object that needs encrypted communications between scripts; I just don't see there being enough demand for such a feature when there are workarounds in place.