Jump to content

Security Orb - is it possible to make?


Teqi Falta
 Share

You are about to reply to a thread that has been inactive for 4079 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Yes, but it's not necessarily very stable since it depends on a hack. Rez your object and set it to group B. Then link it to an object that is set to group A, being sure that your group B object is a child prim in the new linkset. If you do that, the child will retain its group B affinity unless you take it back to inventory and rez it again. I think it will retain it even if the linkset is deeded to group A, but you'd have to experiment to find out. Be sure that the script that's testing a detected av's group is in the child prim, not the root.

See the note at http://wiki.secondlife.com/wiki/LlSameGroup

Link to comment
Share on other sites

I think you are going to need two scripts for this.  I would have the script in the root prim (which is set to group A) send the UUIDs of detected avatars to a script in the child prim (set to group B)  to check on whether llSameGroup is true or not.  If it's not, the script in the child prim tells the script in the root to eject them.

Remember  you can't re-rez the orb after linking it up, or the child prim loses its membership of group B.

Link to comment
Share on other sites

Since that behavior is a flagged as bug, I would be wary of relying on it. The "proper" solution might be to rez two objects (one deeded to group A and the other just set to group B - not necessarily deeded) and have them communicate via direct chat (i.e. llRegionSayTo). That way only the initial handshake needs to be secured, the rest of the communication remains private.

One way to secure the connection is this:

  • Both objects have a known channel to communicate on and the same password
  • Both objects send out a RANDOM string on rez, on the comm channel. The first rezzed one of course never gets a reply. Doesn't matter. :) I'll presume B got rezzed last so it's easier to follow what happens.
  • B sends random string to A
  • A replies with llSHA1String(randomstring + password) sent directly to B via llRegionSayTo. The entire conversation from this point on is on llRegionSayTo()
  • B confirms that the SHA1 hash matches randomstring+password and sends A a confirmation to that effect. At this point, B can be absolutely sure that A is the right object to talk to.
  • A sends a random string to B (basically reversing the process)
  • B replies with llSHA1String(randomstring + password) to A
  • A confirms that the hash matches and accepts B as partner, completing the handshake by confirming success to B
  • At this point, A and B are absolutely guaranteed to talk to the right prim (they have each others UUID too) and not to some impostor, and the password itself got never revealed in chat. The handshake is also safe from replay attacks since it'll never be able to replicate the entire handshake without knowing the password.

This process can be simplified of course, I just kept it separate to make a point. It also has one advantage: If one of the two objects has to be reset, the handshake automatically re-establishes the connection.

Link to comment
Share on other sites


Teqi Falta wrote:

is it possible to make a security orb with these options?

- Land owned by group A

- Security Orb is deed to A group land

- ppl are members of group B

Security Orb teleports avatar home from A group land if not wearing the B group tag

 

Curious minds want to know-

 

How does one link a deeded object to one that isn't?

Link to comment
Share on other sites

Nevermind, one can't do such a thing. In fact, one can't even link to deeded objects together unless both of them had full perms for next owner set before deeding, since the deed is a transfer of ownership.

 

Bottom line: One can safely say that a deeded security object can only work within its own group. It will be unaware of any other.

Link to comment
Share on other sites

While I prefer Jenni's solution, I have just tried the method Rolig and I suggested, and it certainly does work.   At least,  sending llDetectedKey(0) to the child prim correctly reported whether llSameGroup(id) was true or false, so I imagine (though I didn't test) that the root prim could have ejected me.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4079 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...