llAttachToAvatarTemp and RLV

[Marine Kelley]

Hi,

As stated in my blog today, I think it is best for the RLV to ignore all command received from a temporary attachment. It would be a real loophole for a griefer to use, with no real value added for regular uses, since such an attachment will be destroyed when detached or when logging off.

I could be wrong though, so if you think it is important to let a temporary attachment issue RLV commands, feel free to discuss it here.

Marine

[Marine Kelley]

The address of my blog post is here : http://realrestraint.blogspot.fr/2012/08/about-temporary-attachments-and-rlv.html

[Lance Corrimal]

I vote for no RLV commands from temporary attachments. Maybe even stronger, having a temp attachment tacked onto your avatar should temporarily suspend all RLV...

[Former user]

I applaud the decision not allow temporary attachments issue RLV commands -- the dangers seem to me far to outweigh any advantages, and, like Marine, I can't see any circumstances I'd want to use temporary attachments in which a relay wouldn't also be involved.

But I think Lance's suggestion is a bit extreme. It would certainly be inconvenient if, for example, my collar and other locked attachments and my locked-on layers kept on turning off simply because I was trying on temp-attached items sample items in a shop, and I'm not quite sure what it would protect me against that simply stopping temp attachments from issuing commands won't protect me from.

[Marine Kelley]

Indeed I don't see why having one temp attachment should deactivate all current restrictions, or even inhibit future restrictions while it is attached. Better just ignore whatever comes from it and not disturb other objects, I think.

[Satomi Ahn]

Blocking RLV commands from temporary attachments sounds like a logical decision. By design, RLV used to accept direct commands only from objects you own. Other objects commands need to be "filtered" (through a LSL relay for instance).

The only alternative to blocking RLV commands from temporary attachments would be to implement similar filters in the viewer as in LSL relays (but then so much for customizability!), and in this case, why limit this to attachments and don't let other foreign objects speak through llInstantMessage or llRegionSayTo?

This alternative would not be a lightweight change to RLV, so I think we want to go for Marine's proposal and just block RLV commands from temporary attachments.

Now from a technical point of view, I wonder how this can be achieved? Will the viewer need to query objects details (owner) every time a RLV command is received? Or look for the object in inventory? (considering the inventory may take ages to load!) Are there other methods to tell temporary attachments apart?

[Marine Kelley]

Yes the role of a RLV relay is to take care of all the filtering and customization, besides at the time I was struggling to find a solution to let non-owned objects send RLV commands (struggling which ended up specifying and coding a standard relay), the only other viable solution was filtering llInstantMessage() anyway, and that implied a 2-second delay on a RLV script that would issue it, it would not have been very practical (llRegionSay and llRegionSayTo appeared only later).

As for the implementation... that's the hundred dollar question. My initial plan was to check whether the attachment was part of the inventory when parsing a command, but Kitty reminded me that an owned regular attachment might not even be in the inventory while the latter is still loading.

So I hope another way to tell that an object is a temporary attachment is available, otherwise I'm screwed.

Querying the owner would be too long, it would slow the processing of the commands tenfold and overload the network, I think.

A way I could think of would be to flag an object as temporary at the moment it is attached (or at the moment the permission is given), internally to the viewer, and to check that flag upon reception of a command. That would spare the necessary lookup into the inventory.

[Coffee Dujour]

Blocking RLV from temp attachments is really solid. The problem right now is the viewer has no idea that an attachment is temporary and there is no dependable way to decide what is and isn't; This problem is not trivial. Kitty is working with LL on making detection possible but that is unlikely to deliver in the short term.

Querying owner is useless as you own temporary attachments.

Assuming all objects temporary and flagged on attachment; Clear cache, log in, lots of things attach to your avatar and issue RLV commands. All will be "flagged". Cheat out of all your legitimate RLV toys.

[Marine Kelley]

Well if there wasn't a way to distinguish a temp attachment from a regular one, I would do this :

- Receive a permission to attach request from an object rezzed in-world.

- Is this request special for a temp attach object, or is it the regular attach permission ? If the former, add the UUID of its root prim to an internal list. (*)

- When an attachment sends a RLV command, look up the UUID of its root prim in our internal list. If it is present, then it is temporary and we ignore it (the list should always be very small if we garbage-collect it properly).

(*) If there is no way to distinguish the permission request between a regular object and a temporary attachment one, then it gets harder, we need to request its owner and that is an asynchronous request. But the rest of the algorithm stands, and won't slow down RLV commands by looking up the owner every time, only when the permission is requested.

[Former user]

It's not enough to simply block RLV commands. The temporary attachment could be scripted to do anything, and that anything might not always be benign.

[Former user]

I ask this as someone who knows nothing about how viewers work under the hood, so please forgive me if it's a stupid question -- how easy would it be for the viewer to treat attachments differently if you've only just logged in from the way it treats them normally, and, if it can do that, would it help at all?

Personally, I don't see cheating out of things as a huge problem. If I want to cheat out of something, and don't mind relogging, then I can do easily enough anyway.

[Former user]

As I understand it, the temporary attachment does not last over a relog - the problem is what it can do before you log off; particularly as there is nothing in inventory to indicate that you have a temporary attachment on.

[Marine Kelley]

Chloe :

