Discussion on a change to llTeleportAgent().

[Mollymews]

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]

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 January 15, 2021 by Wulfie Reanimator

[Mollymews]

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]

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 January 15, 2021 by Wulfie Reanimator

[Mollymews]

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]

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]

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 January 15, 2021 by Wulfie Reanimator

[Mollymews]

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]

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]

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 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]

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 January 16, 2021 by Mollymews
[ ]

[Mollymews]

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 January 16, 2021 by Mollymews

[Qie Niangao]

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?

[Kyrah Abattoir]

On 1/16/2021 at 12:35 PM, Qie Niangao said:

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.

To me, presence on the parcel is already tacite permission, you can already unsit people or send them home, NOT sending them home, to me, is a much better alternative that would help in so many situations that don't warrant a full blown experience, or a full blown eject/tphome.

My biggest "game like" case is when someone is bypassing a door by using the "rez->sit->move method". Should an experience really be required to move the person back to the last "room" they were allowed to visit?

On 1/16/2021 at 9:32 AM, 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

I suspect the biggest issue is script-side revocation handling. I can't actually recall any script that was designed to handle a run_time_permission call that isn't the result of the script itself requesting permissions.

Broken content is bad.

But even so, this is just "more" ways scripters would have to fight with the user, and we still, only have 64k.

[Wulfie Reanimator]

37 minutes ago, Kyrah Abattoir said:

To me, presence on the parcel is already tacite permission, you can already unsit people or send them home

...

I suspect the biggest issue is script-side revocation handling. I can't actually recall any script that was designed to handle a run_time_permission call that isn't the result of the script itself requesting permissions.

It shouldn't be hard or even content-breaking to change llTeleportAgent to behave the same way as llTeleportAgentHome, since the latter doesn't generate any permission events.

That said, I still think this is not a good idea. You can't spam llTeleportAgentHome on someone, since the result of the first teleport will generally mean the agent no longer exists on the land. If llTeleportAgent behaved the same way, you could "catch" people into your land whether intentionally or not. Perhaps a throttle could be added or something.

Would it be awesome as a scripter? Yes. Would it be awesome as a user? Probably not. As much as I dislike Experiences as a scripter AND user, that's one area where I think Experiences are a better way to handle teleporting.

Edited January 19, 2021 by Wulfie Reanimator

[Kyrah Abattoir]

It could probably be solved by a slight tweak to how teleportagent behaves "intra sim". Where it doesn't "teleport" you,so much as it "moves" you.

Then you're not really teleporting at all and there is no risk of getting "caught".

[Wulfie Reanimator]

1 minute ago, Kyrah Abattoir said:

It could probably be solved by a slight tweak to how teleportagent behaves "intra sim". Where it doesn't "teleport" you,so much as it "moves" you.

Then you're not really teleporting at all and there is no risk of getting "caught".

What kind of movement do you mean?

Instant position change as with llSetRegionPos wouldn't make it easier for a user to escape a parcel that has a script repeatedly teleporting them to the same spot (or all over that parcel). Physical movement as with llMoveToTarget has issue with taking its time (movement is noticable) and can be blocked by obstacles.

Besides, I'm fairly sure intra-sim teleports are handled "better" than cross-sim ones, but obviously I have no real evidence to show for it.

[Kyrah Abattoir]

I'm not sure I follow what you mean Wulfie, if you can either TP home, to another parcel, or another region... how are you "caught" ?

[Wulfie Reanimator]

10 minutes ago, Kyrah Abattoir said:

I'm not sure I follow what you mean Wulfie, if you can either TP home, to another parcel, or another region... how are you "caught" ?

You fly over the parcel at 4000 meters, or cross a bit of the corner at ground level, and a script teleports you into the lobby of a skybox.

Or a more malicious example:

while (TRUE) { llTeleportAgent(agent, "", trap, ZERO_VECTOR); }

 

Edited January 19, 2021 by Wulfie Reanimator

[Kyrah Abattoir]

6 minutes ago, Wulfie Reanimator said:

You fly over the parcel at 4000 meters, or cross a bit of the corner at ground level, and a script teleports you into the lobby of a skybox.

Or a more malicious example:

while (TRUE) { llTeleportAgent(agent, "", trap, ZERO_VECTOR); }

 

 

I swear I'm not trying to be obtuse but I don't see how it is "more" inconvenient than being Teleported home.

As far as I'm concerned my trip is interrupted in both cases, the only difference is that in your case I have to teleport somewhere else manually.

(I'd love a viewer modification that silently teleports me back to the last "safe" parcel i crossed before being teleported home by the way)

[Wulfie Reanimator]

2 minutes ago, Kyrah Abattoir said:

I swear I'm not trying to be obtuse but I don't see how it is "more" inconvenient than being Teleported home.

As far as I'm concerned my trip is interrupted in both cases, the only difference is that in your case I have to teleport somewhere else manually.

You have a point there, no big disagreement on that.

[Kyrah Abattoir]

An improvement on llTeleportAgent could be to silently discard a teleport that won't move you more than 1m.

(If anything, to avoid people using it as a really bad move2target)

Edited January 19, 2021 by Kyrah Abattoir

[Gabriele Graves]

Teleport Home is a one time thing only, teleport anywhere (even intra-region) at anytime for as long as a land owner wants is a completely different beast altogether.
Unseating only came along to stop people being able to defeat being ejected or avoiding being teleported home.

Nothing in either those things suggests that land owner should be able to teleport people anywhere they please at any time when on their land.

It isn't tacit permission.  Nobody can assume permission from others, it must be granted explicitly or it isn't permission regardless of how badly something is desired.

The more and more we go down this road, the more disturbing it is that some just cannot understand this simple concept and it only cements in my mind that these are exactly the wrong people to be giving any permissions to even explicitly.  It's even laughable to talk about trust at this point.

Edited January 20, 2021 by Gabriele Graves

[Wulfie Reanimator]

2 hours ago, Gabriele Graves said:

Teleport Home is a one time thing only, teleport anywhere (even intra-region) at anytime for as long as a land owner wants is a completely different beast altogether.
Unseating only came along to stop people being able to defeat being ejected or avoiding being teleported home.

Nothing in either those things suggests that land owner should be able to teleport people anywhere they please at any time when on their land.

It isn't tacit permission.  Nobody can assume permission from others, it must be granted explicitly or it isn't permission regardless of how badly something is desired.

The more and more we go down this road, the more disturbing it is that some just cannot understand this simple concept and it only cements in my mind that these are exactly the wrong people to be giving any permissions to even explicitly.  It's even laughable to talk about trust at this point.

How exactly do you justify llTeleportAgentHome when you say things like "permission must be granted explicitly regardless of how badly it's desired?" I desire you off my land, but the same "no consent" argument applies there too.

The more I've thought about Kyrah's point, I don't see much (negative) difference between what we have and what we could have. Any malicious use of llTeleportAgent on the owner's land would have the same outcome. You'd have to teleport home, which is where you'd end up today.

It would obviously mean that scripts could only use llTeleportAgent to move avatars within the current parcel, to prevent the most significant abuse (intentional or not) such as ping-ponging or the slow cross-region teleports.

Edited January 20, 2021 by Wulfie Reanimator