Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 19:11:32



Reply to topic  [ 30 posts ]  Go to page 1, 2, 3  Next
The @putinv command 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Let's continue here the discussion which was started in the old thread on SL's forum (do not post over there any more, please).

I did read all the suggestions in the old thread, but I'm reluctant to restrict too much the ability for objects given via @putinv to issue RLV @commands (after all, what fun would it be at all if such objects could not auto-lock themselves and/or use the other RestrainedLife features ?)...

Therefore, my plans for @putinv are for now as follow:

llGiveInventoryList(victim_id, "#RLV/subfolder", list_of_stuff) would put the list_of_stuff objects into a folder named "~subfolder" (instead of "subfolder") inside the #RLV folder. The command parser would also be slightly modified so that RLV @commands issued by objects held inside #RLV sub-folders which name start with "~" are filtered (i.e. @commands deemed "dangerous" will be ignored for these objects).

For now, the only "dangerous" @command would be @putinv itself... I.e. @putinv could not be issued from any object given to the victim via @putinv. This would make it much more difficult to create worms-like scripted objects (even if such worms would not be able to spread without RLV users wearing "accept anything from anyone" relays around).

Any thought or comment ?


2009-03-18 09:48:27
Profile WWW

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Yes, one thought, for now:
I would prefer not to have all those forced-put inventory folders directly in #RLV, as it will pollute the #RLV listing when accessed from a menu (as it often is!).
Sure, the scripts could also filter folders starting with "~", but
1 - we don't really want to make those unreachable from menus,
2 - and this would require to update all the old scripts.

Why not forcing everything into /#RLV/#forced/, or #RLV/#sandbox/ or something like this?

Blocking rlv commands seems also a reasonnable thing. As Kitty said, if RLV commands are needed, they could come from the device that issued @putinv in the first place.
All commands, except one: @detach=n... and that one could be useful.

What about extending @detach such that it works like @remoutfit?
(i.e: @detach:attachment_point=n would lock the attachment at the targeted location)
I don't know why it isn't already in the API. This would make a lot of other things easier too.


2009-03-18 11:57:58
Profile

Joined: 2009-03-18 12:27:58
Posts: 2
Reply with quote
I think that it would not be so easy to filter RLV commands that came from attachments inside of #RLV folder. Yes, you can try to filter llOwnerSay, but what will prevent that attachment to issue any RLV command via existing relay? Moreover, attached object sure will be owned by user himself, so most relays won't bring any confirmation at all.


2009-03-18 12:50:50
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Satomi Ahn wrote:
Yes, one thought, for now:
I would prefer not to have all those forced-put inventory folders directly in #RLV, as it will pollute the #RLV listing when accessed from a menu (as it often is!).
Sure, the scripts could also filter folders starting with "~", but
.../...
2 - and this would require to update all the old scripts.

Not if the @commands for listing the folders in #RLV omit the folders starting with "~" (like they do for "hidden" folders)...

Quote:
1 - we don't really want to make those unreachable from menus,

Why not ?... You just asked for the contrary ("as it will pollute the #RLV listing")...
Plus, if the victim wishes to have the items given to them via @putinv listed by the other commands dealing with #RLV, they can simply remove the tilde character from the folder name...

Quote:
Why not forcing everything into /#RLV/#forced/, or #RLV/#sandbox/ or something like this?

Then your objection about not wanting to pollute the #RLV listing in menus still stands...
You got me confused. You want one thing and its opposite at the same time...

Quote:
Blocking rlv commands seems also a reasonnable thing. As Kitty said, if RLV commands are needed, they could come from the device that issued @putinv in the first place.

I'm strongly opposed to block all RLV commands !!!

This would make the @putinv feature pretty useless. Think about a dollification device, for example: when sitting on it, it gives you a full doll outfit with functional RLV attachments (for example: a ring gag, lockable and muting you). With your solution, once you stand up from the device, everything stops working (i.e. you can detach the gag and/or speak through it) and all the true fun is gone !

It's a no-no as far as I am concerned.

