Discussion on a change to llTeleportAgent().

[Mollymews 4,904]

Just now, Wulfie Reanimator said:

llTeleportAgent is not really an Experience function. It's been amended with a special exception and just happens to work well with Experiences because of the "all or nothing" approach.

yes. Same with llSitOnLink. Personally I think Linden should remove all the text about permissions from the Experiences dialog. The text says nothing about force teleport or force sit. If it was my decision then I would just have Join Experience: Yes/No, with a Help Info icon for those who want to know more about what experience-enabled scripts can do to us

just a note about seeming to go off-topic talking about Experiences. I think that when talking about scripted teleport then part of the discussion should also be about the current alternatives to what is proposed, and could those alternatives be a viable substitute

[Wulfie Reanimator 3,530]

13 minutes ago, Mollymews said:

yes. Same with llSitOnLink. Personally I think Linden should remove all the text about permissions from the Experiences dialog. The text says nothing about force teleport or force sit. If it was my decision then I would just have Join Experience: Yes/No, with a Help Info icon for those who want to know more about what experience-enabled scripts can do to us

just a note about seeming to go off-topic talking about Experiences. I think that when talking about scripted teleport then part of the discussion should also be about the current alternatives to what is proposed, and could those alternatives be a viable substitute

llSitOnLink is an Experience function by virtue of it not being usable without being part of an Experience. It has no alternative way to operate, not even on the owner. (That alone is a stupid way to implement functions, imo.) But I do agree that the Experience dialog should be made less imposing.

As for talk about alternatives, sure, but this thread was specifically created because the JIRA was accepted. The topic right now is "How should llTeleportAgent change?" not "What can we use instead of llTeleportAgent?" That's not a useful/constructive conversation to have right here and now.

Edited Friday at 09:52 PM by Wulfie Reanimator

[Mollymews 4,904]

13 minutes ago, Wulfie Reanimator said:

As for talk about alternatives, sure, but this thread was specifically created because the JIRA was accepted. The topic right now is "How should llTeleportAgent change?" not "What can we use instead of llTeleportAgent?" That's not a useful/constructive conversation to have right here and now.

accepted

lets talk about a specific of llTeleportAgent() using classic PERMISSION_TELEPORT

this capability has to be restricted to the parcel owner of both origin and destination

if it is not then we will see a proliferation, once again, of the Ultimate Orbiter. Social engineer a person into granting PERMISSION_TELEPORT and then sending them to a random region anywhere on the grid . When they come back, orbit them again to some other random region on the grid, and repeat over and over

how likely is this to happen, people doing this to others?

it has happened before. Linden released Grid-wide Experiences with inter-region teleport capability not tied to parcel ownership. In the days leading up to the release there was a lot of chatter across the internet boards about making the Ultimate Orbiter and using it to grief. Social engineer people into accepting the Experience permissions request

despite the chatter, Linden went ahead and released Grid-wide Experiences. The Abuse Reports flooded in from all over the grid. Three days later Linden had to pull it and Grid-wide Experiences have still yet to be re-introduced

[Wulfie Reanimator 3,530]

26 minutes ago, Mollymews said:

this capability has to be restricted to the parcel owner of both origin and destination

if it is not then we will see a proliferation, once again, of the Ultimate Orbiter. Social engineer a person into granting PERMISSION_TELEPORT and then sending them to a random region anywhere on the grid . When they come back, orbit them again to some other random region on the grid, and repeat over and over

how likely is this to happen, people doing this to others?

It's as likely to happen as any other type of griefing that currently exists in SL. I don't think that's a good enough reason to add new restrictions to the function, especially something as severe as you're suggesting.

llTeleportAgent can currently teleport avatars anywhere, regardless of origin/destination ownership. Changing the function to fail if the origin/destination has a different owner is a breaking change, and will prevent many (if not the vast majority of) currently existing scripts from working, even Experience ones.

Let's not forget that a piece of land can have multiple Experiences on it, which will be owned by different people, who cannot all own the same piece of land. This means, inevitably, that there are Experiences that may teleport avatars between parcels that do not have the same owner, even if the avatar stays within the Experience.

Even the origin may not be owned by the Experience owner OR the script owner OR the target avatar.

I'm not saying it's impossible, but its implementation will be convoluted and I would rather avoid that at any cost.

Edited Friday at 10:55 PM by Wulfie Reanimator

[Mollymews 4,904]

1 minute ago, Wulfie Reanimator said:

It's as likely to happen as any other type of griefing that currently exists in SL. I don't think that's a good enough reason to add new restrictions to the function, especially something as severe as you're suggesting

this is what Linden thought as well with Grid-wide experiences. It didn't turn out well. Might be different this time, might not be either

this a flaw of classic permissions design. The inability to revoke

