Update "Modify Rights" & Prim Linking

I wish Second Life would update their "Modify Rights" to allow the creators to turn certain rights on ( like stretch, or color ) and turn off certain mod rights like (unlink, duplicate, texture, and showing prim details like size, shape etc ) then designers could give certain modify rights on their prims and not allow other types of rights.
I also wish, that when linking prims, that they become a full mesh workup as a whole prim and then copycats can't see the individual mesh/prim pieces to duplicate them. ( You know do not show the outlines, do not show the individual shapes ( block that ).
Also if a designer chose to do this type of setting, and link the full prim making it one entire prim that cannot show the details and individual pieces, that the UUID became a special sort of UUID that would hold a type of DNA, so that if a person did use a copybot that the UUID would show who the original creator of the original shape was, and then it would show that it is a 2nd generation copy, this way these special linked creations could then be traced as to who made the original one.... and this would stop copycats from saying they created them, no matter how much they changed them/texture/color etc.

These ideas would really help the true designers, and limit the number of copycats.

I understand the difficulty in implementing these ideas, but it's just as difficult to create new features in SL and spend months or even years debugging those and even more difficult to deal with all of the messages and such that you must get from upset designers that fill out help requests to state someone is copying them.

I think it would be worth your time and effort to do these things as they'd later reduce the number of complaints you would get and the number of people you currently need to answer all the complaints.

Just Ideas for a Better World in Second Life.

i would like that nomod become REALLY nomod

i the fashion that you cannot see the object inventory or interact with what is inside.

I would like "nomod" to go back to when it was even *less* "nomod".

You used to be able to "break" nomod objects, by deleting inventory from them. I used to do that all the time for vehicles I was using as props so I could cut down the script overhead in the sim. You can't do that any more.

you mean it isn't possible anymore to extract scripts from a nomod object? O_O

when did i miss this!!

I'll vote to get rid of no modify altogether (except on scripts I guess).

Anything that's no mod can't be renamed (huge pet-peeve ) and for anything prim-related, copybot showed that whoever is intent on stealing will find a way, so the only use for no mod is to frustate customers (I'm "old" enough to not need floating "Sit Here" text in my house, pose-balls only unnecessarily waste prims and I don't need every last bit of decorative furniture to be a light) or loose out on a sale.

You can't even edit modifiable notecards in no-mod objects. I sell items that have some quite fiddly scripts in them, deleting just one can completely wreck the whole object. They are also in various prims. Therefore what I want is to be able to make it no-mod so the user can remove/damage the scripts or remove the prims containing them, but can still modify the notecards. I might bug-report this one actually, as it seems incorrect to me.

That's correct.

I dunno, I bitched about it in the forums when I noticed because I couldn't use a prop flying saucer, I'm surprised you didn't catch that.

If I bought an object, why shouldn't I be able to damage it? The only one who potentially loses by that is me.

The thing that really bothers me isn't no-mod objects, it's no-mod clothes and other wearables. Clothes don't need to be no-mod, since what makes clothes clothes is the textures, and for clothes they're already effectively no-mod... and making them no-mod means you can't adjust them to fit your avatar's attachments.

thing is that nomod should stay i mean hell i sell all my prim stuffs in mod, but there was countless game project that i stopped because the old nomod behavior made it so easy to hack them.

but you mean that it isn't possible anymore to right click delete something in a nomod object? if that's the case then i might blow the dust of some ooold projects.

