I've made some progress on the viewer and am about to settle a big gripe of mine since the beginning : the ability to issue commands through object Instant Messages as well as llOwnerSay calls. But first please check the previous blog post for I have edited it to show the advancement of the "not done yet" features for the time being.
Back to task IMs. I am posting about it here and now because I want to extend the capabilities of the viewer to cages and furnitures, without the hassle of a object that the user must wear to relay commands from objects around that they don't own. For instance, you step into a cage, and if you're using the viewer it closes and prevents you from teleporting out. Without support for object IMs the user would have to wear a special attachment that would llOwnerSay everything the cage says, provided it's allowed to etc. Instead of this I want to execute IM commands very much like llOwnerSay commands. It would be so easier for content creators and users.
But it would be so easier for a griefer to take advantage of your vulnerability too ! That's why I have thought about a very tight rule to allow/deny IM commands. Let me show you its pseudocode.
IF I am accepting IM commands (off by default I think)
AND owner is not muted
AND object is not muted
AND object is in the same sim
AND object is close enough (to be determined... 20 m ?)
AND command is not "force remove outfit"
THEN
.. IF object is owned by me
.. OR object is owned by a friend who can map me
.. OR object is in the same group than the parcel I'm on
.. THEN
.... execute command
.. END IF
END IF
This way there is no need to maintain an internal list of names of the people/objects allowed to control you, as it is managed by the actual friends list. And it is persistent across sessions and installations as well. Less hassle for the user and for me, more clarity for the user. Keep in mind that it doesn't prevent your viewer from being screwed until you relog, so you will have to use the Mute List against malicious users. There is no way around that unless you keep "accept IM commands" turned off. Basically if you're in a "allow cages to keep me prisoner" mode, expect to be more vulnerable.
The critical part is the double OR : either owned by a friend who can see me on the map so that discriminates a lot and still sticks to the relationship between an owner and their subs, or set to the same group than the parcel you're on (not the one the object is on, or you'd have rogue parcels with objects griefing people around) to allow public cages to keep you in (I'm thinking of Deitide, Stonehaven, Bondage Ranch, Bondage Playground...).
I would like to hear your comments about this rule (constructive ones please), knowing that I've already brainstormed a little so I think it will pretty much look like this in the code. But I would like to hear about potential loopholes, exploits, methods I have overlooked and such. I'm asking for your advices because I consider this to be VERY IMPORTANT as it is likely to be used by many content creators soon.
Thank you for your help !
Marine
Subscribe to:
Post Comments (Atom)
Posts
10 comments:
Rather than 'object is in the same group as the parcel I'm on', I wonder if 'object is owned by the parcel I'm on' or 'object is owned by the same group as I have active' would be a better discriminator.
If a parcel has object create permissions turned on, it would be possible for someone to drop a griefing object, and if you add in open group membership, setting the group on the item isn't a problem. To deed an object to a group requires that the person be a member of the group administration, and I don't think most groups give that permission out lightly.
People are walking around and send "@version" to anybody in range. How can you assure that i dont recieve a dozent of IMs everytime i am in a cage and NOT using the RR Viewer ?
Ariel : Thank you for pointing that out and yes you're absolutely right about Deeded Objects, it is even more secure than my initial solution. However Deeding an object is not something to do lightly because some LSL functions cease to work, and the object does not belong to its real owner anymore, but to the group. So I think owners of public places would be a bit reluctant to do that.
Technically I don't even know how to use groups for this check so I might very well switch to "object owned by parcel owner and you're on the same parcel yourself" or something like that.
Anonymous : I don't think I have any way to stop people from sending you bogus IMs, especially if you're using the regular viewer. I'm not even sure what your question is. If you're using the regular viewer then you will see "@version" messages like the rest, and I'm not going to remove that functionality from my viewer just because some people are dorks, sorry.
Sorry Marine... thats not what i wanted to say. Until now ONLY PEOPLE send IMs to me to check if i am using the viewer. With your future plans every single object in the world could start to send IMs to find out if there`s something on the client side. Using the 1.12 items without the viewer is already very frustrating because you recieve a bunch of chatspam - of course i dont have to use the items. if every cage or similar toys start to talk to me to check if they have the right to do something........ (i dont want to imagine that).
Please dont misunderstand me : I am using the viewer most times and love your work. But i am also using windlight and I can choose if i want to recieve the spam from worn item - if i simply detach them. But i cant affect inworld items unless i mute them
I think the concern anonymous is mentioning, is your screen being filled with @xxxx messages whenever you walk into a cage using the regular viewer.
But this is already similar now if you use attachments that send RL commands...
imho, it's the responsability of the script writer to let her script check what viewer the subject is using and send the other @xxxx messages or not, as a matter of kindness to those who don't use the RL viewer.
Oh, another question just comes up: what if the object sending the IM is actually an avatar/agent? Will the viewer accept all commands from persons? If so, will you make sure they have to be in the friends list and allowed to map?
Also: will different objects be able to overrule each others commands? Like if I step through a door that prevents me to TP, will stepping through another door be able to allow me to tp again?
What about asking for permission once when receiving IM Commands from an unknown object?
Maybe you can remember the given permission for some time, but this could ensure you won't be troubled by griefers.
Nevertheless:
I think the best option would be a list of owners with permission to send you IM commands through objects.
All you need to do is to save that names somewhere in a xml-file or similiar (maybe simple txt-file),so that you even can reinstall or uninstall the viewer and replace it with a new one and keep that list.
I do not think that list would be too large + the user could maintain that list and put names on it or remove names from it on his own.
So those who run Sim like deitide or stonehaven won't get 234 requests for being added as owner or friend per day.
Group related permissions are indeed a problem, because you only have 25 Groups in SL and in many cases the parcel owner is not the one who runs the cage, this could be any member of the group on the parcel with permission to build there...
Just my 2 cents
Anonymous : sure sure. Actually 1.12 is shipped with the RL scripts inside, but it's really done the same way people did with 1.11, so you can always remove the scripts. I have to make my mea culpa over this though, I should have added an automatic version checking but didn't find the time to either code it or test it. I will in the near future. So sorry about the spam, our code monkeys are working on it ^_^
As for automatic version checking through object IMs... I don't see what I could do against it for people using the normal viewer or Windlight. If there was an atomic and automatic way to check (from, say, a data bundled in the avatar), I would. But unfortunately there is none that I know of. Cages that are compatible with the RL viewer are bound to ask you whether you're using it or not, one way or another.
Danii : You're right it's the responsibility of the scripter, not mine, to not spam people. As for avatar IMs, no only object IMs will be checked (it would be a mess otherwise). When I mentioned the friends list I was meaning "to check the owner of the object trying to command you is a friend of yours". And different objects spawn independent rules : ie if one of them prevents you from tping, none will ever be able to overcome that restriction until the first object revokes it (or disappears from your surroundings, as my garbage collector works well now).
Shirlee : I want to avoid fiddling with external files as I only ship the executable. Nicholaz follows the same policy and I think it's a sane one. The friends list, or actually the subset of your friends that you've allowed to see you on the map, *is* the list you're suggesting, and it's maintained server-side. You're talking about Deitide but that's precisely the reason why the second "OR" exists : to keep the owner's friends list from exploding ^_^
Do I understand it right that whatever restriction imposed will only last as long as you're near the object that imposed it?
And will this also be the case for attachments?
So you will be well again if you walk away from the object? In case you are able to walk away of course ;-)
Yes Danii that's pretty much it. The garbage collector removes all the restrictions issued by objects that are not around you anymore (unrezzed, or in another sim, but they still can be far), and the IM commands are restricted to 20 meters. I don't remove rules if the object goes farther than that for a simple reason : some prisons can be huge and I don't want to force them to use "repeaters" to constantly refresh the restrictions put on their prisoners.
Checking if an item is group owned is simple - just check if the UUID of the owner is the same as the UUID of the group.
I think the only function of any importance that is disabled for group owned objects is llGiveMoney. I haven't done any testing of llGiveInventoryList, and someone probably should (the lslwiki says it doesn't work for group owned objects, but the LL wiki doesn't note any such restriction). A different concern with the idea of making objects group owned is if furniture is Copy/No trans - but I think most furniture is sold Trans/no copy.
If it's decided to make the behavior switchable, I would argue that it should be controllable by llOwnerSay messages.
One other thing to consider might be trying to make the permissions more granular, and also adding a preferences tab. Order of precedence would be Deny (via script), Allow (via script), Allow/Deny (via preference pane).
Sources (as discussed thus far) would be self (It probably could be argued that this should be hard-wired on), Maping friend, same group as parcel on, owned by owner of parcel on (not all parcels are group owned after all), owned by group active, owned by user/group X, same group as X, and open (This would be off by default, but someone might want this).
The use of things like 'owned by user x' is that some people may have given mapping permissions to people other than their owner (like a sibling).
Actions which would could be allowed/denied would naturally be all restrictions except granting permissions for IM actions. Adding/removal of exceptions would be limited by the permissions of the restriction the exception is being made to.
--Ariel Moonsoo
Post a Comment