not able to revoke PERMISSION_TELEPORT once granted, is up there with PERMISSION_TRIGGER_ANIMATION. At least with animation we can ourselves LSL script a defensive measure at least in stopping unwelcome animations playing on us

i am not sure that there would be way to LSL script a defense against unwelcome teleports. Unwelcome meaning subsequent teleports from anywhere on the grid to anywhere else on the grid

[Gabriele Graves 1,511]

2 minutes ago, Mollymews said:

this a flaw of classic permissions design. The inability to revoke

not able to revoke PERMISSION_TELEPORT once granted, is up there with PERMISSION_TRIGGER_ANIMATION. At least with animation we can ourselves LSL script a defensive measure at least in stopping unwelcome animations playing on us

i am not sure that there would be way to LSL script a defense against unwelcome teleports. Unwelcome meaning subsequent teleports from anywhere on the grid to anywhere else on the grid

Hmmm, I must admit I missed this aspect in my thinking.  I change my opinion, without revocation being a part of the solution, I would not be happy introducing these kinds of changes to llTeleportAgent().  On reflection, I think it should stay as it is.

[Wulfie Reanimator 3,530]

42 minutes ago, Mollymews said:

this is what Linden thought as well with Grid-wide experiences. It didn't turn out well. Might be different this time, might not be either

this a flaw of classic permissions design. The inability to revoke

not able to revoke PERMISSION_TELEPORT once granted, is up there with PERMISSION_TRIGGER_ANIMATION. At least with animation we can ourselves LSL script a defensive measure at least in stopping unwelcome animations playing on us

i am not sure that there would be way to LSL script a defense against unwelcome teleports. Unwelcome meaning subsequent teleports from anywhere on the grid to anywhere else on the grid

I absolutely agree that regular permissions should be revocable and I couldn't believe that's not the case if I wasn't painfully aware.

But that isn't how llTeleportAgent currently works. You cannot teleport an agent that isn't in the current region (and maybe neighboring regions, I haven't tried), so that's not the kind of griefing that can happen. I obviously oppose the idea of LL making it possible to teleport agents from anywhere to anywhere without a way to properly prevent it, and "just leave the Experience" isn't enough because something that disruptive can prevent you from staying logged in long enough to leave the offending Experience, if you even know which one it is.

That is not what I'm advocating for and I cannot even imagine a new type of function that should ever be allowed to do that.

Edited Friday at 11:48 PM by Wulfie Reanimator

[Mollymews 4,904]

1 hour ago, Wulfie Reanimator said:

teleport agents from anywhere to anywhere

i was bit over broad in saying this

the way it worked last time (grid-wide experience) was social engineer the victim to grant permission. Once given then whenever the victim is present on the region with the greifer then orbit the victim.  The greifer could do this to the victim on any region they were both on using a HUD

with grid-wide experience permissions there was a way for the victim to stop this themselves. With classic permissions there won't be (if not tied to parcel owner)

 

as part of this discussion also (which Linden will have internally)

the monetary cost to the company of processing of support cases. The Linden support center manager is going to have a influence on this decision as the remedy (as with other classic permissions abuses) is social governance, there not being a technical preventative measure in place. Boss Linden is going to listen carefully to what the support  center manager will say about this

if the implementation of this doesn't require PERMISSION_TELEPORT and parcel owners can just do it then the support center is going to get support cases and abuse reports also:

like: "I went to this place and I got teleported somewhere else. Is the teleport broken ? Or if is not broken then why are they allowed to do this to me. I thought they had to ask me for permission?"

each of these kinds of support queries/cases has to be responded to by support center staff. What the estimated number of cases might be only the support center team would be able to answer. Same with the estimated monetary cost of the support centre staff doing this

Boss Linden will weigh all this up. Cost/benefit analysis, etc

 

[Lucia Nightfire 1,629]

2 hours ago, Mollymews said:

it has happened before. Linden released Grid-wide Experiences with inter-region teleport capability not tied to parcel ownership. In the days leading up to the release there was a lot of chatter across the internet boards about making the Ultimate Orbiter and using it to grief. Social engineer people into accepting the Experience permissions request

despite the chatter, Linden went ahead and released Grid-wide Experiences. The Abuse Reports flooded in from all over the grid. Three days later Linden had to pull it and Grid-wide Experiences have still yet to be re-introduced

Curious when/where this happened as grid scope experiences were only offered to the few people that participated in the closed beta. There was no public offering.

[Wulfie Reanimator 3,530]

7 minutes ago, Mollymews said:

i was bit over broad in saying this

the way it worked last time (grid-wide experience) was social engineer the victim to grant permission. Once given then whenever the victim is present on the region with the greifer then orbit the victim.  The greifer could do this to the victim on any region they were both on using a HUD

with grid-wide experience permissions there was a way for the victim to stop this themselves. With classic permissions there won't be (if not tied to parcel owner)

Then that is exactly the same as any other kind of griefer attack, way less evil (from an implementation standpoint) than what you described earlier.

We're simply not going to get rid of this problem until LL sits up and provides us a way to revoke all permissions. (It doesn't even need to be a pretty UI like the Experience list. Just a "revoke all permissions" is enough, though I wonder how difficult even that might be.) I do think that the upsides outweigh the downsides, especially when considering the grid-wide attacks that currently exist that don't require any permissions or Experiences.

