Talk:LSL Protocol/Restrained Love Open Relay Group/key

Should the key be deleted/inactivated after a take over? If not, there is the possibility for the session to be stolen another time, by replaying the message. If it is, then, it should be explicitly said in the spec!

On the other hand, it would be interesting if the session key completely superseded the controller key. Then there would be the possibility for a bunch of controllers to share a session (one being able to change restriction from another, with no real takeover/handover). Of course we would want to add some security so that only authorized device could join the session (combining with !x-channel could help some). Maybe also we would want to make a difference between session key and session password. --Satomi Ahn 00:36, 28 October 2010 (UTC)

The key is not deleted or inactivated after a takeover; if the session was negociated with !x-channel on a private communication channel, the key is private. Of course, after a takeover, the controller can renegociate a new key by sending a new !x-key command: the new key must supersede the old one. --Dahlia Orfan 20:35, 1 November 2010 (UTC)

Version 003

I rewrote some aspects of the specification. LSL_Protocol/Restrained_Love_Open_Relay_Group/key/003_draft

Most notably !x-nopingclear became !x-noping/clear and I added requirements concerning privacy (and llRegionSayTo). Consistently, refrences to !x-channel were removed.

Also I removed the paragraph about !x-email, since I am also modifying this one to be have more consistently with over x-tensions such as key and forward.

I did not understand the paragraph about reseat too... So I removed it :P. In my understanding, resitting has always been the responsibility of the relay.

Any comment?

Yes, your relay does not resit a captured avatar as I had in mind when I wrote this paragraph; my relay does. There is clearly a misunderstanding and I re-add the paragraph.

--Dahlia Orfan 10:51, 9 June 2011 (PDT)

Ah... my relay is actually supposed to resit, but there is a bug right now. The resitting part is in the basic specification.

--Satomi Ahn 12:53, 9 June 2011 (PDT)

I do not know any other relay but mine which resits the captured avatar (so execution of a @sit:uuid=force) after a refresh/relog except mine; so I am very surprised to discover that it is in the basic specification. Are you sure, there is no misunderstanding ? By resit, I do not mean just llOwnerSay("@unsit=add") after a refresh/relog but also llOwnerSay("@sit:uuid=force")... And the uuid key is not necessarily the one of the grabber; test with tkPBA: the relay resits the avatar on the grabber, not on the chair I was before relogging.

--Dahlia Orfan 17:16, 9 June 2011 (PDT)

Other topic: ok, I understand that !x-noping and !x-key are to be considered like restricting, in the sense they require authorization from the wearer. But a nuance should be made here. To me there are "transient" and "persistant" restricting commands.

Both transient and persistant would live through till the end of the session, but transient ones would not hold the gate open (keep the session open) if no truly persistant restricting command was also currently living. They would just vanish and close the session after some timeout.

But I digress. This is something we should add to the core requirements. Then I believe !x-noping and !x-key should be transient as they have no use when there is no actual and concrete restriction. This would make of !x-noping the first transient restricting meta-command with a /clear version... Is that fine?

--Satomi Ahn 08:55, 9 June 2011 (PDT)

!x-key is not a restriction; !x-key transmits the UUID key of the session to the relay, and only once; And in my relay, !x-noping is implemented as any restricting command and I do not see the interest to do a so subtle distinction: your idea is just more complicated to program with an additional timer. After all, if the grabber wants to remove the noping restriction, it sends a !x-noping/clear. The command !release also cancels !x-noping...

--Dahlia Orfan 10:51, 9 June 2011 (PDT)

My point was not to add another timer, but just stating more clearly what my relay (and I think also others) already does. The distinction is not that subtle (look here: Talk:LSL_Protocol/Restrained_Love_Open_Relay_Group/ORG_Requirements#Version_004). Some commands require authentification (this is maybe what you call restricting), but do not establish permanent restrictions that require the session to stay open. This is what I meant by transient.

The reason of the timer is so that the user does not get asked again every 2 seconds if a bunch of such commands is sent to their relay.

--Satomi Ahn 23:24, 9 June 2011 (PDT)

I think it would be great to have a way to fork a session too.

C->R !x-fork/<new_key>
C<-R !x-folk/<new_key>,ok

After which a new session is created having exactly the same restrictions and memory.

This would be useful if you want to give a session to another device while keeping your own session.

An alternative would be to fork without copying. But then you'd have to take extra steps to add restrictions so that the new session is not transient, using !x-takeover more than necessary. (on the other hand, if you put too many restrictions, you will also need to switch between sessions to remove the restrictions you don't want copied... ).