I agree with you, temporary attachments without any control on the part of the user is a bad idea, a can of worms. A malicious attachment could attach on you and make it hard for you to remove it, while griefing you and people around until you find out your only choice is to log off.

But it is a matter that has nothing to do with RLV :p

[Former user]

Marine:

I 100% agree with you, I am very concerned about malicious attachments that have nothing to do with RLV but can be malicious in their own right.

LL have opened a huge can of worms with llAttachToAvatarTemp - I can imagine some very evil attachments that would be hard to eradicate.

That makes it go beyond just ignoring RLV commands from the temporary - to be honest, RLV commands worry me less than the general griefing opportunities.

[Marine Kelley]

Well it's worse than I thought. A brief test yesterday with my current viewer, not at all tailored to support temporary attachments :

• Used my alt to create a box, in which I put a simple script which would make it temp-attach to someone when touched by them. Unlogged my alt.
• Went there with my main avatar, touched the box.
• I got a permission request for attaching, which is EXACTLY the same as the one sent by an object owned by you, except this one wasn't owned by me but by my alt.
• I granted the request, the box attached itself to my head.
• No trace of this item anywhere in my inventory or in my Appearance panel. It was on my head (or rather my head was in it), I could see it on my screen, but short of right-clicking on it there wasn't any way I could access it.
• I didn't try it, but I was told that this object was de facto "owned by me" and could send me llOwnerSay() messages, hence RLV commands.
• I detached the box by right-clicking on it and selecting "Detach", and it was gone.