1 hour ago, Mollymews said:

if the implementation of this doesn't require PERMISSION_TELEPORT and parcel owners can just do it then the support center is going to get support cases and abuse reports

I don't think (and definitely hope) this is something nobody is suggesting. Teleporting an avatar should always require initial permission, absolutely no exceptions.

[Mollymews 4,904]

4 hours ago, Lucia Nightfire said:

Curious when/where this happened as grid scope experiences were only offered to the few people that participated in the closed beta. There was no public offering.

not to pick on Linden as quite a few closed alphas/betas (even with NDAs) often leak

some people (including staff) just don't know how to keep a secret. They tell a friend, who tells a friend, who tells a friend. Each person in their turn promising to keep the secret and not tell anyone else. They can't help themselves either and the secret spreads

 

when I heard about it in the days prior to release, I told someone else also, a then regular SL blogger of good reputation. I mentioned to them that this was going to be a nightmare for Linden, and maybe Linden might listen to the blogger

i actually understand tho why Linden went ahead with the release. A lot of effort and resources goes into these kinds of projects. The call is made to release and monitor what happens. And if the chickens do fall out of the sky it can be pulled

[Mollymews 4,904]

5 hours ago, Wulfie Reanimator said:

We're simply not going to get rid of this problem until LL sits up and provides us a way to revoke all permissions. (It doesn't even need to be a pretty UI like the Experience list. Just a "revoke all permissions" is enough, though I wonder how difficult even that might be.) I do think that the upsides outweigh the downsides, especially when considering the grid-wide attacks that currently exist that don't require any permissions or Experiences.

I don't think (and definitely hope) this is something nobody is suggesting. Teleporting an avatar should always require initial permission, absolutely no exceptions.

on the first, i definitely agree that it would be great if Linden could come up with a way to revoke classic permissions

am sure Linden have looked into it quite extensively. If was me (and it isn't) then I think it would be some kind of immediate region based thing. Like we could  bring up a viewer system window with a list of the scripts currently on the region that have our permissions and we can select those we suspect and press Revoke

this could only work on scripts the region server knows about. It won't be [ at least not easily I think] able to get to copies of a script in somebody's elses inventory. But it would be something as opposed to nothing

on the second, I am just going off the example use cases in the proposal

like able to move an agent outside a parcel, rather than have to use llEject. If a situation calls for a script to apply llEject then a permissions requested teleport is not going to be an effective substitute for this, given that the requested teleport can be declined unlike llEject

moving avatars away from a busy landing point. A permissions request teleport that can be declined in this use case doesn't provide any advantage over llMapDestination

Edited Saturday at 08:35 AM by Mollymews
[ ]

[Mollymews 4,904]

52 minutes ago, Mollymews said:

am sure Linden have looked into it quite extensively. If was me (and it isn't) then I think it would be some kind of immediate region based thing. Like we could  bring up a viewer system window with a list of the scripts currently on the region that have our permissions and we can select those we suspect and press Revoke

this could only work on scripts the region server knows about. It won't be [ at least not easily I think] able to get to copies of a script in somebody's elses inventory. But it would be something as opposed to nothing

i quote myself because maybe the solution for the egregious case is a whole lot simpler. The egregious case is a script in a HUD that somebody else is wearing

maybe the solution is: right-click on their avatar and menu: Block All Scripts They Are Wearing That Have My Permissions

 

edit add: altho I suppose that if this was easy to implement then Linden maybe would have already done it. assuming they have thought of it already, which they probably have

Edited Saturday at 09:25 AM by Mollymews

[Qie Niangao 4,528]

I'd like to hear from @Kyrah Abattoir whether asking permission was intended as part of using llTeleportAgent in place of llTeleportAgentHome to manage which avatars are on the parcel. Maybe? The intruder/griefer gets a choice of fates: "take this teleport or get sent home" might have some use, I guess, but wasn't what I thought was the intent.

Personally, for my usage, I guess I'll just stick with Experiences (if only the permissions dialog weren't "Abandon hope all ye who enter here"), and I really can't imagine asking permissions to teleport, over and over again, at every origin/destination portal object in multiple regions.

While we're discussing relaxing the "owner only" restriction on llTeleportAgent, could someone explain why the function is also verboten in temp-attached objects, yet can operate without dialog in regular attached objects?