--Satomi Ahn 09:55, 10 June 2011 (PDT

!x-noping

I was thinking about the risks of !x-noping setting restrictions that can never be cancelled, and how these could be mitigated - and wondered what other people's thoughts were on this. In particular, the spec notes that !x-noping can be used without !x-key. This would clearly be a foolish thing to do in a worn controller, and a note to that effect should probably appear in the spec if this issue is not otherwise addressed (see below). If the user wearing the controller is logged out for any reason then it will be impossible to cancel the session, rather going against the requirement that A controlling device MUST, at any time when a relay is locked, provide a mechanism that will unlock it in bounded time.

Even if the worn controller does use !x-key, there is a danger that if there are problems uploading the script state to the asset server when the wearer next logs out, the key will be lost. It will then be impossible to release the victim.

The risks with a controller that is rezzed in-world are smaller, since its UUID should never change. (The benefits are smaller too, though, since a grid-wide ping protocol should suffice to allow a long-lived session to be established.) However, a sim crash can still cause the controller's scripts to revert to a state up to an hour earlier (perhaps before the session was created) or of course the controller's scripts may simply have bugs.

!x-noping removes the current last resort mechanism that the owner of a malfunctioning device currently always has for releasing the victim - namely derezzing the device. It seems to me that the noping spec needs to provide a replacement mechanism that a device owner could use.

The best solution I can see is that for any session for which noping is in force, the relay must also store the UUID of the owner of the controller. The spec could then include a command, !x-noping/forceping that forces a one-off ping of all sessions marked as noping that are associated with the owner of the object sending the command. Any device that failed to respond to the ping would have its session removed from the relay. Melancholy Lemon 13:19, 16 June 2011 (PDT)

The part about !x-noping being usable alone has been removed in 003.

We are aware of the issues of !x-noping risking sessions that remain stuck forever. However I am not sure I really understand the forceping proposal. This would make !x-noping completely moot, wouldn't it?

Another approach would be forcing the use of !x-delay or similar commands (note that !x-delay already disables ping as long as a delay is running). I see little inconvenience in sending !x-delay/10000|!release instead of !x-noping.

--Satomi Ahn 04:52, 17 June 2011 (PDT)

The use of !x-delay is excellent; The idea of storing the UUID key of the owner of the controller is very good; the relay implementing the x-tension key should have a button "safeword_by_owner" (a shorter name should have to be found); by clicking this button, always present in the dialog box, even if safewords are disabled, the wearer could choose a present avatar around and asking him/her to release all sessions those controllers is owned by this avatar.--Dahlia Orfan 05:23, 17 June 2011 (PDT)

Or what about a command !x-cancel, to be added to the x-tension key; if C sends to R !x-cancel, all sessions of R those controller and C has the same owner are cancelled. --Dahlia Orfan 05:31, 17 June 2011 (PDT)

About !x-cancel and safeword_by_owner, the problem is that you would have to remember the owner name for each session in the relay memory (it cannot retrieved from the UUID of the object that potentially does not exist anymore). --Satomi Ahn 05:38, 17 June 2011 (PDT)

Storing the UUID key of the owner of the controller (not of the avatar who used the controller) is already done in my relay : capture yourself with my relay and click "grabbers"; you will see Grabbed by xxx (owned by yyy); I did that very early in my relay because I had in mind when you want to tell someone about a problem with this controller (technical problem, grieffer, etc...).--Dahlia Orfan 06:18, 17 June 2011 (PDT)

Actually, the UUID key of the owner of the controller is also already in your relay Satomi... So I do not understand the problem at all. --Dahlia Orfan 06:42, 17 June 2011 (PDT)

Coming back to !x-delay: Dahlia pointed to me in IM that delays could be huge so that there is not much difference with !x-noping for all practical aspect. However, the syntax of !x-delay encourages the device scripter to think about a reasonable delay, which !x-noping does not. --Satomi Ahn 05:38, 17 June 2011 (PDT)

I wrote a new draft without !x-noping, with advice how to use !x-delay instead. Now I can see there was an advantage for !x-noping: its implementation was way easier than !x-delay. We can revert my recent editions if this is a big issue. --Satomi Ahn 06:07, 17 June 2011 (PDT)