Scary experience, because although my viewer knows whether the object is owned by me when asking for permission, nothing tells me the object that attaches to me will have its UUID (contrary to what I said yesterday, but I didn't know at that time), so this information is not going to be very useful. Since the viewer has otherwise no way of telling a temporary attachment from a regular one, and since the inventory may not be fully downloaded (especially for creeps like me with 60k items worth of inventory), checking the presence of this item in the inventory is not reliable, and slow.

I have no doubt that at some point, LL will give the viewer a way to manage temporary attachments. Because nothing tells me the object that attaches to me will not become invisible and very small, and if I have no way to know where it is, or even if it is there, or how many of them have attached to me, a lot of bad things could happen, and I'm not only talking about RLV. For example, a griefer could use that kind of trick to force another avatar (you) to grief a sim (spamming, lagging, or even hacking into external websites), you wouldn't even know how to stop it unless by logging off or removing ALL attachments (does it even kick temporary ones off ? I'm not sure). And if you are a RLV user, the second option may not even be possible if the object locks itself on you.

In conclusion, I see only one reliable way to prevent this kind of issues : to NEVER accept any attachment request coming from an object you don't know and that you don't own. I will see in the RLV to prevent @acceptpermissions from automatically accepting attach permissions coming from objects you don't own, for now.

It sucks. This feature has been implemented in the worst possible way, by not giving the viewer any information.

[Jeroen Wenting]

It can get worse, Marine. Say a temp attachment is trying to force itself upon you, its name set to RealRestraint_HUD (nothing preventing a griefer from using that name, is there?). The popup you'd get would be identical to the one you'd get for a real RR HUD being rezzed by say your blindfold or Vixen cuffs. Now imagine that thing sending RLV commands (as you say, it can use llOwnerSay() and you wouldn't be able to easily tell it came from a temp attachment) blocking your windlight, tps, etc. And who knows, it might even (not RLV related) be able to issue unfiltered llTransferLindenDollars commands, emptying your L$ balance to the account of its creator.

[Marine Kelley]

Agreed. Try not to give griefers even more ideas though :p

[Marine Kelley]

A little update about the implementation :

So far there is absolutely no technical way to distinguish a temporary attachment from a regular one, once you are wearing it. Granted, a temp one will not show up in the inventory, but neither will a regular one if the inventory has not loaded fully, so this is not a good way to tell one from the other.

Likewise, nothing says that the object requesting permission to attach is the one that will attach (this is likely a "feature" but since it is decided server-side, I can't do anything about it).

I cannot prevent an object from attaching (or kick one that did) if it has not received permission either, because there are so many ways of attaching an object and the viewer does not know whether an object has been attached following a user input or by the sim itself.

All this to say, the two solutions I thought of at first (checking the presence in the inventory and checking the presence in the list of objects that have requested permission) are not going to work, because we have so little information. The only information we have to tell a temp attachment from a regular one is the name of the owner when requesting permission to attach. That's all, and that's not enough to protect the user in a satisfactory way.

So for now I have only one countermeasure : to prevent an object not owned by you from benefiting from the @acceptpermission RLV command. That way you will always see the box requesting your permission if the object if not owned by you, and you will see its owner on the dialog box.

Now, I have no doubt that sooner or later we'll have a UI or some other way to manage temporary attachments, because the potential for griefing is too big. There are so many nasty ways of abusing the system and so many nasty things to do once you have successfully attached an object on another avatar, that I can't think of LL keeping things the way they are. This means that sooner or later we'll have a way to keep a temp attachment from sending RLV commands.

But for now, protecting from abusing @acceptpermission is the only thing I can do.

I've been working on it a little this weekend, on the latest v-d (including pathfinding and all), I'll keep testing before releasing 2.8.3.4 this week.

[Sei Lisa]

Can anyone please give me a clear example of how objects attached through llAttachToAvatarTemp can be used by griefers in ways that objects attached through llAttachToAvatar can't, before jumping the gun?

I thought it was just a way to e.g. rez a RLV HUD (like that in RR products) and attach it without clobbering my inventory. What did I misunderstand?

[Kyrah Abattoir]

And linden labs has done it again.

Marine the viewer doesn't "think" the object is owned by the wearer, i checked from the script perspective it's the same, temp attachments involve inventory transfer. Which makes the security of using those attachments moot.

example: I make a game with special guns, i want to use temp attachment so at no point the wearer can tamper with game equipment. Not only do i have to set the bullets copy/mod if i want to sell the system, but i cannot check the owner key to detect if game equipment is owned by the game manager account.

Another good idea from LL with a half assed execution.

[Marine Kelley]

Sei : I'd rather not give ideas to griefers, but the first annoyance that comes to mind would be to strip you in a public area.

Kyrah : Indeed the viewer (mine or any other) is not given any information as to whether an attachment is temporary or regular, once it is attached. The ONLY information we have to tell both apart is when the object requests permission to attach. Once it's on, there is absolutely no way to tell a temporary one from a regular one. That's the information we need LL to give us and I'm pretty sure they will eventually.

[Sei Lisa]

Again, isn't that equally possible with llAttachToAvatar alone? What makes llAttachToAvatarTemp special that can't be done with llAttachToAvatar?

[Marine Kelley]

With llAttachToAvatar you have to own the object first, with llAttachToAvatarTemp you don't.

[Former user]

I'll be one of the (evidently) few to disagree. llAttachToAvatarTemp() could be used to annoy, but no more than many other existing techniques. However, it does open up some interesting and intriguing possibilities for the forced/transformation players.

Reasons to allow temp attachments to execute RLV commands being:

(A) Without a relay on auto, the object will not be able to temp attach without the Relay asking permission to take control for the object (so it can execute the @acceptpermission command.) or the object being given permission to attach. Yes, this means you have to think before you click the accept dialog, to make sure it is the result of something YOU did. Random popups requesting those perms should be declined, obviously. And if you have your relay on auto, you are accepting the potential (much like many other things in SL.)

(B) The object that attaches in this fashion cannot live through a logout, and therefore it CANNOT reassert any restrictions when the player logs back in. Unlike items that live in the players inventory, such an item does not require 'cheating' to escape from it. Simply relog, and it's gone.

I don't see the danger. Only the potential for those who enjoy certain kinds of RLV play to not have to constantly click dialogs.

[Former user]

Helium pointed me towards this, and I feel the need to chime in my dissent also, as I fail to see exactly how RLV+Temporary Attachments exposes any great security or privacy risks, that are not already 'exposed' by the use of RLV - and optionally, a relay - in the first place.

To start with, there's essentially only two sources for a temporary attachment: One, the object is rezzed by another object owned by someone else, and two, the object is rezzed by another object owned by the user. In the latter case, there is Nothing that new object can do that the initial object couldn't. So I'm sure we can all agree that nothing there is griefable that is not already griefable by ne'er-do-wells.

For the second, the object is rezzed from an outside, unknown source - at a shallow glance this does seem griefable, yes. But then, it requires a Permissions Dialog to be accepted! Isn't RLV based around "providing consent" in the first place? Last I checked, if a user accepts the dialog, they are consenting - either explicitly (clicking 'Yes'), or implicitly (the Diag is auto-accepted).

But, of course, there is @acceptpermission. And it's an ordinary indistinguishable PERMISSION_ATTACH request, which that RLV command grants. If a user had that command active, then they wouldn't see the dialog, and the Possibly Griefable Object would be automatically attached - this is true, and can't be denied. But then you have to ask, "For what reason is @acceptpermission active?" And there's two answers to that, too; An object Already Worn by the user granted it - which means they've already consented! Or, an external object requested it - which means a Relay.

So now, the only way it can have automatically attached by an object that they don't own (because attached by ones they do own already implies the trust in it)... Is via a relay enacting @acceptpermission in the first place. And for that? They have accepted the relay request, giving consent! Either - and this may sound like an echo of what I mentioned earlier - because they explicitly clicked 'Yes', or because their relay is on Auto.

Last I checked, leaving your relay on Auto meant that you accepted responsibility for what may happen, didn't it? I may be sounding insensitive here, but why should a function be crippled simply so that people don't have to take responsibility for Something Happening when they moan "Oh boy, I'm on Auto, anything can happen to me!"..?

Further to it, as Helium mentioned it's not even as dangerous as attachments given to #RLV - Temporary attachments cannot issue anything that they cannot, and if they do issue something you dislike (e.g., "a complete lockdown" perhaps), a single relog will solve the problem. There is no need to relog twice, out of RLV then back in, which some abhor as they find it a form of "cheating". If then on a relog an object grabs the relay again and attaches a new temporary attachment, why should it not be treated the same way a regular relay re-grab would, then? Safeword your relay, move to another sim, put it on Ask/Off - there are multiple ways to solve the problem.

Honestly, as a worst-case scenario, bundle this into "Forbid Give to #RLV". If you don't want objects being attached to you at all, then it could block both methods. Very Minor Problem Solved.

As for "Temporary Attachments can do anything", isn't that... A problem with them in general, completely unrelated to RLV, and already acknowledged as an 'Acceptable Risk' by LL? They still can't delete your inventory, they can't issue any RLV command a relay cannot already (and would be able to do so in order for it to have attached the object in the first place, unless you explicitly accepted which is also giving consent), and they cannot call llTransferLindenDollars or anything of the like, unless you also accept the Massive Debit Permissions Dialog!

I'm not entirely sure how there's "no real value added for regular uses" either, as Iala's example on a "griefable" object name actually highlights a benefit of it - Restraint HUDs that rez+attach each time you log on... But no longer add a new inventory item in your Objects folder? Completely transparent to the user (inventory pane would not skip to the 'new item added'), nothing to clean up and delete afterwards... Nope, nothing useful there. And I haven't even touched the benefits for the 'transformation' enthusiasts on SL; Whilst I know they were never the Intended Audience of RLV in the first place, you can't deny that they are more than just a minor ancillary footnote now.

[Former user]

Sorry to tell Batche. Setting the RLV relay on Auto doen't mean for me the user gives an unlimited concern to everything coming. For instance stripping someone in a public area just because they set the relay to auto, i stil take as griefing, unles the stripper is play-mate for the stripped person or that one states in the profile it is allowed. Otherwise you can take flirting in a RL pub as a concern to rape the girl, to give an extreme esample.

But back to the issue. Marine stated, that the @acceptpermission is not applied to unowned objects, so you will still see the attach permission dialog for objects not owned by you, even if @acceptpermission is set. I think this is a good decision. Yes it will break the games where you enter some area and the new avie is rezzed by foreign object and autoattached on you, and you not see the distrubing dialogs.

That would be fun too, and that pesky dialog would ruin the fun. But there is a simple solution for that case:

1. You enter the transformation area
2. A bracelett is temp-attached to you while you concern
3. Your new avie is given to the bracelett insted of you
4. Bracelett rezzes the stuff and sets @acceptpermission
5. The new avie is attached temporally without bugging you by pesky dialogs.

About the concern given to temp attachment, and how it can be msused. Imagine i do rez a drink giver in a full club. It rezzes some martini glasses, everyone can click the glass which is called "Martini (right hand)", the glass requests an attach mermission and is worn temporally on right hand. And nothing hapens to them than.

But if some special person touches it, the object called "Martini (right hand)" attaches somewhere to root (to be harder to find), than locks itself, shuts down TP, chat, and starts droping clothes piece-by-piece. The victim sees everyone wears martini, with no danger, so the victim gives the concern for attaching, thinking it will be just martini, actually the concern is given to attaching and playing the drinking animation, but to nothing else.

Now the victim has no way to tp out or explain it was a grief. The result is a ban in this club and if it was on PG area even on the whole estate or SL for no reason.

So although droping @acceptpermission for unowned objects is a good start, ignoring RLV comands from temp attachments will be correct safety decision, and i hope it will be possible some day.

Just a word to club owners and staff: Such griefing scenarios is possible and will very likelly also hapen.

[Former user]

To make a constructive suggestion, as soon the viewer becomes able to tell if the attachent is temporary or not, instead of simply shutting off all RLV commands from a temp attachment, i'd suggest a special switch for that, or a new rlv command like

@accepttemprlv=y/n

This command should be ignored if issued by a temp attachment (so only a regularly worn relay or owned object can set it) and the user is able to blacklist it. If the restriction is set, the viewer will accept RLV commands from temporary attachments.

This seem to me to allow the user to decide if and where the temporary attachment can control the viewer. This way you can enter transformation games or use those drinks if and where you are aware of such items potentially dangerous elsewhere.

[Former user]

Jenna, in your griefing example, you fail to recognize one thing. With a temp attached object, the 'victim' only has to log out. The moment they notice that something is executing RLV commands they did not agree to, a simple relog will cause ALL temporary attached objects to vanish. They might have to log back in at their home location, instead of where they were last (in order to re-wear clothing, etc.) but they are NOT locked down with no recourse. No need to disable and re-enable RLV, or anything like that.

And if that's a major concern (and you visit a lot of PG sims, etc.) wear a skin that has undies as part of it.....while the object CAN strip you, or force-wear things in your #RLV, it cannot give you anything to your #RLV without an accept dialog from the inventory give (unless you have ALSO enabled 'auto-accept new inventory in the prefs) and have shared wear enabled. If you are setting your prefs up so as to be vulnerable, you should expect this kind of thing now and then.

Now, I agree that the "@accepttemprlv=y/n" command is a good idea. Even moving it from RLV into a debug setting for the viewers isn't a bad idea. At least that way, those who LIKE being vulnerable can be.

So, to recap.....To be vulnerable: 1) Enable RLV 2) Wear Relay 3) Set Relay on Auto 4) Refuse to wear PG-skins