Well yeah, but I'm too nice to my customers, and as it is currently I've had to make items modable that I didn't want to, result being that the odd customer manages to arse it up because they think that because it's modable that they're supposed to change the appearance and remove parts that they don't realise contain a bunch of important scripts. Result being that if they do break it I feel compelled to give them a replacement (in exchange for the original of-course, won't do this with copyable objects!). I'd rather be able to prevent them from doing that kind of damage in the first place.

I do get what you mean though with removing scripts for performance or whatever. I would have thought I could still remove items if I wanted, I wouldn't really mind that; as a customer stupid enough to start deleting scripts in a scripted object needs that kind of lesson to learn. It's more the having to allow people to disassemble my items, just so that someone can modify a notecard in my product that is a problem for me.

Perhaps then, making an object no-mod should still allow the user to do whatever they want with the contents (privvy to the rights of the contents themselves), with the option to delete always there. So I could have my nice object with its n-mod scripts and editable notecard, make the object itself no-mod. And now users could edit the notecard happily without any chance of breaking anything, but if they really wanted they could empty the object to leave it as a decorative piece or such.
Even then inventory permissions could apply slightly differently. If an item in an objects inventory is not copyable, it could also be made no-transfer. This 'erroneous' permission means you can make scripts that aren't modable, and also cannot under any circumstance be removed from the object they reside within. However this permission of course cannot be applied to objects that are not within another object's inventory.
This allows scripted items which require some kind of security (e.g a pair of special security scripts that ensure the validity of the item and check each other for being disabled) from having those scripts modified. While an object with a night-light script doesn't need this should the user decide to have the light on all the time, or the lamp just as decoration.

well personally if you want to allow the object to be broken down you let the mod right, i can see countless of application where i have to give an object to someone for it to work (tons of games) yet i do not wish the said oject to be tampered with.

That's a valid use no?

If it's no-copy, I could see a reason for making it no-mod, but then I gotta ask why you're selling a complex device like that no-copy?

That would make things like no-mod aircraft a lot less annoying. I ended up building a plane from scratch because the version I bought was no-mod and the creator wasn't interested in fixing the bugs. On the plus side that makes me a better builder. On the minus side I'm not going to buy any more no-mod planes.

Your idea about having items that are no-transfer and no-copy is really scary, though. I don't like the fact that you can effectively make object no-copy-no-transfer by making them no-mod no-copy and putting a no-transfer item in the inventory... and I suspect that this is precisely why LL has made this change, because people have been using this hack to make serialised or watermarket security tokens for gambling games.

If there's a need for some kind of server-managed watermarking or serializing on objects, Linden Labs needs to implement that rather than supporting this kind of abuse of the permissions system.

No.

This is precisely what I mean when I'm talking about things liek serialising and watermarking.

Being able to tell if tampering has happened, yes. Not being able to tamper with it, no.

Oh sorry, my explainations are generally crap, I'll try again.
Basically, the idea is that if an item in an object is no-transfer, it cannot be removed from the object. It wouldn't make the object no-transfer though unless the inventory item was copyable (thus normal behaviour).
e.g:
I have a box, it has two scripts in it. The box is copy/mod/transfer, the scripts are both no-mod/no-copy/no-transfer.
What this means is that the scripts simply can't be removed from the object, ever. However, the object itself is still modable, copyable and transferable. However, if the scripts had been no-mod/copy/no-transfer, then the object would no longer be transferable.

Really it was me going off at a tangent though, just another idea for allowing creators to protect scripts that they absolutely do not ever want removed from their items. In order to combat the fact that my first suggestion/alteration would allow scripts to always be removed from a no-mod object.

I don't like it.

1. Rather than making it so the scripts can't be removed from the object, give people some attribute of the object that makes undetectable modifications impossible. A watermark or serial that is destroyed if the object is modified, for example.

2. If you were going to have a "no remove", then make it a new permission.

Which is what used to be possible.

Oh, and sometimes you need to do that to FIX an object. I had an avatar that had a broken no-mod AO in a no-mod object, and I was able to fix it by pulling the anims and script out and putting them in a new attached prim. I was not able to get a response from the creator, so if I couldn't do that I'd have been out of luck.

Well as I understand it, in the circumstance I described, no-transfer is already there but unused (because no-copy over-rides it). Renaming it for that case though would make sense. As it's only needed in that case anyway, as having a copyable, no-remove item makes no sense as you can't remove it to copy it =)
It just seems to me like it makes most sense since the field is already there and to add it as an option requires logical additions only to check for it when attempting to remove from an object (ie: if (no-copy && no-transfer) then deny-transfer.

But the reason I'm on this really is that LL must have made the change for a reason, perhaps responding to author's complaints that users could remove scripts from their objects and place them into other object and they do not want this. It's still a valid thing to want I think, but LL has made the wrong choice in doing a 'blanket' fix and prevent all forms of editing inside a no-mod object.
So I agree with you that the previous system was preferable on the whole, I also agree that it is a valid concern to want to prevent transfer of some object contents. So I think some compromise is needed, and IMO using the no-transfer permission in this special case (if it can be, I have a loose understanding of how permissions are stored but I figure it to be much like unix style perms but with more rules), then it would be the simplest way to allow some compromise on security of contents, and user ability to interact.
So for my items (which to respond to an earlier comment I made no-copy as they are quite expensive and get used in establishments as well as homes, making them copyable would impact my business too much, though I grant some leniency on known down-time/content loss periods), I would have the object itself no-mod (so it can't be delinked), but allow minor scripts and all notecards to be editable, with the main scripts being no-mod, no-copy and no-transfer/no-remove.
This would give a perfect mix of robustness with the customisation my users want.


While that's a valid complaint, users shouldn't have to be responsible for fixing products. So long as this new 'no-remove' feature were used sensibly (and defaulted to off) then as long as no creator does it for all their scripts then this is still possible if we really HAVE to do it.
Out of interest, do you know what actually caused the fault? I notice that it doesn't seem to be possible to reset no-mod scripts, the ability to always reset them in the event of a script crash (stack-heap collision) could help there as that's the main issue with scripts that I can think of, except for just crap ones in which case you're stuck either way unless you want to write your own.

In the circumstance you described, either (a) this is actually a new permission that's displayed as no-transfer/no-copy for some odd reason, or (b) this is actually an object with no-transfer *and* no-copy set, and there's a mechanism to set both modes. Case (b) is too difficult to implement safely (allowOperationBy() only looks at a single bit, and would have to be changed everywhere inthe code base), and if it's a new mode why not call it that?
I have no doubt that that's what happened, but what they have said is that this was changed to prevent an exploit. What this does is create an exploit, because it allows a content creator to deny a customer the right of first sale.
I would say that "no-remove" would have to be a new mode, and if it was set then no-transfer and no-copy would be cleared... and it would have to be possible to set a no-remove script non-running.

I don't care whether I should "have to be" responsible for fixing a product I bought, I have "had to be" responsible for doing so thousands of times in my lifetime, everything from software bugs to loose fittings, tight fittings, missing components, miswired components, and design flaws. Anything that makes that impossible has to be justified by something more than "the guy who made it didn't think you should be able to do this".

No, I attempted to determine the difference between a working and a non-working version, but I couldn't see any.

Replacing software with my own versions is a pretty common way to fix stuff. In "First Life", people even package up replacements and provide them as patches, replacement modules, enhancements, and they *sell* them.

Given that most scripts in SL are pretty trivial, and that most of the no-mod scripts in SL are replacable with better scripts you can get for free on the Wiki, in the Forums, or in products in Yadni's Junkyard... most of them shouldn't be no-mod. I kind of wish there was some penalty for setting even scripts (let alone things like prim objects and clothes) no-mod... and I wouldn't actually mind if it *cost money* to set "no mod" on my scripts. Almost all the ones I set no-mod are ones that do something that is a bit non-obvious AND took me more than an hour's tweaking to get right, and where I believe the script itself is a big part of the value of the product. And even then a lot of them I sell full-perm.

About the only 'little' scripts that absolutely need to be no-mod are ones containing cryptographically secure information (eg, texture or other asset keys, encryption codes, or PINs or other authentication secrets). It's amazing what people think is a "competitive advantage" though.

Either option is fine with me. However, case (b) requires no addition to permissions, no extra bytes for prims or whatever. The only checking that really is needed is when someone attempts to transfer the item out of an object; if no-copy and no-transfer is set (resulting in 'no-remove' behaviour) and a user tries to transfer it out then it will either refuse and throw up an error (if the perms are for current owner; ie you got it from someone else who set these perms) or allow it, but remove no-transfer (as a person who received it with full perms and changed next-owner perms).
It would certainly require a good deal of care to be sure it was working, but the checks are completely uneccessary anywhere other than inventory removal/transfer FROM an object, as that's the only place the perms can be set.
So that would be user removal, llGiveInventory*() calls, and llRemoteLoadScriptPin() calls that I can think of, which aren't used THAT much really, so a single extra bit-checked for better overall functionality isn't going to have any performance implications.

It requires changing every bit of code in SL that refers to the no-transfer or no-copy bits so that they don't treat no-transfer+no-copy as no-transfer or no-copy. Missing one bit of rarely used code will lead to unexplained permissions failures. Changing one bit of code the wrong way will lead to exploits. Adding an extra flag bit is MUCH safer. Trust me on this, I've been dealing with this kind of problem for longer than the word "cyberspace" has existed, and I fixed the first remote execution exploit in someone else's code back when only computer nerds asscoiated "mice" and "windows" with computers.

Not to mention there seems to be 10 unused bits between PERM_DAMAGE and PERM_RESERVED.

Came up with an alternative to this which I put onto the Jira; a 'Modify Contents' permission.

Basically this permission is set to the same as 'modify' for all existing items, so no-mod items now are no-mod-contents too, to preserve the current behaviour which apparently is the correct one (much to my dismay as it's completely stupid and counter the unix-style they seemed to be going for).
Anyway, when enabled it allows you to modify the contents of an object, what exactly you can do however is still determine by the exact settings of each item within that object.

The result is that the ability to modify an object itself (ie the prim-size etc) and the ability to modify the contents of an object would be separate and you can mix and match these for different effects.

This permission could also be applicable for things like notecards and scripts, allowing you to make the script/notecard itself modifiable, but it's contents no-mod, thus you can rename the script/notecard but not change anything inside it.