Permission Reforms

Here are some changes we'd like to see introduced to the Second Life permissions system. We're hoping you'll help to improve/add to what's below. Later we'll post the results on the Feature Voting Tool.

1. Please let me select multiple objects and change permissions in one go.
2. Please give me the ability to specify a friend who can change permissions on my objects, in the same way that you can currently let someone modify your objects.
3. Please give me an LL command that lets me alter next owner permissions.
4. Please give me the ability to resume full rights on any object returned to me that I have created.
5. Please let me resume full rights on any script I've created that has been transferred to someone else so that I can fix it without having to re-issue the whole product.
6. Please fix the bug that says I have insufficient permissions to view a notecard even after someone has given me mod rights.

Loki Clifton, Biscuit Carroll

we developers have been waiting WAY too long for these options. a change like this would exponentiate (hope i spelled that right) the growth of SL content!!!!! i vote yes.

There are a few caveats with this:

* I buy mod furniture, link it to a prim I created and I'll now be listed as the creator but should obviously not in any circumstance be granted full permission to the entire object

* I create a prim with a no copy texture on one face, being able to get full permission to the prim breaks the permissions on the texture

* Any number of people could have worked on the object/script since you created it, you shouldn't be able to get a full permission copy and benefit from their work just because you created the original prim/sciript

This should never have been an issue. These should have been rights of a creator from the beginning. Great job of outlining some much needed options. Thank you for this Loki.

I am sure ..nobody expects the object being returned .. would be returned with more permissions than it originally left you with.

However the server retains all the creator data in the asset server so you could filter out all the new added prims stuff and think of this as more of a back step so it would act like you was the owner again not talking about giving next owner the same "GOD" rights as the creator but restoring the creaters rights when the object is back in there hands or when given mod rights by its new owner

Good thoughts, Loki!

I'd also add a request to separate the "resell" and "give away" options. Of, failing that, an option that let's you have "resell / give away" checked, and another option to not allow the next owner to increase the price.

Regards,

-Flip

and METATAGS!! They were promised months ago, still nada. Anyways, HELL YES!! Long overdue implements. Great post Loki.

Individual prims retain their own creator data.



Ditto textures.