Fail to do ANY of these, and you could be griefed in the way described. Do JUST ONE, and you are no longer vulnerable.

It should be noted, btw, that when the object DOES temp-attach, it loses ALL permissions, and they have to be re-acquired by the object. Of course, with RLV on, that's easy to do.....

(And the current bug with animation permissions not being revoked is a MUCH bigger griefer hole than this......And that works on ANYONE, not just those with RLV)

[Former user]

I just wanted to chime in as another dissenting opinion. Just to be clear though, I am working off of the assumption that the @acceptpermission change (to not autoaccept attach permissions from unowned objects) is done and in place. I agree that such a change is necessary, because it means that the target has to click something to accept the item.

And that, I think, is the crux of why I feel like this is not nearly as big a deal as it is being made out to be. What exactly is the difference between clicking "yes, I grant permission to attach" and clicking "yes, I'll accept this #RLV folder" and then having it force-attached? You have to manually choose to accept the item in both cases, the only real difference is that people have learned to be leery of inventory offers, but haven't necessarily learned (yet) to be leery of attach permission requests. Even then, people have already had to deal with bloodlines permission spam, and griefing items that request debit permissions and the like.

At some point, you have to trust the user to actually pay attention to what they're doing and clicking and accepting. Apparently we trust them enough to let them choose whether to accept arbitrary inventory items and open themselves up to having the item attached for reals, so why can't we trust them to choose whether to accept arbitrary inventory items to be attached temporarily? Must we really accommodate to the lowest denominator here?

