|
Kyrah Abattoir
cruelty delight
Join date: 4 Jun 2004
Posts: 2,786
|
05-19-2006 01:31
after failing several game projects due to hacking possibilities i started wondering what really mean nomod in SL, it would suggest an object is unmodifiable and unalterable, however it seems we STILL can supress stuffs from the object inventory or pull out what it contain, i quite don't understand why nomod wouldn't lock completely an object, not even allowing you to see what is inside, i belive its something much needed for client object trustability
_____________________
 tired of XStreetSL? try those! apez http://tinyurl.com/yfm9d5b metalife http://tinyurl.com/yzm3yvw metaverse exchange http://tinyurl.com/yzh7j4a slapt http://tinyurl.com/yfqah9u
|
|
Torley Linden
Enlightenment!
Join date: 15 Sep 2004
Posts: 16,530
|
05-19-2006 20:25
Asking for clarification on this...
|
|
Kelly Linden
Linden Developer
Join date: 29 Mar 2004
Posts: 896
|
05-19-2006 23:06
The permissions system in Second Life is one of the oldest parts of Second Life. It is not perfect, and definitely doesn't match all the use cases wanted in today's SL. Additionally it is one of the most complex and convoluted systems in SL, and thus the hardest to change. A permissions system re-working has been on our collective minds for some time now.
That said, here is the reason for no-mod's behavior - a historical design philosophy of the permissions system. One philosophy behind the permission system was to give BOTH the creator AND the owner some rights to the objects. This is manifest primarily in 2 places. You can not make an object both NO COPY and NO TRANSFER. This means an owner always has the right to either make copies or give the item away, sometimes both but never neither. The creator has the right to choose which they can do.
The other case is NO MOD, which isn't truly no mod. The creator can decide that the object's shape, colors and textures can't be modified or appended to, no new contents can be added and that the contents can't be directly modified. No one can add another script, or link another prim, or change the parameters of any of the prims.
However, at the same time the owner has the right to dissasembly. They can pull contents out of the object. A real life analogy may be buying a DVD player. After you buy it, you are free to take a screwdriver or hammer or saw and tear the player apart. It may no longer work, and you may not be able to put it back together, but you can surely do it. In SL contents can be pulled out but not put back.
Being able to see the contents of NO MOD objects is part of the same thing, the owner has the right to see what the objects he or she owns is made up of.
One primary concern I have seen regarding this is scripts being pulled out and put in another object to be hacked. This is a valid concern, and there are many applications which were not predicted when the permissions system was created. However some of this can be worked around, as long as the script itself is not modifiable. Security code is only a few lines long. You can check that the script is still in the right object, owned by the right owner and even that no unexpected other scripts are present in the same object, that the object has the right number of prims etc. Here is a simple function that can protect from some hacking by killing the object if this script is put in someone else's object. Yes, it's a bit harsh, and yes it has a loophole if they have any of your objects that are modifiable: this is just an example.
void secure()
{
if (llGetCreator() != "hard-code-your-id-here") llDie();
}
_____________________
- Kelly Linden
|