Mollymews 4,904 Posted Friday at 09:38 PM Share Posted Friday at 09:38 PM 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 2 1 Link to post Share on other sites
Wulfie Reanimator 3,530 Posted Friday at 09:50 PM Share Posted Friday at 09:50 PM (edited) 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 Link to post Share on other sites
Mollymews 4,904 Posted Friday at 10:28 PM Share Posted Friday at 10:28 PM 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 Link to post Share on other sites
Wulfie Reanimator 3,530 Posted Friday at 10:48 PM Share Posted Friday at 10:48 PM (edited) 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 Link to post Share on other sites
Mollymews 4,904 Posted Friday at 11:05 PM Share Posted Friday at 11:05 PM 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 2 Link to post Share on other sites
Gabriele Graves 1,511 Posted Friday at 11:11 PM Share Posted Friday at 11:11 PM 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. 1 Link to post Share on other sites
Wulfie Reanimator 3,530 Posted Friday at 11:18 PM Share Posted Friday at 11:18 PM (edited) 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 Link to post Share on other sites
Mollymews 4,904 Posted Saturday at 01:29 AM Share Posted Saturday at 01:29 AM 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 Link to post Share on other sites
Lucia Nightfire 1,629 Posted Saturday at 02:19 AM Author Share Posted Saturday at 02:19 AM 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. Link to post Share on other sites
Wulfie Reanimator 3,530 Posted Saturday at 03:25 AM Share Posted Saturday at 03:25 AM 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. Link to post Share on other sites
Mollymews 4,904 Posted Saturday at 07:31 AM Share Posted Saturday at 07:31 AM 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 Link to post Share on other sites
Mollymews 4,904 Posted Saturday at 08:32 AM Share Posted Saturday at 08:32 AM (edited) 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 [ ] 1 Link to post Share on other sites
Mollymews 4,904 Posted Saturday at 08:51 AM Share Posted Saturday at 08:51 AM (edited) 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 Link to post Share on other sites
Qie Niangao 4,528 Posted Saturday at 11:35 AM Share Posted Saturday at 11:35 AM 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? 1 Link to post Share on other sites
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now