Also, to give a specific counterpoint to Jenna's martini example: Nothing you described there requires TempAttach to occur. It could just as easily happen right now, and I'll give you a specific example how (trying to stay as close to your example as possible).

Consider the pub right next door. you walk in and everyone is holding martinis in their hand, drinking them merrily. as you approach the bar, an automatic script says "click the mixer to receive a martini!" Everyone seems to be wearing the martinis without incident, so you click it and receive "Martini (wear me!) (right hand)" which you then wear. If you were not a special person, your experience ends here. IF you were a special person though, the "drink animation" script in the martini (totally innocuous looking, since you need a script to play that drinking animation) sends a @version command to the relay channel. the RLV-enabled viewer automatically responds (no relay needed here), the and suddenly the victim gets hit with restrictions.

Virtually the same scenario, almost exactly the same result. The only real difference is that in my scenario the victim needs to log out twice, once to disable RLV and once to re-enable it. In both cases the victim consciously made the choice to expose themselves to the risk, either by allowing the attach or by wearing the item; they may have been lulled into a false sense of security by the surroundings, but that can happen just as easily now as it would with tempattach. You might argue "but people won't be as vigilant about permission requests," but that's just an excuse. Careless people will expose themselves to risk, and it doesn't matter how the risk is presented, whether the window is blue, grey, or has giant blinking letters.

[Former user]

I find it very disappointing that Marine hasn't responded to any of the dissenting opinions....we have valid arguments.

[Marine Kelley]

Well this discussion is not only with me, but between you guys :p

The @acceptpermission command does not work with temporary attachments on purpose, it is implemented and released that way so I don't think it will change. This is the only way to protect yourself from having a temporary attachment send RLV commands to your viewer without you being able to do anything about it, even avoiding the object in the first place.

As to whether a RLV command in a temporary object can be nasty, no it cannot really be nasty (no RLV command will break your inventory or steal you L$ or spy on you) but it can really be annoying when done poorly or with the intent of griefing you. Some people are more sensitive to frustration than others, most are not technically minded so when something goes wrong, their motivation can spiral down really fast. Sure there's no real damage done, but some people take a bad hit when they are griefed. I do not want to give griefers more tools than they already have.

As for @accepttemprlv=y/n... that wouldn't be practical. It would force scripters to distinguish two cases, one where the object is able to send RLV commands and one where it is not. Besides it would have to be an internal viewer switch, rather than a command, since it should be decided by the user only and not by a script.

To Renethe : "Must we really accommodate to the lowest denominator here?" Yes, always. It does not mean we should restrict ourselves too much, but we must put safeguards in everything we do, in SL and outside SL. That's why you have barriers on the sides of the roads and ramps on the stairs. I know the mentality nowadays is to think "I am strong, screw the weak", but you cannot be strong all the time, sometimes you need the safeguards too.

[Former user]

I'm still trying to understand how someone needs 'protection' from temp-attachment. If someone turns on @acceptpermission in their own worn object, they are giving consent for other objects to attach without being prompted. How is this something that needs to be protected against? If someone's owner turns it on in the players worn object, again, didn't they consent to let that person have the choice to do that? And with relays, they HAVE to allow the @acceptpermission request (either explicitly, or implicitly with an auto accept setting on the relay)......

We need to be protected from our own choices?

And since you can log and remove the object instantly (no need to disable rlv, relog, remove object, re-enable, relog again, etc.) as well as log to your 'home' location so something doesn't auto-spam requests (which would get removed quick anyway, since it'll be spamming a LOT of people) the griefing potential of this seems pretty low to me. Considerably less than something that does an inventory give to #RLV.....and those kinds of traps already exist, but #RLV hasn't been 'disabled' for everyone. And the 'you have to click to accept the folder' doesn't work, as there is an 'auto-accept new inventory' option now.

At the very least, put a debug setting in the viewer so that we can choose between the two behaviors.

I'm not going to comment on the 'lowest denominator' stuff.....I'd just get some people riled up and that's not my goal. I will say, however: "At some point, you have to let people have responsibility for their own actions. We don't need to be protected from our own choices." and to quote old Ben Franklin, "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."