Beside, the true security concerns about @putinv are not really what type of restriction it can force on your avatar (after all, any device accessed via a relay can already do the same things, and if it bothers you, you can still relog with a RL disabled viewer to get off or remove the device), but more about potential worm or virus-like behaviour of malicious items. This behaviour can be obtained by designing a device which attempts to issue @putinv to other victims around you once it got attached to you. Preventing other RLV commands than @putinv itself to be executed from #RLV/~folders would not prevent this to happen, thus why I suggested to restrict @putinv only.

Even with my solution, there is still the possibility (on build-ok parcels) for the worm/virus to rez a child object in-world which in turn would try to @putinv on other unsuspecting victims (they still must have their relay in "auto accept anything from anyone" mode for this to work, of course).

The next step to harden the security would therefore to either:

- not implement @putinv itself (but keeping the redirection of stuff given via llGiveInventoryList(victim, "#RLV/subfolder", stuff) to a subfolder of #RLV (which can't normally be done with llGiveInventoryList() in normal viewers), so that the victim will get the blue dialog to accept/deny/mute the object giving you the folder (but then many people will complain that a lot of fun is gone for them).

- restrict @putinv to devices you are currently sitting onto: this cannot be done without changing the current syntax of the @putinv command, but since the specifications are still preliminary ones, this is quite feasible. Of course, a device (in our hypothesis above, the rezzed child of the worm device) could still force-sit you and then @putinv, but you would notice this spurious force-sitting and could take action to get rid of the worm.

Henri.


2009-03-18 13:05:48
Profile WWW

Joined: 2009-03-18 12:27:58
Posts: 2
Reply with quote
Quote:
- not implement @putinv itself (but keeping the redirection of stuff given via llGiveInventoryList(victim, "#RLV/subfolder", stuff) to a subfolder of #RLV (which can't normally be done with llGiveInventoryList() in normal viewers), so that the victim will get the blue dialog to accept/deny/mute the object giving you the folder (but then many people will complain that a lot of fun is gone for them).

As I mentioned earlier in previous thread, there's a way around. It's to remember user's choice. So we need to have list of allowed av's similar to mute list.

Quote:
Beside, the true security concerns about @putinv are not really what type of restriction it can force on your avatar (after all, any device accessed via a relay can already do the same things, and if it bothers you, you can still relog with a RL disabled viewer to get off or remove the device), but more about potential worm or virus-like behaviour of malicious items. This behaviour can be obtained by designing a device which attempts to issue @putinv to other victims around you once it got attached to you. Preventing other RLV commands than @putinv itself to be executed from #RLV/~folders would not prevent this to happen, thus why I suggested to restrict @putinv only.

I think that it's not possible to filter llSay calls of "@putinv" command. Scripts are executed on server side, so there's no way to intercept interaction of malicious attachment and victim's relay.


2009-03-18 13:47:57
Profile

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Quote:
You got me confused. You want one thing and its opposite at the same time...
No, no, no... I am not asking for one thing and the opposite!
If folders are sent into a common subfolder, they do not pollute the root. You get to see those only if you enter the subfolder. If you like metaphors: if every trash is in the trash bin, then it does not "pollute" your room, but you can still have a look into it.

Coming back to the "~" prefix, so it would mean that those folders can be used by @attach/@attachall/..., but not by @getinv and @getinvworn? Well, I imagine this is possible... but I find this a bit unconsistant (and anyway it is also possible to tell the viewer to hide "/#RLV/#forced").
My point is I don't really see what is the advantage of the "~" prefix, compared to the use of a subfolder. Even when you browse with your inventory window, a subfolder makes things easier because you can fold it.

Quote:
I'm strongly opposed to block all RLV commands !!!

Sorry for this thing about blocking commands: I just missed the fact that you only wanted to block @putinv. Hm, yes, as you stated, this would not prevent worms on every parcel. On the other hand, I cannot see a scenario where such an attachment would really need to send "@putinv". (Or yes, I see one: if you want to simulate a contagious effect in your RP! But how can you make a difference between a legitimate/IC epidemy, and a griefing worm epidemy?)
Anyway, Saunuk's objection remains valid: if the object is yours, it will be authed by most relays.

You know, I am not in favor of blocking llOwnerSay rlv commands. I am quite neutral about it (as long as they don't help spreading worms or steal your money!). I only stated it wouldn't be an issue to block them, as they could be passed through the relay by the device that issued @putinv. But yes, there is still an issue when this device is not there anymore. Then it might be useful if the attachment can send those commands by itself.


Quote:
- not implement @putinv itself (but keeping the redirection of stuff given via llGiveInventoryList(victim, "#RLV/subfolder", stuff) to a subfolder of #RLV (which can't normally be done with llGiveInventoryList() in normal viewers), so that the victim will get the blue dialog to accept/deny/mute the object giving you the folder (but then many people will complain that a lot of fun is gone for them).

IMHO, changing the behavior of llGiveInventoryList() is really something we want! With or without @putinv, I vote for this (but I prefer we keep @putinv in some form).

Quote:
- restrict @putinv to devices you are currently sitting onto: this cannot be done without changing the current syntax of the @putinv command, but since the specifications are still preliminary ones, this is quite feasible. Of course, a device (in our hypothesis above, the rezzed child of the worm device) could still force-sit you and then @putinv, but you would notice this spurious force-sitting and could take action to get rid of the worm.

Restricting to devices you are sitting onto, is it only so that you can notice something is happening? In that case, wouldn't the message you added in RLV 1.16d be enough?
It would be a pity if a sub's owner's objects couldn't force objects into the sub's inventory.


2009-03-18 13:59:55
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Satomi Ahn wrote:
My point is I don't really see what is the advantage of the "~" prefix, compared to the use of a subfolder. Even when you browse with your inventory window, a subfolder makes things easier because you can fold it.

I think you misunderstood.

Things given via llGiveInventoryList(victim_id, "#RLV/myfolder", list_off stuff) are put into a sub-folder (currently and in our example, in the "myfolder" sub-folder inside the #RLV folder). My proposal is to automatically prefix "myfolder" name with a tilde so that the RL patch knows this was given at some point by a RL script (and perhaps during a previous session, which makes keeping track of this in variables impossible and requires a persistent "flag": here, the tilde). This way it becomes very easy (with just a couple of lines of code) to deny certain RL @commands to the objects attached from tilded such folders. This also means that the other devices in the #RLV folder will not be affected by these restrictions (since they where put there by the user themselves, they are supposed to be deemed safe by the said user).

I don't think this would "pollute" anything at all in the #RLV folder: either you get rid of ~myfolder after you are done with playing with the devices it contains, or you move these devices into your own tree for later (re)use, or you let it alone if you don't mind the tilde... Note also that the tilde will make the subfolders using it listed as the last subfolders of the #RLV folder, when sorted in alphabetical order, which only helps keeping the #RLV folder tidy and will not impair the accessibility to your own, custom folders.

Quote:
Quote:
- restrict @putinv to devices you are currently sitting onto: this cannot be done without changing the current syntax of the @putinv command, but since the specifications are still preliminary ones, this is quite feasible. Of course, a device (in our hypothesis above, the rezzed child of the worm device) could still force-sit you and then @putinv, but you would notice this spurious force-sitting and could take action to get rid of the worm.

Restricting to devices you are sitting onto, is it only so that you can notice something is happening? In that case, wouldn't the message you added in RLV 1.16d be enough?

The message is only in the chat log and does not show on the console, so while you can track back what happened, you cannot see it unless you have the chat log floater open.

Quote:
It would be a pity if a sub's owner's objects couldn't force objects into the sub's inventory.

Well, @putinv was designed with transformation devices in mind (devices the avatar "sits" onto and finds itself transformed as a result). Of course, we could imagine other uses, but they seem rather marginal to me... This said, if we adopt a new @putinv syntax, one could imagine yet another for giving permission to trusted persons... the risk is however to open new potential security issues and defeat the "@putinv when sat only" restriction...


2009-03-18 15:02:38
Profile WWW

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Is "myfolder" one fixed string?

Or are you proposing this:
Code:
#RLV
 |-~myfolder1
 |  |-piece_of_clothing
 |  \-scripted_object
 |-~myfolder2
 |   \-shape
 |-Other_shared_folder
    ...

Am I misundertanding something?

What I want is to something like this:
Code:
#RLV
 |-#Putinv
 |  |-myfolder1
 |  |  |-piece_of_clothing
 |  |  \-scripted_object
 |  \-myfolder2
 |     \-shape
 |-Other_shared_folder
    ...

(and the command would be: llGiveInventory(victim_id, "#RLV/#Putinv/myfolder1", list_of_stuff))

This looks way better to me... but maybe is it a matter of taste?
Then, the RL patch would, instead of checking the "~" prefix, verify if the folder is inside #Putinv, as it would mean that this folder has been put into your inventory by some script.
I am not sure whether you did not understand my proposal or if you don't like it for some reason (which I don't understand yet^^).

Coming back to the use cases of @putinv.
I also see it as a way to transform the target. But I am more into witchcraft and magic wands than into scary high-tech devices you would put your victim into for achieving a transformation process. And who knows what would other users do with this command?


2009-03-18 15:51:30
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Satomi Ahn wrote:
Is "myfolder" one fixed string?

Of course not, this was just an example..

Quote:
Or are you proposing this:
Code:
#RLV
 |-~myfolder1
 |  |-piece_of_clothing
 |  \-scripted_object
 |-~myfolder2
 |   \-shape
 |-Other_shared_folder
    ...


Actually, and as I explained in my last post, the tilded folders would appear last in the inventory, like so:
Code:
RLV
 |-Other_shared_folder
 |   ...
 |-~myfolder1
 |  |-piece_of_clothing
 |  \-scripted_object
 |-~myfolder2
     \-shape
 


Quote:
What I want is to something like this:
Code:
#RLV
 |-#Putinv
 |  |-myfolder1
 |  |  |-piece_of_clothing
 |  |  \-scripted_object
 |  \-myfolder2
 |     \-shape
 |-Other_shared_folder
    ...

(and the command would be: llGiveInventory(victim_id, "#RLV/#Putinv/myfolder1", list_of_stuff))

This looks way better to me... but maybe is it a matter of taste?

Do not forget that attaching items in second level subfolders is only supported since RL v1.13 and fully implemented (with proper recursion) since v1.15.
Using your solution means items given via @putinv will not be accessible from "old" RestrainedLife devices (not that old actually: only a few months old)...

Plus, it means that you won't notice at the first glance by looking into #RLV that something new was given to you: you would have to unfold the #putinv folder first...

Finally, I doubt many users will keep a lot of @putinv-given folders in their #RLV tree: they will either get rid of them once done with the fun, or will move them into their own tree/outfits, so having 1 or 2 ~folders in #RLV does not really deserve creating a new sub-folder level just for them...

Quote:
Then, the RL patch would, instead of checking the "~" prefix, verify if the folder is inside #Putinv, as it would mean that this folder has been put into your inventory by some script.
I am not sure whether you did not understand my proposal or if you don't like it for some reason (which I don't understand yet^^).

Well, I definitely don't like it... :-P

Quote:
Coming back to the use cases of @putinv.
I also see it as a way to transform the target. But I am more into witchcraft and magic wands than into scary high-tech devices you would put your victim into for achieving a transformation process. And who knows what would other users do with this command?

I don't believe in magic (or Santa Claus, or any god...), but I do believe in science. :D

This said, your use would definitely be legitimate. It simply makes it harder to find a way to plug the security hole represented by the use of @putinv in conjunction with relays in "auto accept anything from anyone" mode...


2009-03-18 16:57:35
Profile WWW

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
I am lost here. Are you saying you want to be compatible with versions of RLV that do not support @putinv in the first place?


Last edited by Satomi Ahn on 2009-03-18 17:08:20, edited 1 time in total.



2009-03-18 17:01:06
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 30 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.