Yes, but if that data is stored ("last saved by...", then if I get the script back, then I have it as "next owner."

What I'd rather see is just if someone grants me mod rights and has mod rights to a script, I should be able to modify the script.
Currently if the script is full perm on next owner, written by me, given to someone else who grants me mod rights, leaves the script full perm, I can't modify it to fix bugs! Live Help (back when you could actually get a Linden) told me "this makes sense, you don't own the script, therefore you shouldn't be ablet to modify it." WTF?

Only the original creator's name is stored with scripts (or notecards for that matter) and while the OP's suggestion is useful in the quoted case, it breaks in the case where someone starts with a script created by someone else and never bothers/realizes it won't have their name as the creator.

PrimDock rezzes prims with the creator's name and not the user's name by default. Should the creator of PrimDock be able to obtain full permission builds of everyone who didn't change the default prims in the tool?

Just because something sounds useful in a certain situation, doesn't mean you shouldn't consider the wider implications, especially when everything stated can already be done indirectly.

As a landscaper I would really like to be able to transfer ownership of objects from me to my client in a nice easy way and still leave them where I put them.

At the moment I can set things to group easily but I'm still listed as the owner which is frustrating for me and the client. I know that there are ways around this (deeding officer and deed them to group, sell for $0) however they are not very satisfactory. Deeding isn't a good option for an individual who isn't part of a group and selling a whole region full full of plants could make both me and the client lose interst in living!! And actually any of the current options are cumbersome.

In general, I appreciate the positive aspect of the suggestions, but I'm not sold on them.

The economy relies on the existing setup. I, for one, would be very displeased if these changes were implemented on a whim.

Get some motivated hackers in to try to imagine all the potential use cases. If you can live with the results, go for it. As for voting: Remember, large volumes of people are not always right.

Let me play devil's advocate for a while to give you a potential glimpse of improper planning and implementation. It's nothing personal, please don't take it personally! Each one of these can potentially be mitigated by adding more code to prevent abuse of the features. This is by no means a complete list of use cases.

Specific comments to each suggestion:


Let's start by getting SL to remember all the textures I've applied before we let similar protocols forget to change some permissions shall we? Faulty protocols aside, I like this idea, as long as it does not add permissions to things you should not be able to increase the permissions for. Does it stop at the prims, or does it recursively set permissions inside contents too? And contents of contents? The manual process is a gentle one on the asset server.


a. Hand over the password why don't you! (against SL ToS btw). b. Do you trust your friend's computer to never get hacked and their SL account stolen only so that the attacker can get at your stuff without restriction? c. You actually want other people to change permissions on your items without your conscious decision to do so? d. Fall out with your friend offline and can't log on in time to remove rights before they steal all your assets with full perms claiming you gave them permission to resell the original? d. Friend takes your vendor script out and replaces it with their own modifications to your vendor, perhaps pays you once every 5 sales? Your conscious decision to do so is not included.


a. So, if you make me one script that changes permissions favorably for a particular situation, could I copy that script into something you made that you didn't want the permissions changed? Thereby gaining access to things you did not intend me to have? b. Unless maybe it's to reduce permissions and not increase them?


As covered by others in this thread. I think the moment anything is changed after you've released it the permissions should stay as they are or be reduced if you are able to, but never increased.


a. So, anyone who ever sold me anything scripted could modify the script whilst I'm not looking to make it do things I didn't sign up for when I bought it? No thanks. b. Fix your update processes. This kind of manual tweaking doesn't scale well if your customer base grows to a global population for example (it can happen very easily in SL). c. I wouldn't buy your vendors if I knew you could alter them on a whim. Can anyone say "freebies!"?


a. "The user has granted you permission to modify their objects" (something like that), doesn't include notecards and scripts or anything else. This is not a bug. b. Unless you meant permission to modify the notecard as checked in the notecard properties. The notecard original should be assigned the correct permissions and re-issued to you by that user as a conscious decision and action on their part. c. Or the possibility of notecard data not arriving at the SL client due to lag/packet loss and being erroneously reported as insufficient permissions?

Again, very sorry for the negative response to something that obviously came about through good intentions.

Good idea to discuss it with others though. I'm sure we can start talking about solutions to the above and ways they can be mitigated.

Personally, I don't mind things as they are, and would rather see voice chat released (a fundamental missing component) and stability (fixing a bunch of broken components).

I full heartedly agree with the usefulness of points 1, 4, 5, 6. I don't personally have a use for 2 and 3, but they also sound like positive changes.

I propose we strengthen the current permissions system rather than add to it. The more complicated you make it, the more exploited it becomes and the more thats apt to go wrong with it.

As it is now, with every update my heart skips a beat and I walk on needles anticipating a bug that will render the permissions system to allow objects that are not meant to be mod, copy, and/or transfer to do exactly that. *cries*

Please lets just concentrate on things that will improve the safeguards of our IP rights such as Metatags etc and lets leave well enough alone.

Lord knows the permissions system is unstable enough as it is. We could do without adding more unnecessary lines of code into it.

how about something like the INSPECT pie-option... with the permission bits listed for each prim, script and content?

That way, when we want to change a no-copy into a copy (or vice-versa) item we don't have to dig into every nook and cranny to make sure the permissions are correct.

Some ability to sell unfinished-work or parts would be nice too.

I sell you a mod/copy/transfer unfinished sofa object and textures.

You combine and texture as you like.

You can copy and transfer but are forced to choose which version
your customers will get:

( )mod, (x)copy, ( )trans OR ( )mod, ( )copy, (x) trans

I'm sure most texture sellers would like to let their textures be
used in products, but don't want them ending up in freebie boxes.

It'd be a big help.

This feature would be very useful to me. If it had a built-in time delay, it might not load the asset server too badly.

This is something that needs careful consideration, but I do agree that SL's permission system should grow as we discover more uses and more complex uses for it. We also need to remember that perms are currently inheritable and that should both be considered and worked with in any proposed change.

I have an additional idea to toss into the pot on this as well; Get rid of the mutually exclusive interaction between (copy) and (resell/transfer). Each perm should be able to be set, or unset, on your own creations. Yes, I know the system can be swizzled by sticking a reverse perm item inside the top level item and letting the perms inherit to the top level, but it shouldn't be necessary.




Agreed, this would be a huge help. The use of a timed update queue on the server side to handle the changes might be the answer to Adept's concern about server load.

But what about the inheritance? Let's say we have 30 cubes that we want to set to (no mod), (copy), (no xfer), but 5 of the cubes have scripts inside which are (no mod), (no copy), (transfer). Even if this option only tried to change the specifically selected object (e.g., only the cubes, not the internal scripts), inheritance creates a conflict for 5 of those cubes.

Just a thought; when the multiple perm change hits a conflict, it skips that object and goes on to the next, and when complete, deselects all the items it was able to successfully effect the change on. Items that weren't changed would remain highlighted.



Perhaps this would be part of the 'Friend' perms, but only apply to the creator of an object and the specific things that creator made, and not give the friend any rights that you didn't have.




That's just begging for trouble, griefers have enough ammunition as it is.



Restore the rights you had as the creator, yes. Since the item tracks who created it, that should be simple, and apply to interior items as well; if you didn't create the script, you have standard owner rights to it but no creator rights. If you're the scripter & owner, you have should have creator rights to both. This is predicated on you being the owner, as well as the creator.



MMmm, nope. This one is scary. I wouldn't buy any script that the creator can go in and modify even though I own it.

- Aurelius Draken

I think this only applies durring "I have permission to modify their objects," scripts inside the objects being modifyable because of that permission.

*points to the first page and the PrimDock example*

The creator of an object isn't necessarily the creator of the prims.

These are some real good suggestions indeed. Specially I would like to add abit more specific about the "1. Please let me select multiple objects and change permissions in one go." part:

As a scripter, I would like to have the possibility to change permissions of scripts inside complex objects in a more global and more intuitive way. Like for instanse, if I got a object consisting of like 30 prims, all of them got scripts in them. Then I would really like a feature to easy change the permissions of ALL the scripts within the complete object in one go, instead of having to edit each child-prim and do it manually on each script as we have to do it now.

Such a feature would make it so much more efficient to work with complex products and concept ideas. I use countless hours of work on permission settings ever day. So some of these suggestions would make it a bit easier for people to get a more efficient way of working, that I'm very sure of.

I hope linden labs takes some of these suggestions into account, and that they find a sollution to do it in a way that will not open up exploits in the process.

The suggestion we're making here is that rights revert to the creator only if the owner grants modify rights to him/her.

I would like to chime in that #1 and #2 are an absolute must. The other ones are more iffy.

Specifically, for #1, rather than the flat out "select/change all", I like the idea of expanding the "INSPECT" pie-option as well. If I could have that Inspect option drop down a full list of everything selected included recursion of objects/scripts/textures and three columns to the side for each permission setting... Then you could do a button at the top of each column for a "check all". This way you have a complete view into what you're about to do, in order to avoid potential mistakes of forgetfulness.

#2 would be such a major improvement. I work with my RL spouse in SL and really all she wants to do is build. There isn't a day that goes by where she laments that she would just love to build stuff and give it to me to package and sell (and do permissions clean up even, but that might be asking too much)... She has so much work sitting idol that we need to get on the market but it never gets released because of this very issue. Yes, there are the possibilities of abuse, but it's the same in real life. You always have to be careful with who you trust, and this is akin to trusting someone with Power of Attorney. If you preface the allowance severely enough before letting someone commit it (like the warnings when you're going to buy land and break tier), this should help prevent most people from giving this permission carelessly... you know, you could even put a time limiter on it so the person has to consciously renew it every day/week/month/etc... that they want to allow it.

Thanks for bringing these items out for discussion!

Zee