As for the 'barriers and ramps'....Not ALL roads have them. Only those that are a genuine hazard without them....the other roads don't, and assume the drivers will be responsible enough to not just drive off the road......

[Marine Kelley]

We need to protect others from your own choices, rather than protect you from your own choices (which would be wrong).

There are ways to hide a temporary attachments on your body and make them really hard to spot and even harder to detach once they're on. Granted, as they're temporary they stay only for the duration of the session. Granted, RLV is secure so no griefing through it would do real damage (or would it ? How about being TPed naked into a welcome area without your consent ?). Granted, you must have given authorization to the object to attach in the first place. But that authorization is not a free pass for the object to do anything it wants.

The minimal protection I can give is to keep @acceptpermission from allowing a non-owned object to attach on you. For the time being, once attached, a temporary attachment CAN send RLV commands to your viewer and the latter won't be able to tell that they come from a temp attachment. I am just waiting for LL to give us a way to distinguish the two types of attachments, so that temporary ones cannot use your RLV at all.

Whatever you want to do with a temporary attachment, you can do with the traditional way of giving stuff and making the user wear it already. Only that traditional way is more secure (even though harder to script but not much) and safer for said user. The objects are visible in the inventory, so the user is not confused.

As for a debug setting, IF there is a real need for RLV commands to be executed from a temporary attachment, then why not. So far I'm hearing many more requests NOT to let a temp attachment send RLV commands than reasons to let it. It's a loophole, poorly designed because we have no way of telling a regular attachment from a temporary one from the viewer's point of view and that opens the door to all kinds of nastiness. I have designed the RLV to only obey commands sent by owned objects in the first place, that's not to let just any random object control your viewer ! There have been a couple ways to really grief you through the RLV in the past years, loopholes that came from my inattention or from LL's codebase (they are all patched now, to my knowledge). Some of those loopholes did not even require your consent to be exploited, and that reflected badly on the RLV itself during that time. Temporary attachments are just a can of worms waiting to be opened, any future loophole would be amplified by their use. I'm trying to err on the safe side here, and to keep the users confident their viewer will not betray them at some point down the road.

[Former user]

What I cannot see, is how any of that (and every example so far) cannot currently be achieved with an inventory give and a force-wear. For an object that isn't worn already, a relay has to be involved, or the player has agree to the object attaching (in some way). And an object that is in a given folder has to be accepted the same way into #RLV. What prevents an object in that folder being attached (and not just temporarily) and then stripping and TPing the player in a similar fashion?

As for the confusion issue, what prevents that same object from being named based on a path/worn scan with a relay? Then you have two identically named objects, which one is the problem one?

So if the same scenarios can be done with existing RLV mechanisms, why are temp-attachments any less secure?

I'll see about getting a few more of the dissenters I've discussed the issues with to come post here, so you'll have a better sampling......most of them are using other viewers, which while they are not the RL Viewer, do incorporate its RLV code changes (or through RLVa by Kitty, which is, of course, based on the RL Viewer code). So they aren't as likely to know about these discussions.

[Marine Kelley]

When you give a folder to the #RLV folder of a user, it appears there, there is no way to hide it. When you attach a temp attachment, it does not appear anywhere in the inventory. For the moment both can issue RLV commands, but if both of them are griefing items, the temporary one is harder to get rid of because it won't be spotted easily. Granted, you can just relog and the object vanishes. And then it is given a second time, etc.

I am not willing to try to imagine any scenario a griefer could come up with, but I am not willing to make their task easier by exploiting this giant loophole temporary attachments represent either. As you said yourself, if it can be done with a temp attachment, it can be done with a folder given to #RLV, so I don't see why you are so adamant to allow RLV commands to be sent from temp attachments. They wouldn't be efficient anyway. I'm seeing a lot of potential for trouble here, for little return. Lastly, a temp attach vanishes completely after a relog, so if it was a griefing item, no trace will be found. At least with a regular item you still have the item, even if it has deleted all its scripts, and LL can look into the issue afterwards.

I'm curious, what exactly do you have in mind for temporary attachments with regards to RLV commands that you can't do with a folder given to #RLV ?

[Former user]

Several options become available with temp attachment. Traps (which while restrictive are easily escaped from if needed), Transformations (also can be escaped via a relog), and more. Such things can be tied to areas and such, instead of having to reside in the inventory. Further, much more 'complete' items can be used, since the items never reside in inventory......unlike transformations that are given fully to a #RLV directory (which can then be copied, shared, modified, etc.) and thus the transformed form is still marketable, but can be demonstrated (or even used in traps and such) freely, since the item can't be kept through a relog, or copied into another directory or such.

Utility objects are also very useful to temp-attach, to avoid having to scan for it in #RLV, give it if not found, then force-wear it. (or if you skip the scan, ending up with multiple copies stuffing your #RLV to the brim with duplicates). Blindfolds, binders, and more could be temp-attached easily from a single object rezzed from a worn object......and that object can llDie() if rezzed manually (i.e., no parameter passed to on_rez()) so that full-featured items can be used and also sold separately for those who want them full-time.

Sample items, temporary restriction pieces, transformations, and more can be build, sampled, and used in a much LESS annoying fashion. Many who get hit with a transformation and find it unappealing or offensive have to go through the whole rigamarole of disable RLV, relog, find and remove, re-enable RLV, relog, resume......with temp-attach, a single relog solves the whole issue, and with no searching to find the attached/worn item.

I've built SEVERAL items that utilize temp-attachment and RLV, and the overwhelming response I've gotten from those I've demonstrated them to was positive. They l liked it, and knowing it would be gone if they relogged made them feel a bit safer about allowing it to attach. Accepting a folder was always a bigger concern, since if an item attached and locked, they would have to go through the whole mess of 'cheating' out.

I see a LOT of potential there.....and I see a LOT less risk in many ways. And I'm not sure why you think they are 'less efficient' than having to give a folder. An unowned object CANNOT execute the @acceptpermission command without a Relay to hear it. And that has to be accepted by the relay (either via explicit dialog, or implicitly from an auto setting). No different than simply clicking 'accept' on the attach request, other than the option to attach several at once with one acceptance (to the relay request) instead of 4 or 5 attach requests.....and the option to not see any prompts at all (relay on auto).

Even temp-attached objects hit the server logs. So I'm pretty sure LL could trace down a griefing object just fine even without it being in inventory. And if it gets re-rezzed and tries again after the first relog, I think the player will make note of the requesting object name in the attach request dialog, for reporting purposes.

[Marine Kelley]

I hear you about the possible advantages of letting an object send RLV commands even if it is temp attached, but really all these can be done with the traditional way of sending a folder to the #RLV folder and then having it worn through the RLV relay. That's much more secure because it goes through the security policy of the relay, while temporary attachments completely bypass it. Now, if it is really really needed (and I don't mean through lobbying, I am not the only one to convince here), the least I could do would be to introduce a viewer setting to let the user decide whether they want to let temp attachments send RLV commands or not, with a default to False. Everybody would be happy that way and that wouldn't give me much more work (granted, of course, we actually CAN tell a temp attach from a regular one, which is STILL not the case).

I've had a few ideas that would be nice to do with temporary attachments as well, such as cuffing someone without they owning said cuffs, but I did that with giving the folder to #RLV anyway. That's a whole folder with several cuffs, not one permission request per item. Much more convenient that way. I hear you about the transformation bit though. I've been hit by one such object once (and I found it well done), it was annoying indeed. But I don't know how it would be done with a temp attach, since it contained a whole folder with a skin, items and clothes. If you want to do transformation, sooner or later you need to transfer to #RLV anyway.

To answer your question, my real concern is that a temporary attachment will NOT always ask permission to attach. There are cases (which I won't discuss here, but I mentioned one way already above in this thread) that allow an object to attach automatically to your avatar without asking permission and without you owning it. Relying on the attachment permission is a good start but that's not enough.

[Former user]

So, let's say, that we want to cuff someone, as in your above example. But the cuffs you have (or want to use) are something you sell. An object given through #RLV has to have transfer permissions, and usually copy perms too (if it is a rezzable object like a trap or area-effect system.) So what happens is your item that you sell would be out there and shared around. Why buy it when you can get a full copy from the trap, or someone who got caught by it?

Now, you could build a whole new set of cuffs you don't want to sell, or spend a lot of time putting in some kind of 'copy protection' (which is always full of holes in SL) to the original.......

....or you modifiy the script in the cuffs just a little (I've done this, it isn't a lot) and have it rezzed and temp-attach. Suddenly, they can't copy the item....since it's not in their inventory. This allows builders a much better system that #RLV, since they aren't restricted by those concerns. We'll see much better and elaborate traps and such once they notice this is possible.

But only if those traps/transformations can use this method. Now, it is true that we can't rez clothing/tattoo/alpha layers and temp-attach them. I wish we could! But at the moment, we have to give to #RLV anyway for those, and force-wear them. Which adds an additional layer of complexity. But, with the advent of rigged mesh for clothes and even whole avatars, this is much less of an issue......the only thing you might have to worry about is an alpha......and that's ONE layer in one #RLV folder. And ALL any particular builder's (possibly more than one) script has to do is look to see if it's already there, and force wear the alpha before doing the temp-attaching items.

I would agree the viewer setting is a valid solution. Even including one to allow @acceptpermission to work with temp-attach requests could be included (for those who really want to be vulnerable.) I've added debug settings to the viewer before, so I know it is a little work, but it's not that difficult. It'd also be nice to be able to query through RLV to know some of these things (like if #RLV is disabled, or any of these new temp-attach flags are enabled, etc.)

I've gone back through the thread, but I don't see a method (beyond the @acceptpermission command,) where an object you don't own can attach this way without prompting the attachee or using the Relay and @acceptpermission. If there is such a mechanism, that's a bug and it should be filed as a JIRA with LL.

[Sei Lisa]

I'm with Helium here that temp attachments with RLV access are very useful; if at all, to not clobber the inventory. I don't trust in checking if the item is already present, because I've had issues with folders having the same names as other items, not to mention that creating a folder with the same name is a way to cheat to escape being restricted from a specific item; therefore when I give to #RLV I give a new folder ending in a random number, with the disadvantage that that clobbers the inventory. Temp attachments solve that clobbering.

As for the option of not allowing RLV commands from temporary attachments, yes please: rather than breaking the content that is now being created already (I am one of the creators), at least give an option. As for the default of such an option, I hope it doesn't happen as with the "Forbid give to #RLV" option. At some point, the Phoenix team decided to make it default to TRUE, probably because it was seen as more secure. It has caused me lots of headaches when introducing other people to RLV for the first time, setting up their RLV and relays. I always had to tell them "Look in Advanced > RLV > Forbid Give to #RLV and ensure that it is NOT checked". Those who didn't know, had already several folders starting with #RLV/~ which were a pain to move to the right place and rename, not to mention the confusions that arose while giving indications. Fortunately, the default was changed again later. I foresee similar problems with this option, when I help people make things that use temp attachments work as expected.

In this case, saying that you "bypass" the relay security settings is exaggerate. You get a similar effect as if the relay was in "ask" mode, because you are asked in both cases. Except with an entirely different dialog in this case, similar to the one you get when you are asked to be bitten by a vampire. It's possible for a griefer to apply a session-long deformation to your avatar with an animation, and you don't need to have RLV active, by just getting you to accept such a dialog. Yet you don't happily accept every animation you're randomly offered, as you don't happily accept every attachment you are offered.

I'd also like to see an option for @acceptpermission to work with temp attachments. There are those who will gladly take the risk of being griefed in exchange for the comfort of not having to accept an attachment, or for the forcefulness of not having the option to reject it. I agree that such an option can default to not act on temp attachments without breaking any contents. But it's good to have the option.

To Helium: I think the concern of not accepting a dialog has to do with "Experience Permissions". But in that case that will be the issue, not temp attachments, and measures can be taken if and when they are implemented.

[Marine Kelley]

The "options" solution seems to be the best one indeed : I'd add an option for @acceptpermission to work with temporary attachments, and another option to let a temporary attachment issue RLV commands (*), both defaulted to False. If the second one is False, the attachment won't even get a response from a "@version" command. How's that ?

(*) Only when we are actually given a way to tell a temporary attachment from a regular one, that is.

[Sei Lisa]

Except for the default on accepting RLV commands from temporary attachments, that sounds good to me. While you don't get that notification, content is being created that relies on temporary attachments working, and you will break it when you add that default, for people unaware of that option.

I propose instead looking at how it goes during the time they can't be distinguished, and deciding on whether the risk was so great as to deserve switching it off by default later.

[Marine Kelley]

Deciding the default value of a debug setting is a viewer concern, it will not be in the specification. In other words, I will make it False by default in my RLV, the other TPV devs do what they want. The script won't even be aware of it anyway, all it can do is interrogate with a "@version" command. If the flag is set to False, there won't be any response as if the user was not on RLV at all.

As for content being created that relies on a feature that I said wouldn't work, I find that argument a little strange. I was clear very early about what would happen to RLV commands sent by objects you don't own, I think. Allowing it through an option is already stretching the spec to a territory that I and others find dangerous, and already having made and sold objects that rely on that "feature" does not change anything. If the user is given a way to protect themselves or not AND they know what they are doing when they remove that safety (i.e. we don't impose that loophole on them without control), then why not. But I never said RLV commands sent from a temporary attachment would work at all times. I'm pretty sure I said it wouldn't.

[Former user]

I think a better solution would be to default the behavior of @acceptpermission to not allow unowned objects to execute it, but to default the behavior of temp-attached objects to allow RLV commands. That way, the objects will still work, though at defaults they will always have to be accepted by a dialog. Then those who find the dialogs irritating and want to be affected without prompting can change one setting, and those who want to secure themselves completely can do so by changing one setting as well (just the other setting.)

Technically, once you agree for the temp-attach object to attach, the person DOES own the object, even if it isn't in their inventory. I guess they are just different perspectives on the issue.

[Former user]

I'm fairly new to RLV scripting so I don't know if RLV auto accept permissions also works for permission_debit, but if it does it would be a Valhalla for thief's. shoot a temp attach, set @acceptpermissions then use a llsettimerevent(0.0001) to transfer 1 Linden to themselves and drain your whole account dry in a matter of seconds.

[Marine Kelley]

Don't worry about the permission to take money from your account, it is not included into the permissions that a script can be granted automatically. Only permission to trigger an animation and permission to attach can be granted automatically, and no other.

[Former user]

thats a relief

[Former user]

A bit late to this discussion but... it turns out there's no point in blocking RLV commands from a temp attachment, even if you could do it. I did some tests, and objects rezzed by a temp attachment are (like the attachment itself) owned by the wearer. If you blocked RLV commands from temp attachments, all a greifer object would do is rez an object that could send RLV commands normally, and even attach itself in a non-temporary way.

Blocking @acceptpermissions from working for objects not owned by the user stops this from happening before things get that far, but once the object is past that, it has no reason to remain as a temporary attachment if it doesn't want to be.

[Lance Corrimal]

Whatever came out of this? Is there a debug setting now that would allow rlv from temp attachments?

[Former user]

Perhaps now we have Experiences we could link the two in some way to allow temporary attachments from experiences you have accepted where the script is compiled using that experience. I'd like to auto attach RLV relays if someone has accepted my "Mars" experience and have entered a play area. With current release of Firestorm (4.7.5.47975) and RLV relay attached in this way can issue rlv commands except @detach=n (or sneaky remattach:point=n derivatives).