Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2017-05-23 10:43:36



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

Joined: 2009-03-25 20:55:42
Posts: 4
Reply with quote
Satomi Ahn wrote:
Sorry, I wasn't clear.
It is not renaming, I suggested, but really moving. ("Latex Doll"->".old/Latex Doll")


Nope - I read it wrong.... My bad! It was Lag - uh yeah.. Lag...


2009-03-26 23:54:10
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
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:

  • @putinv is purposely rejected and fails when invoked by an attached object held inside a #RLV sub-folder which names starts with a tilde.
  • The llGiveInventoryList() redirection to #RLV is now only accomplished when the sub-folder name starts with a tilde. I.e., after a successful @putinv, you must use:
    Code:
    llGiveInventoryList(victim_id, "#RLV/~whatever_subfolder_name", list_of_stuff);

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).


2009-04-08 11:58:10
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
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).


2009-04-16 16:17:03
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
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... :D

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 !


2009-04-20 18:42:30
Profile WWW

Joined: 2009-03-26 14:28:01
Posts: 4
Reply with quote
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.


2009-04-21 14:58:43
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
Kitty Barnett wrote:
Is there a reason why there's no optional "auto attach on accept" flag? *confuzzled*
I spoke with Marine about it and we quickly came to the conclusion it was dangerous, for the following reasons:
  • Users may not notice that the items are given to their #RLV folder (do you always read the text in the dialogs ? Isn't your index finger sometimes reacting faster and clicking "Keep" before your brain actually registers the actual consequences ? Did you never had several blue dialogs piled on together and clicked on their "Keep" buttons repeatedly without reading ?). Forcing the device giving the folder to use a relay to attach the objects adds a new layer of security (and a chance for the user to decide that finally, no, they don't want to interact with the device).
  • A RLV user could want not to be bothered with RestrainedLife devices at a particular moment (when they are in a RP for example, and do not want to be captured or Restrained spuriously and accidentally by a RL device). In this case, they will either turn off the relay or remove it, but entranced with their RP, they might still just press "Keep" on the inventory offer without noticing, and then end up being automatically restrained while they did not want it.
  • A RLV device, even on a trusted playground, might be operated by a third person trying to grieve you. A new !who meta command was recently added to the specs of the relays, so to identify such situations. Bypassing the relays with an auto-attach feature also bypasses all the securities the relays can offer.
  • Some attachments are a "permanent" part of your Av (think of the ears and tail of a neko, for example, or simply of your avatar's genitals), and yet are not RestrainedLife-locked: allowing to auto-attach, means you risk having such attachments kicked off and replaced with other, locked attachments, ruining your AV till you get freed or relog with a normal viewer. Good relays allow you to blacklist some commands you don't want to be imposed on your AV (the neko of our example will want to blacklist commands dealing with the attachment points for their genitals, tail and ears): this is not possible with auto-attach.

Quote:
(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)
I'm not even sure it is possible, but it would be a bad idea anyway: imagine what would happen if a user who got used to click "Grant" on the "big scary yellow" dialog to grant inventory offers to the #RLV folder, thus making it a quasi-automatic reaction, suddenly clicks by mistake for a true money transfer permission from a griefer (the griefer could even use #RLV/~somefolder in the name of their object to try and lure the user), thinking it was just another #RLV offer: I don't know for you, but I am personally not ready to deal with the money losses and complaints from these users about this "feature".


2009-04-21 16:23:07
Profile WWW

Joined: 2009-03-26 14:28:01
Posts: 4
Reply with quote
Henri Beauchamp wrote:
Users may not notice that the items are given to their #RLV folder (do you always read the text in the dialogs ? Isn't your index finger sometimes reacting faster and clicking "Keep" before your brain actually registers the actual consequences ? Did you never had several blue dialogs piled on together and clicked on their "Keep" buttons repeatedly without reading ?). Forcing the device giving the folder to use a relay to attach the objects adds a new layer of security (and a chance for the user to decide that finally, no, they don't want to interact with the device).
In my opinion it's getting the folder under their shared root that's the hardest; getting a folder attached under the shared root once it's there is much easier (ie get them on some bondage furniture with inventory attaching feature, get the keys to their bondage gear, etc).

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.

Henri Beauchamp wrote:
A RLV user could want not to be bothered with RestrainedLife devices at a particular moment (when they are in a RP for example, and do not want to be captured or Restrained spuriously and accidentally by a RL device). In this case, they will either turn off the relay or remove it, but entranced with their RP, they might still just press "Keep" on the inventory offer without noticing, and then end up being automatically restrained while they did not want it.
If they're so distracted then they're not going to remember that they absentmindedly accepted a folder that is now publically available under their #RLV and is attachable until they stumble onto it at some indetermined time in the future (or find out the wrong way because someone force-attaches it on them at which point it's too late).

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").

Henri Beauchamp wrote:
A RLV device, even on a trusted playground, might be operated by a third person trying to grieve you. A new !who meta command was recently added to the specs of the relays, so to identify such situations. Bypassing the relays with an auto-attach feature also bypasses all the securities the relays can offer.
Griefer wears an attachment that gives #RLV/~obnoxious_object while it's named after the object the victim is sitting on (or in in the case of a cage) and only "owned by..." name would differ (very few people would notice that discrepancy). Victim presses accept, putting it in their #RLV and then the griefer can check their bondage gear (ie RealRestraint collar with keys on it or some doll keys with "forced dress accessible to all" functionality will allow anyone to silently force-attach anything without the victim ever getting any visible feedback on who's doing it or even that they're doing anything; etc).

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).

Henri Beauchamp wrote:
Some attachments are a "permanent" part of your Av (think of the ears and tail of a neko, for example, or simply of your avatar's genitals), and yet are not RestrainedLife-locked: allowing to auto-attach, means you risk having such attachments kicked off and replaced with other, locked attachments, ruining your AV till you get freed or relog with a normal viewer. Good relays allow you to blacklist some commands you don't want to be imposed on your AV (the neko of our example will want to blacklist commands dealing with the attachment points for their genitals, tail and ears): this is not possible with auto-attach.
The granularity you describe isn't possible through script though: a relay could decide to not allow @attach*:/~*=force, but then it's an "all or nothing" situation because it has no way of knowing whether the given folder contains attachments on (left ear) and/or (right ear) or not so it has to refuse an @attach on any and all script offered folders, or in essence breaking the feature altogether as far as relay consumers are concerned.

(Edited to rephrase the griefing example so it's clearer what's going on)


2009-04-21 20:52:40
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
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...


2009-04-22 07:36:51
Profile WWW

Joined: 2009-03-26 14:28:01
Posts: 4
Reply with quote
Henri Beauchamp wrote:
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.
Spend 5 minutes in a place like Stonehaven and see how "responsible" some people are :p.

Henri Beauchamp wrote:
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...
That was a misunderstanding on my part it seems; my assumption was always @putinv through a relay (subject to whatever warning levels the relay itself implements) *and* the inventory offer dialog.

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.


2009-04-22 10:22:31
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
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...


2009-04-27 22:15:44
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 30 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 1 guest


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.