Cool VL Viewer forum http://sldev.free.fr/forum/ |
|
The @putinv command http://sldev.free.fr/forum/viewtopic.php?f=7&t=8 |
Page 3 of 3 |
Author: | Sharie Criss [ 2009-03-26 23:54:10 ] | |||||||||
Post subject: | Re: The @putinv command | |||||||||
Nope - I read it wrong.... My bad! It was Lag - uh yeah.. Lag... |
Author: | Henri Beauchamp [ 2009-04-08 11:58:10 ] | |||||||||
Post subject: | Re: The @putinv command | |||||||||
The Cool SL Viewer now implements RestrainedLife v1.16e (see the announcements forum), and @putinv specifications (still preliminary and subject to changes !) have been amended as follow:
This prevents objects given via @putinv to issue a new @putinv in a later session (since @putinv permits a given user's scripts, this permission is however still valid during the current session unless explicitly revoked or @cleared for the object which issued the first @putinv). Note however that an object given via @putinv may still try and use a relay and issue new @putinv commands via it. It therefore still does not solve the problem of open relays (relays accepting anything from anyone without warning and prompting their user). I'm therefore still undecided about @putinv... Perhaps should we remove @putinv itself altogether and only keep the #RLV redirection (but this time, the redirection would trigger the normal keep/discard/mute dialog). |
Author: | Henri Beauchamp [ 2009-04-16 16:17:03 ] |
Post subject: | Re: The @putinv command |
In RestrainedLife v1.16f (see the Announcements forum), I finally decided to get rid of @putinv itself and only kept the llGiveInventoryList(victim_id, "#RLV/~some_name", list_of_stuff) feature (but this time, the Keep/Discard/Mute dialog is always presented to the victim, just like for a normal llGiveInventoryList()). This plugs the potential security issues associated with the previous @putinv implementations and gets closer to what Marine will implement in her own patch (but this feature should still be considered a preliminary implementation). Note that the redirection to the #RLV/ folder is only active after the RestrainedLifeAllowGiveToRLV debug setting is set to TRUE (else the #RLV/~some_folder is created in the inventory root folder). |
Author: | Henri Beauchamp [ 2009-04-20 18:42:30 ] |
Post subject: | Re: The @putinv command |
Marine adopted my last implementation of the llGiveInventoryList() redirection to #RLV, with a minor change: the feature is enabled by default and may be disabled by setting the new RestrainedLifeForbidGiveToRLV debug setting to TRUE. This feature is implemented in Marine's RestrainedLife v1.16.2 (=1.16g for the Cool SL Viewer). I'm pretty sure that this new feature will boost the creativity of RestrainedLife toys makers... Thank you to Saunuk Flatley for the original idea and patch, to Marine for adopting the feature, and to everyone who participated in the discussion about it ! |
Author: | Kitty Barnett [ 2009-04-21 14:58:43 ] |
Post subject: | Re: The @putinv command |
Is there a reason why there's no optional "auto attach on accept" flag? *confuzzled* From the viewpoint of a non-attached object that wants to attach a folder it hands out: (1) in some/many cases the object might want to give out the folder regardless of whether the avie is using RLV or not (ie the latex doll transformation, RLV @attach'ing the folder is merely an added convenience, it's not essential) (2) if it wants to check for RLV it's going to have to talk to a relay - assuming there is one - issue @findfolder to check whether it exists, give the folder if it doesn't exist, poll @findfolder a few times and then finally issue @attach or give up if the folder didn't arrive within a given time-out) (3) depending on the situation any attachments in the folder would need to announce themselves on wear to let the object figure out which ones got attached and which ones didn't (any attachment point can be locked so the attach could succeed, it could only partially succeed, or it could fail altogether) or in the case of non-RLV the avie might not wear all of it You could cut out (2) entirely and get rid of the relay requirement if you're not particularly interested in whether or not the folder exists already. If you do want to check if the folder exists already, or if you're using the relay for other things anyway, then the effort is still significantly reduced (one @findfolder and either a llGiveInventoryList or an @attach and you're done without the need to poll). (Not being interested in whether the folder already exists doesn't necessarily mean being sloppy. Some people are inevitably going to want to hand out "limited use" objects that expire after a time or one use) (Increased risk from malicious objects isn't necessarily an issue; the inventory offer dialog could just use the "big scary yellow" pop-up for #RLV/~ attach-on-accept folders rather than the innocuous blue pop-up) --- Related, having the requirement/recommendation of only using @findfolder to check for existence - rather than @getinv/@getinvworn - would likely improve forward compatibility since the way it's written right now the specification implies that ~folders will always be in the root and cannot even be moved into another folder under the #RLV root without some script out there believing that the folder is not available anymore. I also know of at least one case where ~ folders will not just simply be for one session and can then be deleted, and I could imagine it being very tempting for some "communities" (ie prisons) to "force dump" a variety of folders under #RLV to ensure that everyone has a minimum of toys (or toys that the Dominants know how to use rather than having to figure out the menus for 10 different brands of gags) and/or dress folders. The one person I know currently has 50+ prims (each one representing a folder that should be under #RLV) for sale at L$0 with instructions on how to move everything into subfolders under #RLV. Everyone is/will be expected to go through that or the tp to the actual "playground" will not work. I don't even have to guess to know that she'll be using llGiveInventoryList() to dump them all under the root since it's just so much more convenient, even without a way to create a folder structure. Personally I think it's only a matter of time before an "inbox" folder for ~folders will become a necessity (and possibly the ability to create your own custom folder structure, ie: #RLV/~PlaceName/NameOfFolder vs #RLV/~PlaceName_NameOfFolder) and @findfolder would fit any/most future changes, but @getinv=<channel> to examine only the root won't. |
Author: | Henri Beauchamp [ 2009-04-21 16:23:07 ] | ||||||||||||||||||
Post subject: | Re: The @putinv command | ||||||||||||||||||
|
Author: | Kitty Barnett [ 2009-04-21 20:52:40 ] | ||||||||||||||||||||||||||||||||||||
Post subject: | Re: The @putinv command | ||||||||||||||||||||||||||||||||||||
If the user accepts the inventory offer, but refuses the relay request then the folder is still publically available under their shared root which gets you half of the way there already (particularly if the avie is under @showinv=n in which case they have an attachable folder they can't remove if they "accidentally" accepted it). Security was partially traded away the moment @putinv was retired, taking the relay out of the loop as far as preventing things from going into the shared root. The accept dialog is currently the one and only "defense"; everything else depends on "if your relay isn't on auto-accept" or "you don't walk around with your keys to your bondage gear available" or "if you remember that you accepted a folder 2 hours ago that you didn't mean to and still haven't gotten around to deleting yet" which just isn't terribly realistic. And if you had to go through a relay to get something under the shared root in the first place then "attach on accept" is a non-issue to begin with.
Again, if the relay needed to be involved then @putinv shouldn't have been retired because it would have avoided the mess altogether (no folder would ever be able to sneak into the #RLV root due to user absentmindedness like you described - if the relay is off and a folder is offered and accepted then it ends up harmless under "My Inventory").
By taking the relay out of the loop and letting any random prim offer inventory that can end up in the shared root if accepted the potential for griefing increased rather than diminish (before the risk was restricted to the narrow case of wearing an auto-accept relay and then accidently clicking "Keep" on a folder; now you have to worry that everything RLV that could be used to access shared inventory is properly secured and not publically accessible in case of accidental accepting).
(Edited to rephrase the griefing example so it's clearer what's going on) |
Author: | Henri Beauchamp [ 2009-04-22 07:36:51 ] |
Post subject: | Re: The @putinv command |
Kitty, I'm sorry but your arguments cannot stand... You make the assumption that everyone is using a relay in "auto-accept everything from everyone" mode, as well as insecure devices allowing for anyone to issue any RL command on their avatar... But what about the vast majority of the people who use RL responsibly and cautiously, and let their relay either check for trusted devices before accepting (devices pertaining to a white list of people, or pertaining to the owner of the land, etc....), or even configure it to ask them permission every time (which is the default for all relays) ? These persons will also not grant to the RL device they own permissions for everyone to browse and attach stuff in their #RLV folder. Marine designed RL so that it is not possible for any device but the ones owned by the "victim" themselves to send RL commands to their viewer (thus imposing the use of relays for device pertaining to others): there is a good reason for it, and this reason is security. If we were to allow auto-attach, then it would completely defeat this principle (since once the offer is accepted, the device is owned by the victim and can issue any RL command without further checks or permissions), bypassing any relay and any security implemented into them. I am sorry, but this is not going to happen... About @putinv, the reason why it was removed, is that its function was to make the viewer auto-accept (and at first, completely silently) the inventory offers to #RLV/. Yes, it had to go through a relay first, but since some people use relays in an insecure mode, it could be used for grieving (including by making worm-like objects propagating to all RLV users with relays in "auto-accept anything from anyone" mode). The redirection now does not need for a @putinv command, but at least the user always get warned via the Keep/Discard/Mute dialog (and in the case of a griefer sending a lot of inventory offers, that "Mute" button is also a plus....), and this whatever is the configuration of the victim's relay. The feature is simply more secure without @putinv than with it... |
Author: | Kitty Barnett [ 2009-04-22 10:22:31 ] | ||||||||||||||||||
Post subject: | Re: The @putinv command | ||||||||||||||||||
Two practical examples: 1) victim is not wearing a relay at all but they have their keys out on their RealRestraint restraints because they're looking to "play". They're talking to someone then they're offered a #RLV/~ folder from an attachment the other is wearing with "I made this and it's fun and blah blah". It's just a folder and it kind of has a weird name, but they accept it because what's the harm and they can just delete it later. Still, wearing something someone offered is risky, especially under RLV so they ask "what's that?". Meanwhile the other uses the "Outfit" plugin on their restraints and force attaches the folder that snuck under their #RLV... oops. @putinv would have kept this and any situations like it where the avie isn't wearing a relay from ever happening since without a relay there just isn't any way to get a folder under the shared root. However irresponsible you think that person was for having their keys publically available, even if they had the common sense to normally *not* wear random inventory offers, they had no choice in the matter. If you think it's farfetched, try it at any public "playground". The reason it works is because there is no "inventory offers can be dangerous under RLV" reflex. 2) victim is using a relay and is restrained on say an RLV enabled bondage cross and receives a #RLV/~whip_marks folder from an attachment. Neat! They accept it and miss that the "owned by" doesn't match the actual owner's name. Now it's a simple force dress on the bondage cross (don't ask why a bondage cross has a force dress option, the weirdest things seem to have it :p)... oops. Once again @putinv would have kept this from happening since the bondage furniture would have been the only thing that could have offered it inventory that goes under the #RLV root (the trick would have still worked but the #RLV/~whip_marks folder would have been under the "My Inventory"). If I was distracted enough I'd probably miss the "owned by" discrepancy which is your one and only clue that something is amiss. (The "attacker" could have attempted to grab the relay directly and @putinv and then offer inventory, but that would trigger a "something strange is going on here, I'm going to decline this" on either the relay, or later the inventory offer. The point here is that a trusted object - the bondage cross - is (ab)used to force attach the offered folder without raising much if any suspicion that something is amiss) --- Since I missed that the inventory offer dialog was originally suppressed on @putinv I'll agree that the current solution is better than the original, but I still don't see a good enough reason to eliminate @putinv. You can't expect people to magically become aware that inventory offers are now potentially "risky", nor expect people to catch on to very subtle clues like in 2). It also seems a bit odd to me to draw the line at one but dismiss other potential concerns. If people are expected to act responsibly then it's no more risky than what's there now, and if allowances need to be made for distraction and/or "not so responsible" behaviour the current method is wanting. In my view the fact that 1) and 2) are even possible makes the entire thing "insecure for convenience's sake" already. |
Author: | Henri Beauchamp [ 2009-04-27 22:15:44 ] |
Post subject: | Re: The @putinv command |
Sorry for the late reply, but I am extremely busy... Again, you take the very particular case of someone wearing a dangerous device, or at least in a very dangerous mode (allowing anyone to control them via RestrainedLife)... I, for one, would never allow such a thing, and even my own products only allow full control to the primary Master/Mistress (secondary Master/Mistresses got less permissions, and everyone else even less). But even in this case, I still think the current implementation is "secure" enough. The main concern was to prevent worm-like devices to spread around SL automatically via RLV users with open relays. This is now the case (since any item given has to be explicitly accepted by the victim). The cases you are describing would at worst allow to grieve one person at a time (and then they can just log off and relog with RL disabled or a normal viewer to get out of the situation). As a side note, if I were a griever, I would not rely on people having public access on their RL devices, and won't even use the new #RLV redirection: I'd rather give items to a normal folder and ask nicely to the recipient to try and wear the nice gift I made to them (this too can be done via automatic scripts: it's just a llGiveInventory() and a llInstantMessage()). Doing so will make the potential victims even less suspicious, and the device, once worn, can do all sorts of "nasty" things using RL commands... |
Page 3 of 3 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |