While I was moving it, I noticed that this is marked as a bug. Should it perhaps be a "new feature"? It's not at all that I want to lower the priority of this... just that as I see it, bugs are when the system doesn't work as designed, and features are when it does but you want to change the design. Thoughts?

• The client itself simply ignores all llTeleportAgent requests for some period of time (10s, at least) after the completion or cancellation of any teleport, to prevent teleport loops.

• Only the landowner or a member of the land group can issue llTeleportAgent for another person.

• The user can set their preferences to allow, ignore, or prompt for teleport requests.

This would be less disruptive and more useful than any imaginable fix to llMapDestination.

the 10 second buffer is something I don't like. And only the landowner..

llMapDestination can be used if you're not the landowner. Replacing it with something that requires that is not a replacement at all.

llTeleportAgent is a wonderful idea, but it won't replace llMapDestination. It will suppliment it.

Incidentally, in my experience, simply teleporting out of the region (if even possible) is not enough to stop the spamming. The map spam will continue to follow you until relogging. Relogging seems to stop the map spam while the object remains rezzed, but...and this is where it gets really screwy...if the griefer then takes the object back into inventory and then re-rezzes it, BAM, it starts spamming again. The effect of this is that it enables griefers to prevent an individual, effectively, from accessing their account at all, should they choose.

I see no reason why the function cannot be limited to once per event. I do not know of any legitimate reason why it would need to be called more than once per event. Possibly I could see someone wanting to send a map teleport to multiple people, so perhaps limit it to once per user per event, but even then, it makes little sense to allow this exploit to continue.

The map spamming does indeed stop when you teleport far away. And no amount of re-rezzing can make it spam someone who is not currently in the sim.

Had your comment proven true, I'd have moved this to security.

That being said, I do know of a situation in which an individual did continually receive spam after relogging to a different location. I do not know why this occurred, and have had difficulty reproducing it. However, one device that does this claims in its manual that the target must remain logged out for 30 minutes. Perhaps it only occurs if they log out from the region where the attack occurred and relog directly to another region, rather than teleporting out first and then relogging.

Also, does it depend on how one constructs the loop to continue sending the llMapDestination() calls?

Incidentally, the move to the new behavior for llMapDestination() in 1.20 RC6, where a small card is popped up instead of the map, still allows for this behavior, with the added problem that the cards steal focus, thus preventing you from typing or interacting with the world.

I'm surprised there's not been a patch for this in Nicholaz' viewer already.

If that's the case, a differentiation between sim-sent and landmark'd map window open could be made, and a sort of throttling implemented. But no muting or the like.

No, I believe the solution lies sim-side. If Day Oh is right, the only performant solution will be the suggested script flag that turns off as soon as an event calls mapdestination, and gets set again once the event is done. So yeah, 1 call per event. I pondered legal uses and can't think of any product that's being commonly used that would be negatively affected. Yet there are several map spammers spread and for sale.

I'm not going to discuss possible techniques for getting around server-side throttling systems in a public forum, but make no mistake there's plenty of them.

Client-side, yes, you could throttle the map message calls it acts upon. Implementing both solutions would probably be the safest idea.

And my point, which is getting lost here, has little to do with whether it could be implemented in the server, but that it ought to be implemented in the client right now because WE don't have the server code, but we DO have the client code.

Well, when it comes to inclusion of a fix into the SL client via 3rd party patch..that will take as long as LL doing a sim-side fix. Sadly enough their latest stance on 3rd party patches is, that they will be looked at, but inclusion anytime soon is unlikely due to QA tests and such. I think a patch Nicholaz submitted found its way into the client months later, and AFAIK, wasn't even close to his solution.

But yes, it'd be worth to make a 3rd party patch for this for inclusion into viewers like Nicholaz or CoolViewer. I will peek at the viewermessages later, but my solution is bound to be an ugly hack out of habit, so I can only suggest any client wizzes here to whip something proper up.

Also, it depends on whether the new llMapDestination() behavior implemented in 1.20 RC6 is retained or not. In that client, a small parcel landmark card is popped up instead of the map. It is certainly easier to limit those (perhaps even just not accepting another llMapDestination() request while a card is already up). Unfortunately, it might be more difficult to deal with the map pop up unless the client can tell the difference between popping up the map due to llMapDestination() and the user pushing the map button.

Also, because the client doesn't know whether the llMapDestination() calls are coming from the same touch_start() event or not, it can't differentiate between being map spammed compared to clicking on a legitimate llMapDestination() teleport object, then realizing you clicked the wrong one, and then closing the map and clicking on the one next to it.

Of course...and I'm sorta typing as I think here...if the client can recognize whether the requests are coming from the same object or not (and I don't know whether it can), it would be easiest to implement in that manner, so that you could put a really long throttle on how often an individual object could call the event. Maybe even have it so that three llMapDestination() calls in less than 10 seconds cause it to permanently ignore further calls from that object.

That being said, all client-side options are still rather messy fixes compared to a simple limiting of the function itself to one call per touch_start() event.

Therefore, regardless of the version, the client CAN distinguish between llMapDestination() and clicking on a button.

So getting the client to throttle it isn't hard, and will solve the worst part of this problem, and therefore it should be done.

A logical followup would be to expand the packet to include the UUIDs of the requesting object and owner, so you could add a "Mute" and "Report Abuse" button to whatever pops up.

I wouldn't be surprised if the packet already has the UUID of object and owner. I know many others do (don't have a lot of experience with looking through packets, but had to examine some SoundTrigger packets the other night to try to solve a nasty bug and they include the UUID of the owner, object, and root prim (if the sound trigger is coming from a child prim)).

llMapDestination() is a cool function, it's sad that some people's reaction to being given a cool tool is to find ways to use it to create objects that ruin other people's enjoyment of SL.

Anyways, I can barely script weapons without blowing myself up, perhaps someone with more coding experience could draft a patch?

I really think that once griefers can't block people out by continuously popping up maps or landmarks then there will be no more incentive to use this particular attack.

See: https://jira.secondlife.com/browse/VWR-2060

Muting should be possible, too. It seems like you can't mute enough things in SL. And half of the blue notification windows don't contain any information about who (or what and who) initiated them, making it near impossible to track down abusers. Client-side throttling sounds like a good idea, too.

If low frequency requests like this could be transmitted over TCP, instead of UDP, that problem would be solved. You could also run text chat over TCP and get rid of the out-of-order chat problem.

Well I guess i had better comment on this issue... because... well... I'm sure you know...

About 18 months ago I was developing a stargate that would give you the map as you walk though it so that you dont have to stand in front of it and touch it, which is inconsistant with the way a stargate is used on tv / movies.

As I didnt have my own stargate brand back then I build a DHD (dialing device used on the tv show) that would wait until you walk though the stargate before it would give you the map.

I discovered that the focus on the viewer MAP page is badly behaved and can clear the map if you are pressing buttons when the map appears. ie. walking though the stargate.

My solution to this problem was to keep sending the map while the person was moving, as movment would indicate they are still pressing buttons which are likly to mess up the map's destination. I fell off my sky platform while testing this work-around and got spammed with maps all the way down to the ground. More testing found a nice balance to ensure the map holds at the correct destination without spamming. In fact most people dont even notice the map was sent mroe than once. See VWR-2060

The point I am making here is that sending the map more than once has both good and bad uses. It is important to remember breaking good content to stop bad content when the good content was created within the documented specs is unfair to people who paid money for those products. We might as well ban trees so people cant poke them into your house from neighbouring parcels of land!

I vote NO. I would like my DHD, Stargate, Quantum Gate, and Quantum Portal to remain in working order thanks. As do all the other creaters and customers who would suffer from broken content if this jira was implemented.

The lindens are quite good at breaking spammers by use of mute functions on the viewer. There is no need to change the documented behaviour on the server of a long established function when other options are available. Especialy a function that has other much more serious issues that need to be addressed. Such as the inablity to teleport above 1024 meters high, or the fact the focus is not on the Teleport button, rather the region name, resulting in lost destinations. See VWR-2060 & VWR-7331

This issue should be filed under VWR as it can be resolved in the viewer. Any attempt to resolve it at the server level will break content.

Darling Brody

ps. Please be polite and on topic with any replies directed at me.

****************************************************************************************************

As you can see, the problem isn't just annoying... it would completely block you to "play" Second Life. So resolve this issue NOW (i don't care how... even eliminating the llMapDestination() function temporary) until they provides a proper solution or "tools" to save your "soul" is mandatory: break single contents is less important than blocking an user to enjoy the whole rest.

If fixing this would break legitimate content due to bugy behaviour of the function, then said buggy behaviour should be fixed too. Please file your own jiras on any other potential problems with llMapDestination, and link them to this one. I'll be glad to mention them in the description as prerequisites.

Moreover, the individual claiming that this will break her products also makes and sells a product that contains a map spammer (among other things), which makes me a bit skeptical that concern over broken content is really the issue here...or maybe I should say that it's a matter of which content would be broken.

One potential problem with fixing this client-side is that the client is still receiving a high volume of packets from a scripted object in-world telling it to open the map. Thus, the client is still going to wind up slowing down a bit from this. Additionally, placing the throttle clientside could mean that having a map spamming object in a region would prevent another legitimate object from being able to open the person's map.

However, being able to mute the map spamming client-side would be a nice thing, even better would be for one to get a popup window saying "XXX, an object owned by YYY, would like to open your map" and then give the user the option. I really don't understand why the ability to essentially control the function of another user's client is not something that requires any permission. As it stands right now, one doesn't even have any indication of who even used the attack on them. As such, filing abuse reports is completely impossible, allowing people to grief with impunity.

That being said, the best reason for fixing this at the server level, as opposed to a client-side fix, is that it may very well be simpler to do it that way. A server-side fix allows for only the offending script to be throttled, and would prevent both the server-side lag caused by all those function calls and the client-side lag caused by receiving multiple packets. A server-side fix is also more likely to be able to differentiate between "good" and "bad" uses since it's looking directly at what the script is doing rather than the end results, and thus makes it easier to find a solution that prevents this function from being abused while still allowing legitimate uses to continue.

And let's all remember that this bug can be truly nasty when abused. The user has no warning, is completely unable to interact with anything around them, cannot even type, due to the fact that the map steals focus. They cannot even pull up a landmark to teleport out. They are essentially frozen. Their only options are to teleport home or to log out and then log back in to a different location. If this occurs in their home location, then they must log out. Also, teleporting to another sim still means that all of the llMapDestination() requests that are still stuck in the queue will still pop up, so if the user spent too much time in the original sim, they're still going to have the map popping up for a while. Relogging does appear to at least stop the queuing problem. Of course, even after a relog or teleporting home and going through a million map popups, one still CANNOT return to the region where this happened until the initiating object is removed. If there is no autoreturn in that region, this means that the user is effectively shut out from using that entire region.

And there's still the problem that the user has no clue who did this to them, and has no way to effectively file an abuse report. One moment they're walking along, the next moment their map is popping up and won't go away and they can't even type anything to their friends and have to log out. Hell, if this happened without it being an attack, there wouldn't be any equivocation here, people would be DEMANDING that Linden Labs fix this bug. I still don't understand why people get upset when the client is buggy and crashes on its own, or when servers crash without warning, but somehow it's OK when it's a glitch that allows people to do it to each other, because there's content that might be broken....and we all know which content we're talking about, and it isn't teleporters or other legitimate uses.

Linden Labs has been talking lately about the so-called "First Hour" experience. I can tell you that if I had been hit by an attack like this as a noob, I probably would have logged out an never returned. Stupid pointless script-kiddie griefing attacks like this are a major hindrance for SecondLife as a platform for the future. Imagine showing off SL's capabilities to other IT people and getting hit with this while giving a tour. Imagine new users building in a sandbox until some moron decides he needs to get his kicks and uses something like this on them. If LL is wondering why they don't get more Abuse Reports about it, they should consider that it may be because attacks of this nature appear as if they were just bugs in the client. A lot of people aren't even aware of it. I also wouldn't be surprised if a lot of people left SL because of it. But hey, I'm sure that LL's recouped enough money from Lindex sales from the people who sell these devices. Goodonya, Linden Labs, always willing to turn a blind eye as long as money's changing hands.

By the way, any chance we could get a Linden, preferably G-Team, to comment on the ToS legality of creating, marketing and selling, and using devices specifically designed to spam another user's client with maps as described in this ticket? I cannot believe that Linden Labs really condones this stuff (I was being facetious in the end of the above paragraph). My guess is that they simply haven't come up with a good fix yet, either server or client side, that solves the problem without breaking content. In that event, I do wonder why they don't simply disable map spamming objects as they are reported. It's a stopgap solution at best, but it does allow everyone to be happy until a real solution can be found. Map spammers can be taken care of, and legitimate content can be left alone.

Unless, of course, we're going to hear from people claiming that map spammers are legitimate content?

Technically, there is some permission involved, in that, if the spamming object is not attached to the victim, then llMapDestination can only be called from a touch event. Hence, it does require some interaction with the object.

The problem is that spamming scripts can simply trap the script in an infinite loop

while (1)
{
llMapDestination(....
}

etc. And do it endlessly.

There are many more issues at hand here, like the unmuteability of it (another issue) the complete absence of information as to the source (should be another issue, but noone has made it yet), but the primary thing THIS issue is about, is removing the ability to spam endlessly, by placing a limit on the number of calls per event. Hence, the user could only get one map each time they click.

With regards to specific server-side script limits, why not make it, say, 4 times per touch_start event? That way if it needed to be called multiple times for some specific device (such as a teleporter), it would be able to do so. I understand that some people feel that it may need to be called more than once, but 4 times ought to be enough. If 4 times isn't enough, I'm sure 5 or 6 or some other small but reasonable number could be found. The point being, of course, that we put a clamp in there somewhere.

One other option might be to simply prevent the function from being called inside any sort of loop event, such as while, for, do while, etc.

Another thing that should be remembered is that what we are discussing is specifically applying to touch_start() events triggered in objects not attached to the user. As such, attachments will not be affected by these proposed changes.

The thing is that this is just a variant on the old notecard/texture bombing technique, and that was solved simply by throttling popups and warning you that it happened. There's absolutely no reason not to similarly limit the actual popup to some small number of popups per second (or per event, but the whole touch event limitation on this call is silly in the first place), with a longer period of throttling when that limit is exceeded. Once that's done it won't be useful as a griefing tool, and people won't bother making map bombers any more than they bother making notecard or texture bombers any more.

In addition, the source of a map event should be added to the protocol so people can locate, return, and mute sources. But if that takes some time to coordinate, there's no reason not to do the throttling NOW.

Please dont post to the JIRA when angry. One bad experience is not a good reason to break every single map teleporter in SL. The people who own and use those teleporters will not appriciate it.

@ "4 times per touch_start event?"

what about orentation devices. Where you have to get to a location, and when you do you are given the next map destination. These can send many different destinations over an extended period of time.

What about when someone walks through a stargate... and then walks though again. Does the gate fail to work the second time?

@ "prevent the function from being called inside any sort of loop event"

That would totaly prevent the script from looping while waiting for the correct time to send the map in the Touch even. Such as the DHD's I have been selling for the last 2 years. (as described in my above post, which have been on sale in my shop for longer than any other items!)

@ Argent Stonecutter

Your right. As I said in my post, Linden Labs are doing very well with their server side throttles and client side mutes. That is all this is needed here.

Darling Brody

PS. Thanks for the personal attack. Good to see the JIRA being used to solve problems without biast or personal vendetters!

Stargates would really benefit from llTeleportAgent. HAving to use llMapDestination is a pretty annoying hack.
I'm not sure how you can make the script loop until the corrct time. Unless the correct time is a static value, it doesn't seem like that's going to work - you can't recieve inpu when trapped in a loop.

Of safeguards were put in place, like throttling of excessive/abusive use, ability to trace the sorce, and ability to mute spamming, then I'd see no problem with removing the restriction that it only b called from a touch event.

As to personal attacks, you're clearly showing a lot of bias here yourself. Lest we forget, the Quantum Core had a "crash" mapspammer module in it last I looked.

From Ms. Brody's own Quantum Core Documentation:

[Banish]
Description: Locks the victims MAP page open to Help Island. It immobilises your victim's ability to interact in the SL environment. Their only escape is to teleport home or relog to another region.
Type: Passive, Reusable as Active. [Anonymous]
Range: Region Wide
Duration: Victim must remain logged out for 30 minutes.
HUD Usage: [Banish] <ALL/Name> [GO]
Chat Usage: /666 Banish <ALL/Name>

The "Crash" module is described as:

[Crash] <---- disabled by Linden Labs after complaint by Kerik Rau
Description: An attack that can't be muted. It immobilises your victim's ability to interact in the SL environment and will crash them if they do not relog to another region.
Type: Active
Range: Region Wide
Duration: Stops when victim has logged out.
HUD Usage: [Crash] <ALL/Name> [GO]
Chat Usage: /666 Crash <ALL/Name>

So I can see why one might easily confuse the two, since both modules are intentionally designed so as to allow one user to force another user to either leave a region or relog. Now, if the ToS were actually enforced to the letter, this ticket might not be necessary, since section 4.1 of the ToS states:

In addition to abiding at all times by the Community Standards, you agree that you shall not:....

(iii) take any action or upload, post, e-mail or otherwise transmit Content that violates any law or regulation;
(iv) take any action or upload, post, e-mail or otherwise transmit Content as determined by Linden Lab at its sole discretion that is harmful, threatening, abusive, harassing, causes tort, defamatory, vulgar, obscene, libelous, invasive of another's privacy, hateful, or racially, ethnically or otherwise objectionable;
(v) take any actions or upload, post, e-mail or otherwise transmit Content that contains any viruses, Trojan horses, worms, spyware, time bombs, cancelbots or other computer programming routines that are intended to damage, detrimentally interfere with, surreptitiously intercept or expropriate any system, data or personal information;

Additionally, the "Amber" packet spammer that sends thousands of sound packets per second to a user's client probably violates an additional subparagraph:

(viii) interfere with or disrupt the Service or servers or networks connected to the Service, or disobey any requirements, procedures, policies or regulations of networks connected to the Service;

I think that uploading content that is designed and marketed as being intended to force another user to relog would probably violate several of these subparagraphs. I mention this specifically to show that one reason why it is necessary to enact limitations on llMapDestination() that could potentially damage content such as teleporters is because Linden Labs has not disabled content that clearly violates the Terms of Service.

So here's the choice, as I see it:

We can place limitations of some sort, whether it be serverside throttling, limiting of function calls within an event, clientside muting, etc, with the understood risk that it might damage or break certain content such as teleporters.

Or Linden Labs can take a more active role in disabling and deleting content that uses llMapDestination() as a tool to disrupt and destroy other users' ability to enjoy SecondLife in violation of section 4.1 of the Terms of Service.

Now, personally, I'd prefer the first option. It is impossible to police each and every device that might contain content like this, and it's easy enough for it to be scripted on the fly. Thus, by crippling the ability to abuse the function for griefing purposes, the problem should be solved using the least invasive methods and utilizing the least effort. After all, by placing limitations on the function that, let's face it, should have been there from the beginning, we're attacking the problem at its source.

However, if the concern that this fix might break content is so great, then maybe we really should consider the second option. That way, teleporter makers such as Ms. Brody won't have to worry about their teleporters being broken, and this function will continue to work as it always has across the grid. Unfortunately, it does mean that LL would have to be much more active in removing these products, but I don't think it would actually be too difficult. It won't stop devices that are scripted on the fly, unfortunately, but it would stop any script kiddie with a couple of bucks from being able to purchase products that carry out these attacks.

So I'd say that we're faced with a choice here, either the function gets nerfed or the objects that abuse the function get removed.

There is nothing biast about not wanting your products to be broken by a poorly implemented fit when there is a better way to fix the problem that will not effect innocent objects.

I am _SURE_ you dont want to break the products being made by all those other innocent creaters who are yet to find their way to this JIRA. By all means banish the banish, but dont banish the work-arounds being used by other products to fix issues that should have been fixed years ago.

It __IS__ possible to disable map spammers without breaking teleporters. As I have said several times, a simple throttle on objects sending too many of them in too short a time will get the job done. We can have our teleporter cake and eat our spam free login too.

Until the map focus is fixed teleporters will need to send the map more than once to avoid having the region name blanked out by mistake.

The important thing is to fix things in the correct order so the removal of one thing does not rending another broken. So how about showing your community spirit and put up a vote on the related JIRA issues about the incorrect focus on the map page? Once that is done there will be no opposition at all to any limitations you want to put on the map.

I think that you are right that a throttle may be a good first step, although it is important to remember that a clientside throttle still leaves a laggy looped mapspamming script running, and still involves thousands of packets sent to the viewer, even if it is blocking the map from popping up on each one. However, a client-side throttle is a good start since it is probably a stopgap measure that can be put in place the fastest. Once that is in place, then yes, it makes sense to look into ways to prevent legitimate creators from having to call the function more than once, such as those discussed in VWR-2060. After that, then it makes sense to consider clamping the function to being called once per event, which fixes it server-side as well. If it takes too long for that to happen, the option to mute map spam should also be considered.

I don't know then if the answer is to open a second ticket, in the VWR category, asking for a throttle on map packets?

As for VWR-2060, it is not apparent what the exact cause of the problem is. Torley's repro makes it sound as though not all of the information is being conveyed in the packet, but others seem to believe that the problem is user input clearing the map corrdinates. One solution offered for the latter problem would be to shift focus to the Teleport button, which I believe is not a very wise idea, as it would not only make the problems discussed on this ticket MUCH worse, but would also cause problems even for legitimate uses of the function. I cannot support any solution to SVC-2060 or related problems that involves automatically shifting focus to a button that takes default input from the Enter key. That is simply bad practice and will make all problems worse, including potentially the problems in VWR-2060 if the information on the destination coordinates is still not sent correctly.

So I think that the best roapmap towards a solution to the issues with llMapDestination() would be as follows:

1. A Clientside throttle on map packets.

2. A solution to VWR-2060 (currently imported but unassigned).

Once the function does not have to be called multiple times for legitimate use:

3. A server-side clamp to 1 (or some other small number) llMapDestination() call per touch_start event.

Note that fix 3 would only apply to non-attached objects, so teleporters that use attachments for llMapDestination() would not be affected.

Finally, in the mood of community spirit, perhaps Ms. Brody would be willing to issue an update that removes several thousand map spammers from current use? I really don't see any legitimate use to continuing to sell, promote, and support their use, certainly it adds nothing of value to the SecondLife experience.

But the throttle would make continued use of map spamming objects worthless to the griefer, existing ones would stop being used, and future ones would not be made. That would pretty much solve the problem. A few more objects spewing ludicrous numbers of updates wouldn't be noticed among all the badly written animation scripts, non-physical animators, particle generators, and everything else out there.

I do not support a 1 map per click limitation.

For something like a stargate I have watched people walk though more than once. Being able to send more than one map is a nesessaty for existing content. However there is no reason why the number of maps per second cant be limited. (or per 10 seconds, or whatever time period you want to put on it)

Darling Brody.

However, Darling does make a good point in that a server-side fix has the advantage of working for all client software versions, and thus there would be no required update for it to work.

In terms of limiting the number of maps per second, one option might be that if if it sends more than, say, 10 maps in 5 seconds, the script has an automatic 10-second sleep, and the touch/touch_start() event is effectively "reset" such that the object would need to be touched again to send more scripts. I think that there still might be room to add a hard limit of 20 calls per event to prevent people from trying to get around the throttling by simply slowing down the spamming. Obviously, the exact numbers could be changed, but the basic concept should still be sound.

"A few more objects spewing ludicrous numbers of updates wouldn't be noticed among all the badly written animation scripts, non-physical animators, particle generators, and everything else out there."

Sadly enough, you are very much correct on this. The great thing about SL is that the simulators will run scripts coded by anyone. The bad thing about SL is that the simulators will run scripts coded by anyone. C'est la vie.

Client side throttling needs to be in place topo, like not allowing an object to open your mapo more than once every 5 secs, and adding information on the source of it, and a mute button.

warkirby: There are particle scripts that call "llParticleSystem()" rapidly, to do things like change the colors of the particles or make them react in real-time. Or just because they were written by an idiot.

Maybe you missed my opening post here. I make my own stargate and an add-on DHD for other stargates, they both will give the map when you walk though the gate, not when you click on the puddle of water. I have watched people walk though a second time to get a second map. and there should be nothing wrong with that. it is expected behaviour to get the same result when you repeat an action.

This is also how I discovered that pressing the forward arrow clears the map destination as it is the button people are pressing when the stargate map comes up. It is also why I sent a map 3 times in 1.5 seconds to give people time to react to the map being up and to stop pressing buttons that clear the destination due to stupid focus choices.

@ WarKirby Magojiro

There is a similar clamp on the number of IM's that can be sent from all the objects owned by a person in any one region. Basicly it lets you send xx IM's in yy seconds. if you go over that you have to wait zz seconds before you can send another one. Every time you attempt to send an IM while the cap is active you reset the timer again and have to wait longer. An approch like this with a sensable number of MAPs will never effect objects that are sending maps for the purpose of teleporting, while blocking objects that are sending maps to bother people.

@ Vittorio Beerbaum

It is a two step solution. The region needs to limit the number sent over a time period, and the viewer needs to let you know who sent it and allow you to block them with MUTE just like anything else.

In fact the MUTE option needs to be fixed. All packets should include an origen, and the mute should be applied to all packets, not just the ones the lindens think of after someone abuses it.

@ All

However there are bigger issues to be fixed at the moment. MONO scripts are crashing out with stupid C# errors and breaking content. LSL script memory space is leaking so that previously well behaved scripts are crashing with memory errors. Their is currently no reliable scripting platform. Honestly, who cares if a few people hanging out in combat regions gets spammed when every other scripted item is going into meltdown. There is a lot more to SL than combat. Lets leave this issue on the back burner while we get a stable scripting platform again.

Darling Brody.

2. Griefers don't restrict their behavior to combat sims.

3. Stopping the spamming in the client won't take any resources away from fixing LSL.

The linden dev team isn't just one person, and they're quite capable of working on multiple things at once, so stop trying to deflect attention away from this issue.

As Argent and WarKirby have already noted, this has absolutely nothing to do with any notion of "combat." The problem with this exploit is that it prevents a user from being able to interact with SL unless they teleport home or relog, and prevents the user from returning to that region until the item is removed. The use of llMapDestination() for these purposes is a clear violation of the ToS and CS, and one could even make a very good case that uoloading and distributing content that is intended to be used for this purpose may also be violations of those rules. SecondLife cannot be a successful platform for design, programming, and gameplay when there are easily exploited bugs that allow one user to so thoroughly ruin the experience for others.

Darling, you have the ability to remove several thousand map spammers from SecondLife yourself with a single update to one of your products, and this would obviously not cause any damage to your teleporters, nor would it require waiting for LL to fix other things first. The fact that you have chosen not to do so makes me seriously question whether your concern here is to preserve your teleporters or to preserve your other product that exploits this bug to harass other residents.

Several people have taken a good bit of time to try to come together to work out methods for fixing this serious exploit, and we have made a lot of effort to try to take into account the concerns that have been voiced so far over teleporters. We have put in this effort because we believed that these concerns were voiced in good fath to prevent breaking content, but when the response to this effort is to hear the old "but there are other bugs to fix" canard brought out is very frustrating. It does not add anything constructive to the process, and strikes me as no more than a stalling tactic.

That is not how you use a stargate. You press the buttons on the DHD to dial an address, and then you walk though the gate.
You really need to go watch the TV show before telling me I have done it wrong, because there is no break to the flow in the stargate I have made.
It operates exactly like the TV show, and works within the documented behaviour of the function.
Therefore I say "NO" to this JIRA, I should not have my stargate broken. And I speak for the litteraly hundreds of people who have purchased them from me over the last 2 years. Last month alone I sold 70 stargates!

Having just read Vittorio Beerbaum comments. I find myself in disagreement. This is not a BUG as nothing is broken. It is in fact a new feature, in that you want new behaviour to be imposed on the existing documented behaviour of a function. i didnt change it, but I will change it back to feature request if I see it marked as a bug again in the future.

Darling Brody.

This would:

1. remove the potential annoyance by an always-focusing window
2. Would be actually easy to implement into the client-side
3. Would not break any in-world content except the one used to grief, as normal systems rely on you actually using the teleport mechanims of the map window before moving on (which closes the window, so the client'd be ready for the next destination in the tour system)
4. minimize griefing potential. the worst that can happen is that you have to take the map window, shove it out of the screen except for a corner, and continue normally. Or take your time finding the offensive object, or autoreturn unknown things from your land, etc.

What Gordon did, in changing the ticket status, was simply update it so that LL understands that we're asking for them to add the new features necessary to prevent this function from being used as an attack. In other words, we're asking LL to do something, rather than to remove something. The most important thing that the LL devs want to see when they read this, after a description and reproduction, is an explanation of what we want them to do. That's really the key to getting things to happen. What Gordon did is clarify to LL that we want them to add features to stop map spamming.

@ Darling:
As I mentioned earlier, you have the ability to remove thousands of map spammers from the grid with a single update to one of your other products. The fact that you refuse to do so, not to mention the fact that you distribute a product containing map spamming attacks in the first place, indicates to me that you approve of their use and that your concerns here may have more to do with the continued ability for your customers to use the map spammers in your non-teleporter products.

@Chalice:

That's a decent stopgap solution, and truthfully the map window shouldn't be stealing focus in the first place. Hell, if the map window weren't stealing focus, user control input wouldn't be able to cause the problems seen in VWR-2060. As I understand it, you are proposing that llMapDestination() only be able to open the map window to a specific destination once, but not change it if it's open, right?

The only problem I can see is that it still would leave the user unable to use their map, but I would agree that it is a good stopgap solution that can be implemented quickly. However, I wonder about whether it would address the concerns raised in VWR-2060 where they say that they need to call the function twice or more for it to work properly. Or would the script still be able to change the map destination, just not allow it to take focus?

The real fix for all teleporters is to implement a properly limited llTeleportAgent and stop trying to turn llMapDestination into something it's not... and fix the attack enabled by llMapDestination. Fixing an exploit like this is higher priority than trying to maintain an incomplete implementation of one particular teleport mechanism in one particular product.

Show stopper is for when content is broken. Nothing it broken.
BUG is for when something is not working as documented. llMapDestination is working as documented.
New Feture is when you want to change or add something. In this case, you want to change something. This is a "new feature" and should not get the same high priority as BUGs which really do break content.
It is you who has had a negative personal experience with this issue. That dosn't make it a show stopper or bug for the rest of the people in SL. Sorry.

@Chalice Yao

That dosnt work. If you close the map, it will open again. that is the weapon this jira wants to stop. If I understand your solution that will not stop it.

Also, the workaround for maps not holding the destination properly requires the ability to send another map while the map is open to make sure it is showing the correct location.

Now if you had something like "a minimized map will not open full page again" then someone who is under attack could minimize (not close) the map to stop it.

This is similar to what most people do anyway. The just move the map off to the edge of the screen where it cant get in the way anymore.

@Argent Stonecutter
I am offended that you would tell me to downgrade the functions in my product so you can have your fix

Why should I downgrade my product when I CAN give people the map as they walk though by using the documented behaviour of the function? Why should customers who purchased my stargate for this function have to loose it?

This is not an exploit. It is not a hack. My stargate is based on the documented behaviour in the LL wiki.

I represent hundreds if not thousands of people who do not want their well behaved innocent items broken. By all means block the weapon, but do it without breaking other stuff. That is why we have comments on the JIRA, so people can point out that the orignal poster didnt take all items into account with their suggested fix.

I am simply arguing that the throttle needs to take into account ALL legitamate uses of llMapDestination, not just the behaviour you dont like.

It has been made clear that server throttles, viewer throttles, or focus changes can resold this issue. There are solutions available that will not break content, or nerf the work-arounds being used to other issues with the map. (see my previous posts for links)

llTeleportAgent is not a fix for two obvious reasona: It will not make existing content work without the creaters rescripting and distrobuting the items. Also it dosnt exist, so it's not a solution at all!

@ ALL

Some people have been dismissing my opinion as being biast. However I am the most unbiast person posting here. I thought it was obvious by my opening post, but I think I need to make it more clear.

1) I make teleporters based on llMapDestination.
2) I made a map spammer based on llMapDestination.

This means I have a foot in both camps. ie. unbiast!

NOW, lets examine what I have said here:-
Q:Did I say dont fix it?
A:NO I didnt! I just said, dont break other innocent items when you fix it. Then I explained what behaviour needs to be retained to avoid breaking innocent items.

So I respectfully ask some of you to gett off my case!

Darling Brody

So, no, this is not a problem of me, because it affected me (i would have the right skill to defend myself), but it is a major problem that can affect anyone in any moment, including you.. and you can't do anything to "block" it.
It wouldn't be a bug if you are referring to the correct term, but is a feature exploit so it doesn't require a "new feature", it does require a FIX and an immediate fix. Since it is "dangerous" for the reasons i've explained above, even a fix that would corrupt your products is acceptable until they'll find the correct way do adjust it.
If i find an exploit in the texture retrieving key (do you remember eh?), it works as descrbed (ex llGetPrimitiveParams) until someone finds the way to abuse/exploit it to steal someone else textures, so they will BLOCK it and correct/add the documentation.
If i find an exaploit in the login procedure to log with someone else name, they will block the login until they will find the solution. So actually the correct step is: blocking part of this function (introducing a throttling), potentially wreck your scripts (because your script are less important than the resident experience) and then after find (eventually) a better solution.

How-To : remove a spammer on your estate
-------------------------------------------------------------
1) Turn off scripts using estate tools. The maps will stop, so you can find the offending object.
2) Return all objects that do not belong to you or other land owners.
3) Turn scripts back on. (if it stopped, problem solved) <-- most come under this easy fix, even the one I made.
4) If not fixed, open state tools and get the script time usage from the debug page.
5) Locate an object that is close to where you were when the attack started with a high script time. Return it.

notes:
This attack only works IF YOU TOUCH THE OBJECT. So it must be somthing close to you, like a door, etc.
Script time for child prims will still turn up in the debug under the main objects name. Look for something like a door you may have opened or some kind of button you might have pressed that has a high script time when it should be idle.

My understanding is that when you give MOD permission to someone, they can NOT add items to the inventory of your objects. Therefore I find it very unlinkly that someone added a spamming script to someone else's object.

The lindens have broken content to FIX griefing exploits. This is true. It is also true that most of the fixes were then re-fixed properly after people like me pointed out that the original fix didnt work properly. (This include llPushObject)
In this case we have the oppertunity to fix it right so that other content is not broken. It has been suggested that a viewer side block is quick and easy to implement. And I have suggested a perfectly good server side throttlle based on the IM throttle model that is already in place. So there is no need to break any contenten at all except the "bad" content you want to break.

The only fix I appose is the one click one map approch, or any time limit placed on how long you can wait before handing out the map. Time limits will fail under lag, and limiting the number of maps to one breaks a lot of workarounds for other long standing bugs.(see below)

Other people (in the other jara) are trying to get the "lost map" bug fixed, and the "wrong destination" bug fixed. Right now, both of those bugs can only be worked around by sending the map a 2nd, 3rd, or even 4th time within a couple of seconds. There is a LOT of content out there besides my startgate that is using the workaround. Dont take my word for it, go look up the other JIRA issues and check that they are in fact sending the map more than once to fix a bug LL has yet to fix.

As I have said many times. If we do not fix this JIRA the right way, a lot of content will be broken. There is no need to press the panic button and implement a bad fix.

Darling Brody

=====================================================
"How-To : remove a spammer on your estate
-------------------------------------------------------------
1) Turn off scripts using estate tools. The maps will stop, so you can find the offending object.
2) Return all objects that do not belong to you or other land owners.
3) Turn scripts back on. (if it stopped, problem solved) <-- most come under this easy fix, even the one I made.
4) If not fixed, open state tools and get the script time usage from the debug page.
5) Locate an object that is close to where you were when the attack started with a high script time. Return it."
=======================================================

Step one is highly disruptive for everyone in the estate.

Step two could be a serious problem for an estate owner who sells off parcels in the region that are then set to group.

All of these steps require estate powers, and thus are useless for individuals on the mainland or those who lease parcels on an estate.

It seems your solution may actually be more disruptive than the map spammer.

================================================
"This is similar to what most people do anyway. The just move the map off to the edge of the screen where it cant get in the way anymore."
=================================================

In my experience, the incoming map requests keep stealing focus repeatedly. Thus even if you move the map to the side of the screen, you are still unable to move or type or interact with the world in any manner except to teleport away.

=================================================
@ ALL

Some people have been dismissing my opinion as being biast. However I am the most unbiast person posting here. I thought it was obvious by my opening post, but I think I need to make it more clear.

1) I make teleporters based on llMapDestination.
2) I made a map spammer based on llMapDestination.

This means I have a foot in both camps. ie. unbiast!

NOW, lets examine what I have said here:-
Q:Did I say dont fix it?
A:NO I didnt! I just said, dont break other innocent items when you fix it. Then I explained what behaviour needs to be retained to avoid breaking innocent items.
=================================================

Of course, you could remove your map spammers from the grid, which by your own estimates are in the thousands, and doing so would help solve this problem without affecting your teleporters. If you want people to work with you on this issue, there needs to be some give and take here. Most of the people who have commented have made great effort to try to work out solutions that would leave most teleporters intact, but you have shown no willingness to take a very simple step to remove thousands of map spammers. Why?

======================================================
"My understanding is that when you give MOD permission to someone, they can NOT add items to the inventory of your objects. Therefore I find it very unlinkly that someone added a spamming script to someone else's object."
=====================================================

Actually yes, someone can add scripts to an object if they have mod rights. I know this because I have friends who regularly as me to help script their objects. While it is often enough to just hand them a script and tell them to drop it into the inventory, sometimes I have to do it myself when I have to make sure that certain scripts are placed in certain child prims. So I have actually placed scripts in friends objects when they have given me permission to do so.

You admit you made a map spammer?

That's two feet in the same camp. I mean... um... [deleted]

=========================================================================
[Banish]
Description: Locks the victims MAP page open to Help Island. It immobilises your victim's ability to interact in the SL environment. Their only escape is to teleport home or relog to another region.
Type: Passive, Reusable as Active. [Anonymous]
Range: Region Wide
Duration: Victim must remain logged out for 30 minutes.
HUD Usage: [Banish] <ALL/Name> [GO]
Chat Usage: /666 Banish <ALL/Name>
==========================================================================

This is taken directly from the user guide/promotional material for her product, and is her own writing. Linden Labs apparently decided a while back that it was somehow not a ToS/CS violation for her to do this, so I suppose this means that we must respect her "right" to sell these things.

In any event, I'd mentioned this before in a comment on this ticket, but it's good to put this documentation out there again because I think it offers a good summary of what these map spammers are capable of doing. I really can't see any ToS-acceptable usage for something like this, and I think this documentation speaks for itself as to why this exploit is a fairly major concern and needs to be patched soon.

I make scripted objects of just about every description. I make three times more teleporter models than I make weapons. On top of that I make an extensive range of anti-griefer land security devices too. Sadly a lot of people cant see past the weapons. They see the weapon as being who I am. It is really disipointing when you meet people who will hound the creater of something because "someone shot them and they didnt like it". You never hear of a tree makers getting abused when someone pokes a tree over a parcel border, but make a weapon, and you are personanly responsible for every single person who is every shot by it! ....at least according to some people. I feel those people are best ignored as they tend to rant on with personal attacks that have nothing to do with the technical side of what needs to be done.

I didnt just make a map spammer, I was the one responsible for "inventoring it". (see my first post here) Now it seems that any weapons is OK so long as the person you are attacking is willing to let you attack them. The problem is, when the other person is not willing! This is where being able to mute / block / stop the attack would permit an unwilling victim to escape harassment.

• • So the issue is : How to stop people from being attacked who do not want to be attacked, with the constraint of not breaking content that is unrelated. By "unrelated" I mean non-weapons. At no point have I stated that the weapon should be retained or should be removed, I will leave that to the Lindens. My interest here is limited to ensuring there is no collateral dammage to other scripted items that have been created, and are functioning within the stated specifications of the llMapDestination function.

So far people have suggested : Client side Mute, Server Side throttle, etc. Any conversation about "who did what to whom" is outside of the TOS for using the JIRA and should be taken to another conversation media.

@Vittorio Beerbaum

The instructions I provided above will enable you to remove both a commercial map weapon, or a script hidden in something else, as you described. It is important to use estate level tools, not parcel level tools. If you mistakenly use parcel level tools it's likly the weapon will not be found. If this happens the weapon will appear to be untracable, when in fact it can be found if you use the correct tools. If you have trouble with it again, call me in world and I will talk you through how to find it step by step. I will not be able to come to your region to help in person, the last time I did that I was set-apon by a group of people looking for someone to take their frustrations out on. They didnt seem to care that I had teleported all the way over there to help them.

Do not pay any attention so anyone telling you those instructions will not work. I have given them to you freely to help you. Please make use of them if you should be unfortunate enough to encounter another similar problem.

Darling Brody.

**********
Quoted by darling brody :

How-To : remove a spammer on your estate
-------------------------------------------------------------
1) Turn off scripts using estate tools. The maps will stop, so you can find the offending object.
2) Return all objects that do not belong to you or other land owners.
3) Turn scripts back on. (if it stopped, problem solved) <-- most come under this easy fix, even the one I made.
4) If not fixed, open state tools and get the script time usage from the debug page.
5) Locate an object that is close to where you were when the attack started with a high script time. Return it.
-
****************

1) This is the minor of the problems. Since i can log with any account (even with the estate powers), there's no reason to shut down an entiere region scripts, affecting tenth people while you may work silently. Turning em off would only help the offender cause: cause to you more troubles.

2) Nice solution, so i've not only returns hundred objects owned by someone else that partecipate to the SIM life: we had several "hosts" with rezzing powers in the past, they put things around (example: a bench), so each time that a host leaves i've to return all their objects, and only because of an exploit, and only because there's no way to identify the offending object so i can't mute it. So you implicit admitt that there's no way to identify these objects, otherwise why i should return "everything" owned by someone else? But again you can survive to it. Another problem: the merchants, so i have to return the merchants vendors also? Or i've to enstabilish a court to decide who of them i can trust? This is the same solution proposed by Linden Lab > Return anything. It would cause more trouble to the land than the map spamming. Again, no solution provided.

3) See point 1).

4) Open the estate page to do what? There's SEVERAL scripts there, including all the "sit poses" scripts, to not talk about the mechant vendors, or any other minor or advanced scripts, with ANY sort of script timing (from less to higher that a potential map spammer). Since the Estate Tools provides the total object scripting time (not the single scripts), looking at the objects and their timings in the estate tools give you no help at all. So, your solution doesn't help at all. To not talk about when the user affected own just a parcel (or even an entiere SIM in Mainalnd) and it doesn't have estate tools.

5) Sure, i start to return any object around me that would be the potential "candidate", returning things to dozen of "innocent" people because Linden Lab left open an exploit. And i'm sure i don't have to tell you that the spamming can start after a "timeout", so it's not necessary any object that was around you in the moment that the attack started (the secrets of llSleep.. lol).

Definitively i don't have to pay attention other people to understand that your provided solution won't works, my first "job" in SL is scripting, and in my modesty i'm far advanced at doing it... but i don't invest my time to develop map spammers, i just like those roaming pets.
Cheers.

This ticket is about enacting measures to prevent the abuse of llMapDestination() that "[l]ocks the victims MAP page open to Help Island. It immobilises your victim's ability to interact in the SL environment. Their only escape is to teleport home or relog to another region." This is a very serious problem as it prevents the use of the service, and could potentially prevent a user from utilizing land for which they are paying good money. Concerns over workarounds to other bugs that require teleporters to make multiple calls to llMapDestination() are best left to those JIRA tickets. Effort spent trying to prevent the implementation of good measures to stop the abuse of llMapDestination() would be better spent trying to support efforts to fix the problems that require those workarounds in the first place.

And besides, who the hell would actually consent to be map spammed. Contrary to the crap printed in the QC manual, being on Damage-enabled land doesn't constitute "consent" for that sort of activity. The argument that it is only meant to be used on those who are willing is rather weak.

I think that all of the suggestions made so far, limiting the number of calls to llMapDestination() per touch_start() event, as well as serverside and clientside clamps on the number of times that the request can be sent in a given amount of time, are all good suggestions and probably could all be included in an eventual comprehensive solution. Additionally, the map should not be stealing focus when called via llMapDestination. VWR-2060 will eventually be fixed, and I think that these fixes should probably not be held hostage to concerns over workarounds necessary to deal with that separate bug.

At this point, I think the real question is which of the potential solutions can be implemented first, which will take longer, etc. It would be interesting to hear from someone at LL regarding the feasibility of these potential fixes and which ones they would be able (or willing) to implement first.

@Vittorio Beerbaum

I disagree with your assesment. I could locate and shut down a spammer within 1 minute using estate tools by returning ONLY the ONE object responsible for spamming. However I respect your right to disagree with me, and wish you luck doing it whatever way works for you. My offer still stands to help you should you need help.

@Ezian Ecksol

Good point. And one that the lindens agree with. Guns dont kill people, people kill people.
In fact, I have never had a Linden ask me to alter one of my weapons in any way. I have heard plenty of people like Jahar boasting that they got the lindens to make me change things. I guess some people need to lie to feel important. That is nothing new, and who am I to deflate their egos if all they have to talk about is their fantasies about me?

I would be nice to be able to talk about the techincal issues of this JIRA, but once again Jahar would rather turn it into a "bash darling brody" session.

Darling Brody.

The function of the "Banish" module, and thus the Quantum Core product itself, is thus quite relevant to this discussion because it is an example of how this exploit is abused to cause serious grief. I mentioned this particular product for several reasons. I mentioned it not only because it is created and sold by Ms. Brody, who is commenting here, but also because it was one of the first products to contain such an attack and is one of the most widely sold products to contain such an attack. By Ms. Brody's estimates, the number of copies sold is in the thousands.

Most ethical scripters would not include such an attack in their products specifically because it has no actual use in SL combat and is not something that would ever be used in a consensual manner, so most other similar HUD products do not contain this attack. Note that this is clearly not because it is somehow too complicated or difficult. Anyone with even the most rudimentary scripting experience can create such an object in a few minutes. It is just a simple loop in a touch_start() event. Most people have the ethics not to turn around and then sell such a product, which despite any claims to the contrary is by its very nature encouraging its use. After all, nobody sells someone a ball and then says "don't throw this." While the disclaimer that it is only meant to be used with consent is nice, the fact is that nobody realistically expects anyone to give consent to this sort of thing.

As to the technical issues of this JIRA, every commenter who does not sell map spammers seems to be in agreement that we need to have client and server restrictions placed on llMapDestination(). All that seems to be left is verbal pooflinging while we await action on the part of Linden Labs.

********
2) Return all objects that do not belong to you or other land owners.
********

now you say:

********
"I could locate and shut down a spammer within 1 minute using estate tools by returning ONLY the ONE object responsible for spamming.."
********

Can you please post your "new" solution to find, locate and return this SINGLE object within one minute please? It would be much appreciated.
Thanks.

I don't use alts. I think the use of alts is a sign of someone who is not willing to take responsibility for their actions. I have the corrage to stand up and be seen for the good i have done and take responsibility for the mistakes i have made. This makes it easy for some people to target me with abuse, because I am not using a squeeky clean alt to post with, while letting another alt do my dirty work.

I dont think you understood my instructions. "Returning" (or rather taking a closer look at the script usage) of objects that do not belong to land owners would also include people with vending machines, group members, and anyone who you would trust not to be spamming you.

There is no new solution. It is just I could go through all those steps very quickly. As an estate owner and manager I would quickly spot an item that belogns to someone who shouldnt have items on my regions. I can also spot an item with high script usage. By following the steps and cross referencing the infomation I could quickly remove the offending item.

From your (and Jahar's) reply to my instructions when you both indevidually argued with each of the steps it looked like neither of you were considering them as interconnected process. I don't have time to argue with people about how to use estate tools, so I gave up to save myself the stress. After all it is not my problem if people want to do things the hard way.

Darling Brody

The name of the offending item is "tree" !

If you want a more sensible answer than that you should have giving me the FULL data in real time while an attack is happening.

I have grown tired of your adding small bits of information to your problem each time to make the task harder. If you were really serious you would have included the full output of the region debug pages, so I could identify which object I think is running spam and tell you why.

My instructions are enough for a skiller person to identify the item if they really want to. The key is, you have to want it to work. I honestly don't think you do want it to work. And more importantly, I don't think you want to be helped by me. I think you have another agender. So I am not going to waste any more of my time.

Darling Brody

ps. if you dont like my attitude, then look at your own. Your not behaving like someone who is on the receiving end of help. You are behaving like someone trying to prove a point. I dont have time for games.

PS: there's no "tree", all of them are named "New Object", gH.

Also, what about if a spamming object is attached to someone? does that work ?

Have you been reading my posts fully, or just looking for points to dispute? READ THIS "I did not say they cant change it. I only said the change needs to take some things into account that other people here have missed. My comments on what needs to be protected will have no bearing on the remonal of the weapon you are lobbying to remove."

I dont have to accept anything. Clearly I understand the weapon, and how to deal with it better than you do. I am happy to live my SL without convincing you that I am right about how to track down the offending item. Like I said before, I dont have time for games.

@WarKirby Magojiro

toss the below into a script of an attachment and then get someone to touch the attachment. After trying that I am sure you will not consider objects being worn by other people to be a threat..... ...oh, and it might be a good idea to have your inventory open and ready to detach the item.

touch_start(integer count)
{
while (TRUE);

}

Warkirby makes a good point about about not being able to use estate tools on the mainland, or if one is only a parcel owner on an estate island. And of course, one doesn't have estate tools at all in a sandbox. The number of people in SL with access to Estate Tools is vanishingly small compared to the broader population of the grid as a whole. Thus, an attack that can only be fixed via Estate Tools is one that pretty much cannot be fixed in most situations.

However, Darling is right about the fact that llMapDestination() will only affect the wearer if called from an attachment. However, an object can also be scripted to go alpha, set its size to <0.01,0.01,0.01> and retreat to a far corner of the sim after being touched. Thus even if you own one parcel, the object could move to another parcel and still affect you as long as it is in the same region.

Look, I think at this point we've established that this constitutes a very serious attack when used, and that it is very difficult to stop, even with estate tools, and almost impossible without. I think that all this arguing does is underscore the need to get this exploit fixed.

My advice was given to help a private region owner resolve a problem, not to help everyone everywhere in every situation. It will be the last time I bother helping. I should have learn last year when I turned up to help someone remove one of my weapons and got an ARs filed against me by the people who I was there to help.

**************************************
LAST WORD

llMapDestination needs to permit more than one map to be sent in a click to avoid breaking lagitimate teleporters. See linked issues for comments by many other creaters who need this behaviour.

llMapDestination also needs to have NO time limit between the touch and the llMapDestination function being called, due to lag and any other scripted processes that may need to be performed before the map is sent.

A server side throttle on the number of maps a single object can send within a given time is all that is needed. You cant touch more than one object at a time, so an object-by-object throttle is all that is required. Throtteling based on owner has inherant issues if the owner is the estate owner with lots of teleport terminals and lots of people using them.

Darling Brody

Throttling will be useful. Throttling alone will not be sufficient, as all a griefer (or a map-spammer creator) needs to do is make sure that their map-spammer is sending the llMapDestination() requests at a rate that is slower than the throttle. I understand that you may need to call the function more than once due to a bug, but does it need to be called 20 times? 50 times? A throttle PLUS a hard limit that puts it at a reasonable number will work.

I didnt say I was providing you with a "solution". Stop trying to make my helpfull hints into one. I told you how I would deal with the problem while waiting for a fix. Yet your still at it, trying to win some kind of points battle by adding more and more details. This time the spammer is pausing before attacking to hide it's location. Your not helping to provide a solution, so give it a rest will ya. (rolls eyes)

@Jahar Aabye

While a hard cap sounds like a good idea to stop weapons, it dosnt take into account all the possible objects using the map function. That is a common problem with anti-griefer JIRA entries, they rearly get seen by people who's items are going to be broken until it is too late.

A hard limit of any kind will break any object you wear that gives maps, such as those landmark sorting HUDS.
A hard limit may break some teleproters.
A hard limit will break orenteering systems.
A hard limit will break the grid wide Tardis teleporter system.
A hard limit will break my stargates.
A hard limit will break my DHD (seperate product).
A hard limit will break the stargate HUD (not my product)
A hard limit will break anything that needs to workaround. (which I correcly pointed out, needs to have it's fault fixed first to maintain stable behaviour for SL scripts)

..and I am just one person. If I can think of those things quickly off the top of my head, then we can be sure other people have thought of other things to make. Those people pushing for extream measures need to remember that, and show respect for the other creaters in SL. There is no need to panic and break content by imnplementing an incorrect fix.

I would anticipate a throttle with a limit a lot lower than the one in place for IM's will get the job done. Just like the IM cap it should disable any further maps until there have been no more map requests in a long time.

Darling Brody
having a last word after the last word

C'mon

In VWR-2060, I suggested a worksaround here :- http://jira.secondlife.com/browse/VWR-2060?focusedCommentId=80135#action_80135
Quote:- "I use the workaround of sending the map 3 times waiting 0.5 seconds between each map to give them time to stop pressing buttons, while resetting the map to the desired destination. "

20 is a number you came up with because you felt it will support your argument. If you are feeling particularly bored today I can entertain you buy thinking up a reason why 20 is needed. How about someone walks though the stargate 6.66 times? Now there is a nice number you can ponder the significance of.

Darling Brody

http://jira.secondlife.com/browse/SVC-1038?focusedCommentId=88304#action_88304

Adding in a hard limit on the number of times it can be called is a necessary addition to throttling, otherwise a griefer of map spammer creator - if there is really a difference - could just create a spammer that sends the llMapDestination() request at a rate slower than the throttle.

The landmark sorting huds, as you've so eloquently pointed out, are irrelevant because this funciton can be called from an attachment without requiring a touch event, to show a map tpo it's wearer

If 1 is a too restrictive limit, then 2, 4, 5. Can you give a legitimate example where you would need to call llMapDestination more than 5 times between touches of an object?

You invented the 20 number, and then you said it was too much. Can ou not see that you are arguing with yourself? At no point have i suggested what livel a hard limit would be usefull. I am not arrogant enough to think I could possibly know all the legitimate uses people have for this function. This is why I would not suggest a hard limit. It is also why LL use throttles instead of hard limits.

As I suggested above. someone might walk through a stargate 6.66 times. 666.. interesting number.

@WarKirby Magojiro

You have no way of knowing what event the llMapDestination is called from in the landmark sorting huds. It might be in direct responce to pressing a teleport button being pressed on the hud (touch), or it might be in some dataserver event used to extract the destination details. That is entirly up to the creater, which brings me back to my point of avoiding significant alterations to the documented behaviour. There is no need for a hard limit when a throttle can do the job just as well.

Darling Brody

That point is irrelevant. No limit is needed in attachments. the limit would only be applied to non-aattached objects, when called from a rouch event. problem solved.

@Conveyician: Nobody is competing or trying to break anything here. We're trying to fix a bug in a way most can agree with, and some are obstructing those efforts.

However, I think it is also important to note that we are trying to destroy one piece of content, if you can call it that, which would be devices that abuse llMapDestination() so as to lock a user's map open and prevent them from interacting with their environment. I have yet to hear any spirited defense of map spammers, and I really don't expect anyone to defend them, since they pretty much destroy one's ability to enjoy SL.

While it is true that we cannot know what other legitimate uses individuals will find for llMapDestination(), we can probably safely guess that there is a limit to how many times the function will need to be called per touch_start() event. Why? Well, for starters, most users don't want any device repeatedly popping up maps on their screen. But that's a rather flippant answer, so I'll be a bit more serious:

For starters, I agree with WarKirby that we're talking about non-attachment behavior. This function already has different behavior when attached, so it's not too difficult to imaging that we'll leave the attachment behavior alone. So keep in mind that I'm referring to non-attached objects here.

llMapDestination() brings up the user's map to a specific location. Possibly, the user will then teleport to this location. If this location is in another region, there is no point to calling llMapDestination() again because it will not reach him.

Now, perhaps he decides not to teleport. I'm not sure exactly why a function would want to bring up his map again. If he changes his mind, clearly it makes sense for him to click the object again, since after all he has now decided that he would like to interact with it again. But otherwise, it really doesn't make sense for him to want his map called back up after he has closed it. In fact, it would be rather harassing, and obviously when taken to the extreme is the very behavior that we're trying to stop.

The third option is that maybe he has teleported to a location within the region. Maybe the object wants to then send him the coordinates for yet another location within the region. The problem with this is that the object doesn't really have any way of knowing that he's teleported. If it sends the new coordinates too soon, it risks overwriting the original coordinates before he can teleport. It also makes it difficult for the resident once he's teleported the first time to actually do anything since his map pops up on his screen. But leaving all that aside, it's simply not practical to have that happen. The more likely scenario would be to have another object there to click when he's ready to move on. And of course, since we're talking about teleporting within the region, there are already plenty of other methods for doing so, ranging from llSitTarget() for distances within 300m, to having individuals sit on moving chairs.

The final option is that maybe the device is using llMapDestination() simply to set the map beacon, so that the person can then minimize the map and move to the beacon, perhaps by flying. Ok, this makes sense. But then, why send llMapDestination() again before another touch_start() event? If the user wants to change the map beacon, he's likely to want to do so by interacting with an object (ie touching it again).

There simply isn't any reason for someone to need to call llMapDestination() multiple times without having the user interact with the object again in some way. I can understand allowing it to be called a few times to deal with a known bug as well as possible future bugs or just general SL wonkyness, but there really aren't any realistic scenarios where it would need to be called multiple times. And the problem isn't simply that I'm not thinking of any, because I know that will be the obvious response. The problem is based upon the function itself. It's one that generally is a one-off thing, either the user teleports or they don't, and either way the user would probably expect to have to interact with the object again to get the map back up. Calling llMapDestination() more than a few times from the same touch_start() event pretty much creates the same obnoxious behavior that the ticket is asking to be fixed.

And as for the question about what if a user wanted to walk through the stargate 6 times (dunno how you'd walk through it 2/3 of a time, and "666" has no particular meaning in my religion, dunno why you mention it), that by its very nature is an example of a situation where the user is interacting with the device multiple times. Since they're interacting with the device (by walking through it) it would make sense that they would expect to click before walking through. I guess I'm not seeing how it would be expected to work otherwise, they walk through, get the map, close it for some reason, turn around, walk through again, get the map, close it for some reason.....I mean, the most likely scenario there is that they set the wrong destination and thus would of course want to click it again.

Fixing this exploit would cause a very minor inconvenience for teleporters. It would, however, fix a very major vulnerability that allows one resident to remove another resident's ability to interact with anything around them, and can be used to prevent a resident from accessing an entire region. It needs to be fixed. It needs to be fixed now.

Tell me about it. It's not enough to break the weapon, they want to break the teleporters too. Not suprizing since at least one person posting to this JIRA has stated outright their intention to drive one of the other posters out of SL.

It is just another example of one creater playing the "griefer card" to remove another competitor from the market.

Darling Brody.

My interest in fixing this exploit is nothing to do with removing competition.
Vittorio seems to just want to not be forced out ohis home again by untraceable attacks
Argent ? I don't know, but I doubt it.
That only leaves Jahar. I don't know much about him either, but you said he made weapons at some point here too, did you not?

But tell me, how exactly can fixing an exploit do anything for competition. Anyone using this exploit would lose acess to it, and all of your "competitors" in that regard would be hurt by it, too. What could any competitor of yours hope to gain from wanting this fixed ?

I've already explained how it's done in the description, so it'a hardly a trade secret that only you have acess to, and others would want to deny.

Farthermore, many of the posters here have suggested viable adjustments to the proposed fix, that would not break your devices.

What legitimate need could you possibly have to call the function 5 times or more, between any interaction? Twice is plenty to make up for this onerous bug you keep mentioning.

In fact, I don't think that the central aspects of this ticket are really up for debate. This exploit exists. It is extremely unpleasant and prevents a resident from being able to interact with their environment in any way other than to teleport home or log out. The sole authority for forcing a resident to log out of SecondLife rests with employees of Linden Labs, not with anyone who buys or scripts an object to use this exploit.

There is no legitimate use for map spamming. Nobody has yet come up with one. Even the commenter who makes and sells a device with a map spammer, Ms. Brody, has declined to offer any defense of this device, save for a weak reference to "consensual use." Ok, let's ask for a show of hands of anyone who would consent to having this exploit used on them. *crickets chirping* Anyone? Anyone? Bueller?

Ok, I thought not.

Ms. Brody and Ms. Morigi wish to derail this ticket from its main topic: Fixing a very serious exploit by preventing scripted objects from continuously spamming llMapDestination() requests. Ms. Brody has asked that any potential fix be formulated in such a manner that it does not break teleporters that she makes that utilize llMapDestination(), and that we take into account a workaround necessitated by the bug mentioned in VWR-2060. I believe that we have worked out, or at least are in the process of working out a solution which will take this into account.

By placing a throttle, either serverside, clientside, or both, on the frequency of llMapDestination() calls, along with a hard limit on the number of times that the function can be called per touch_start() event, making sure that this number is high enough that it does not interfere with the workaround required by VWR-2060, we should be able to limit the abuse potential of this exploit without harming teleporters and other legitimate functions that rely on llMapDestination().

This has been suggested many times. So far we have still not heard of any legitimate needs that would require it to be called more than 5 or 10, or even 20 times. Since we have not heard of any legitimate reason as to why such a limit would cause problems, and since Ms. Brody and Ms. Morigi have had plenty of time and have submitted plenty of comments in the interim, I would assume that this means that we ought to be able to safely place a hard limit somewhere in this neighborhood, yes?

The object 'Object' has sent you a Map Dialog from Second Life.
= Object is owned by Vittorio Beerbaum
= http://slurl.com/secondlife/Beerbaum/128/128/23

...so after that, i can easy find the object and (if it's not legit) i may return it, or AR it.
I don't think we're asking for the moon... they have fixed the "sound spam" thing that was alot less dangerous, wrecking some of my products (i do musical instruments) but i NEVER said anything about it since i know it was used by griefers, why in the hell they shouldn't fix a exploit that would make you (litterally) stop playing the "game"?
There's no "excuses", nor any debate is necessary... they need just to place their hands in the code and fix it.

Just a quick note, the sound spam thing was actually very dangerous (was a SEC JIRA ticket, in fact) as it could have resulted in massive bandwidth spikes that could have led to the appearance that DoS attacks were coming from LL's servers (imagine being the sysadmin at a university network who sees thousands of packets per second coming from Agni.LindenLab.com).

This doesn't have quite the same level of emergency as the sound throttling, since it doesn't threaten the overall integrity of the platform, but the ability to totally freeze a resident's ability to interact with their environment (without using the appropriate Land Tools or administrative Linden powers) is still fairly serious. A griefer could, for instance, use this in a store to force one's customers to teleport away. After all, LL has been proactive in fixing other exploits that could force logoffs, such as URL and dialog spamming, and orbiting to max integer altitude.

I agree, why the hell shouldn't they fix an exploit that can literally make someone stop playing the game?

(Especially when we've come up with a solution that should spare most, it not all, legitimate content)

For the record: Despite the words you have attempted to put into my mouth, I have not agreed with anything you have proposed. I have debated "appropriate weapon types" with you many times before with neigher of us able to convince the other. Do not for one moment take my choice not to re-re-re-re-debat that issue with you again here as me agreeing with your point of view.

As I have no desire to get stuck in another unproductive endless debate with you. I have chosen to protect my teleporter products from the original short sighted proposal of one-map-per-touch. I have re-stated my desire to have those teleporters protected each time someone said that it was worth breaking content to break the map weapon.

It is short sighted suggestions like this one that breaks content, content that takes months to get fixed again. Example: Look at the other teleporter method using the link set to move the avatar. People shouted "griefer" and the lindens busted a lot of good content. It took a lot of hard work from lots of creaters who make teleporters to get the lindens to undo the bad-fix, and officialy support the link teleport method. If I am not mistaken it was the same short sighten people shouting "griefer" here who caused the bad fix in that other JIRA too.

Darling Brody

Also, please go back and re-read the comments from WarKirby and I regarding placing the limit at 5, 10, or 20 llMapDestination() calls per touch_start() event. We have asked several times whether placing the hard limit at a number like that would allow for teleporters to function and use the workaround to VWR-2060 while still placing a necessary cap on excessive use of the function. It has been mentioned several times, by myself and by Mr. Magojiro, that a hard cap is necessary in addition to a throttle, because otherwise a map spammer could simply send out maps at a rate slower than the throttle limit. Since part of what makes this attack so pernicious is the fact that the map steals focus every time it receives the call from the map spammer, even a slow rate of llMapDestination() calls could have a serious effect.

Instead of attacking me personally, or bringing up other unrelated JIRA tickets, you need to explain in more detail why your teleporters would still be harmed under such a change, and perhaps suggest constructive methods for limiting this attack. If you feel that the ability to spam llMapDestination() requests should not be limited, or is not a high priority issue, then we would also welcome your input to that effect as well. However, please remember to keep your comments relevant to this particular JIRA ticket and to the llMapDestination() function and its uses, including teleporters of course.

I have no intention of jumping through hoops into obvious traps. I have stated that a hard limit will break content. I will not engage in a conversation about suitable hard limits when I have been clear that any limit is undesirable. I provided a list of products that would suffer damage from hard limits and they have been ignored. Noone even bothered to contact the makers of them for comment. It is obvious why, some people dont want any opposition to this illconceived fix. The same people who are slinging barbs at people who appose them.

I do not have to explain in MORE detail why my teleporters would be harmed. I have given enough detail already, and have had to suffer fools telling me (1) that it should be broken anyway, (2) that I should reduce the function of my teleporters to what other people are doing, (3) unrelated personal attacks and allogations.

I am more innovative than many other creaters with the implementation of my teleproters, that is a good thing, not something bad that needs to be broken by ignorant people. Given that the Lindens have gone out of their way to preserve content that I have created, I would say I am on the right track to be creating new content in innovative ways.

Darling Brody

I have gone over the reason in previous posts. To put it very simplisticly, all of those products can send more than one map over extended periods of time for perfectly legitimate reasons.

note: there is no permission system for llMapDestination. There is only an exception to the rule that lets attachments call the function at any time and the person wearing it will receive the map. For non attachments the function can only be called in the TOUCH event.

Some people have been misleading about what i sell. A multi-tool I sell which has over 250 functions also includes a map bomer. While customers will complain if I remove it myself, they are unlikly to miss it if the lindens remove it given the other 249+ working functions. This is why i have not opposed stopping the weapon, under the condition that teleporters are not broken.

Those people who are not aware of the history between "some people" and myself need to be aware that "those people" are not above distorting the truth. This is why "those people" have been happy to let people think I sell an exclusive map bomber product. You see, that miss-information helps their cause while weakening mine.

What I would like to bring your attention to is that fact I do not hide behind alts. I stand up for what i think is right, and I cop to everything i have done in the paste. Other people will hide behind an alt. I dont. That make it easy for people to go at me with a personal attack rather than look at the facts. You yourself are guilty of this. You implied that my point is less valid because I sell a map bomb. Maybe you should visit my shop and see just how HUGE my product line is. Then you will understand just how wrong you are to have thought that.

Darling Brody

It's irrelevant whether there's CURRENTLY any permission system for the call, since we're talking about changing the call's behavior ANY behavior is in scope... and a permission that allows the call to be made outside of touch events would more than merely offset the effect of the change.

As for your multi-tool, I don't see what difference it makes if it has 20, 200, or 2000 other functions. You're still selling a map bomber. If you want people to take you seriously you need to stop doing that. And, really, if you're getting enough business out of that feature that you'll lose a significant number of lost sales (let alone get complaints) from new customers, then what you're selling is not "just" a multitool, it's being sold as a griefer tool.

Yes, you have the brass balls to stand up and say "I am a sinner", but even Christ wouldn't accept that as repentance if you qualify it with "... and I have no intention of changing that"... and I don't see why you should expect to hold anyone here to a stronger standard than that. If this functionality is merely a minor feature of one of your many products, then getting rid of that feature can't possibly have any significant cost to you. This doesn't strengthen your case, it only weakens it.

... wait a second. Now you've reminded me of something else. Aren't you one of those people selling "copybot protectors" for years after they were proven completely worthless? Yes, yes you are. Not only were you taking money for a product you must have known was completely worthless, but it was one that stealthed itself by changing its name over and over again. We had someone set one of those up in a sim catty-corner to ours, and it was spamming our customers and costing us sales because they thought WE were the ones using this useless spam tool.

You're not just a sinner, you're an infamous, unrepentant, and mendacious one.

The issue appears to have been imported already, DEV-7360, so at least its in the Linden system. It might be worth bringing up at the appropriate office hours. Maybe Andrew's or Soft's?

One possibility is to ask Linden Labs for a client-side throttle first, with the understanding that we would re-open the ticket and request a server-side clamp on the number of times the function can be called if it is discovered that map-spammers are being updated so as to get around the throttle. If we have to re-open the ticket to do that, however, I would imagine that such a clamp would be much smaller than if it were added with the initial fix.

However, I am in-world right now, and will do a search for teleporters and wander around to their stores seeing if I can get some input.

You insult me and my products without providing any usefull comment on the issue at hand. Then you declare that your not going to talk to me anymore because "my comments are not helpfull"!?!?! I bet you have your fingers in your ears and your shouting "la la la not listening" right now! Then you can have the last say like children do.

Darling Brody
la la la not listening!

Right now I've got the throttle set to a call rate of 4 calls per 4 seconds – if objects try to exceed that rate against a particular target then the calls will fail until they stop trying for at least 4 seconds. I'm thinking maybe that isn't enough and should maybe bump it up to 4 calls in 8 seconds or something like that. I'm reluctant to break the case where someone clicks for llMapDestination(), accidentally closes the map and quickly re-clicks (yeah, probably a rare corner case).

So, here's an opportunity for SL Residents to provide some input as to what the simple throttle rate should be. The throttle is target-specific so an object could handle somewhat rapid clicks from unique avatars (if multiple people click in the same simulator frame then llMapDestination() only handles the first detected clicker). What do you think the throttle should be?

(1) 4 calls in 4 seconds (current setting)
(2) 2 calls in 8 seconds
(3) other

I use 3 maps with a 0.5 second delay between them (3 maps in 1.5 seconds) when someone walks through my stargate. (yes i have a work-around to send the map in the collision event)

After that either the person teleports, or they decided that they want to walk though it again. In which case they receive another 3 maps in 1.5 seconds.

So the 4 maps over 4 seconds will work, but the 2 over 8 will not.

I figure it probably takes someone about 3-5 seconds to close a map, turn around, and walk through the gate again, so again 4 maps in 4 seconds should be ok so long as the avatar is not running.

4x4 should not break any of my teleporters so i have no objection to that. However anything higher will cause issues. Frankly, I've had enough of broken teleporters, as you know. Customers have a right to a working product, and I want a break from having to re-write code every other week.

****

On the griefer side, even with only one map, you can wait until the right moment to trigger it. Say when someone goes into mouse look to shoot you. So even one map can be exploited by the dark side.

Darling Brody

• the legacy UDP message format would have to be changed... and we're not allowed to change it anymore - we can only create new (TCP) messages through other pipelines.

Erk. OK, I used to get all aggro about the way SL was trying to do everything with UDP, but... you know... there's a good reason for some things remaining UDP, where real-time response matters. Like keystrokes. If you can't change UDP and are moving everything over to TCP... erk.

4 calls in 4 seconds unfortunately might still be too much. That's roughly just enough time to close the map, try to take a step or type something, and then BOOM, it pops up again. 4 in 8 would still allow Darling and the other teleporter makers to get in their multiple calls, while at least giving it a slower throttle.

But I'm still not sure that this will solve the problem that much. Darling will update the map spammer in her QC product so that it sends 3 or 4 calls per 4 seconds, or whatever winds up being the throttle, and it will still have roughly the same effect. The map window steals focus, so even a map that keeps persistently popping up every second or every other second, and steals focus even when minimized, prevents you from being able to interact with the world.

Preventing the map from stealing focus would be one thing that would help greatly, but I don't know if that is possible. Another addition might be to have the object stop sending altogether if it hits the throttle three times or something, but again this wouldn't stop objects that stay below the throttle.

After all, I can write a script right now that would work as a map spammer under the throttles mentioned here. I don't know if I should post it, though. A throttle is good, it would break many of the map spammers out there, but it wouldn't stop someone from making one that works under the throttle either.

It will need either (or possibly both) making the map stop stealing focus and/or having a high hard limit of maybe 20 calls or something in that neighborhood per user per click. If 20 is too low (I cannot imagine needing 20 calls, but let's say someone comes up with a reason), then we make it 30, 40, 50...surely there is a number somwhere that we can use as a hard limit. That way the actual duration of map spam is itself limited, preventing this abusive practice from being able to actively keep someone off of a parcel.

Any hard limit on the total number of maps will break teleporter huds that organise your landmarks etc.

Darling Brody

Let's ignore the issue of landmark-HUDs for the moment and assume that these changes will be affecting only external objects that use llMapDestination, as I have seen a few teleporters that use such a setup, and obviously map-spammers use that setup as well.

Argent is correct that only hard limits will solve the basic problem in the end, although throttles and making the map stop stealing focus will help in the short term. If it's a situation where throttles are what we can get with the next server release, and then we wait for the one after for hard limits, then ok, that would make sense.

Let's focus on external uses of llMapDestination for the moment and ignore attachments.

This still won't stop people from sending messages at a rate underneath the throttle, though. The other way to blunt the impact of this exploit, though: Is it possible to make it so that the map stops stealing focus each time it's called up,. even if it's on the screen and minimized?

OMG! That is how legitimate content gets broken. Selfish people deliberatly ignore the legitimate uses of functions to push through their own agenda, resulting in ill conceived fixes.

What gives you the right to direct the lindens to "ignore" the rights of other creaters?

***

"is there a way to set it so that if the throttle is triggered 3 times for a particular key"

..and what happens if that person walks through the stargate again after closing the map? Answer: The map will not open again. The customer will complain the stargate is broken. The creater will get bad press for faulty products. The creaters product sales will drop. Innocent creaters will loose their income.
...But that is OK, because you told us to IGNORE those products to make your point of view easier to argue!

***

The simple fact is that this function is for the construction of teleporters. You can not choose to ignore teleporter products when making an alteration to this function. Those people using it for teleporters are the ones who have the RIGHT to expect the function to operate correctly.

Andrew Linden has correctly introduced a throttle that will protect the integrity of existing teleporter products while making it possible for victims of spam weapons to operate their client software enough to return offending weapons with the land tools, or teleport out of harms way to file an AR.

Now your only remaining issue is the ability to mute the map.

And our common issue is to fix the map focus so that it is not directly stealing keyboard input. As this is the issue that forces me to send the map 3 times, the reason map destinations are often reset, and the reason it makes such an effective weapon.

Darling Brody

"The customer will complain the stargate is broken"

It happened many time in the past with other functions "abused" by residents. If something is used in a bad way and reliable way to stop it doesn't exists, so you need to adjust that function. Again, it happened many time in the past. Honestly the user experience (not being griefed) is much more important than any teleporter that uses a loop in a touch event (i never encountered one; while on the other side i've ecountered many script kiddies with that mapspam script).

"making it possible for victims of spam weapons to operate their client software enough to return offending weapons with the land tools, or teleport out of harms way to file an AR"

Probably you didn't followed the past discussion, no i correct myself, u did because u replied to me, but to refresh your memory:

• You cannot locate where the offender object is, so you cannot return it unless you start to guess wich object it must be;
• Not anyone have the possibility to return objects (to not talk about accessing to the estate tools);
• If you teleport away the spam doesn't stop, you need to logout and enter into another SIM;
• You cannot return to that simulator anymore because the spam is perpetual (you don't need to touch the object again), you are out forever, so if it's not a land that you own you don't have even the possibility to find/return the offending object;
• You fill the AR to who? You don't know wich object is spamming; in my case i had to call the concierge team, they send to me someone from the inworld team (Linden), they weren't able to locate the object.

Do i have to write these things again 100 times? Because it seems that you are actually try to ignore the facts. In the moment that you prove with FACTS that a proposed solution would never cause the above scenario again (that is not theoric, it happend to me) so i will agree with you, until then please stop with this game or the ppl will really start to think that the "broken teleporter" is just an excuse to protect a griefing tool that you continue to sell that uses the same function. And honestly i can understand your business, trying to "survive" on Second Life while the sales are going down day by day, but i can't understand how's possible that you know the damage that a stupid script would cause and you still to distrubute it!
I'm actually replying to you just because of my fear that a "fix" wouldn't fix anything... so it's better to reply to you with the same things that you perfectly know instead of put you in ignore and wait passively a "wrong" solution.

OMG! That is how legitimate content gets broken. Selfish people deliberatly ignore the legitimate uses of functions to push through their own agenda, resulting in ill conceived fixes.

What gives you the right to direct the lindens to "ignore" the rights of other creaters?"
*******************************************************************************************************

When I said "Let's ignore" what I mean was that I had (mistakenly) thought that these changes were only to be applied to non-attached items. So by "ignore" I meant setting aside those items as being non-affected. Andrew corrected me by pointing out that the changes that he was making would apply to all items, including attachments. I was not directing the Lindens to do anything (really ridiculous to think that I could direct anyone anyways). My point was to try to keep the commenting towards items that would be affected by the changes, as I had assumed that those items would not have been affected.

Now, it turns out that those items would be affected, so we clearly cannot ignore them. However, you need to RE-READ my posts because I find it disturbing that you immediately jump to really paranoid conclusions from them. I was not suggesting that we should ignore the necessity of those objects or ignore the need for them to function correctly. That would be ridiculous and obviously as a content creator myself I would never suggest such a thing. All that I was suggesting was that we ignore applications that would not be affected by the proposed changes, and I had misunderstood how Andrew's proposed changes would work. I could just as easily have said "let's ignore airplanes for a minute" since airplanes (presumably) would not be affected by these changes.

**********************************************************************************************************
""is there a way to set it so that if the throttle is triggered 3 times for a particular key"

..and what happens if that person walks through the stargate again after closing the map? Answer: The map will not open again. The customer will complain the stargate is broken. The creater will get bad press for faulty products. The creaters product sales will drop. Innocent creaters will loose their income.
...But that is OK, because you told us to IGNORE those products to make your point of view easier to argue!"
***********************************************************************************************************

Huh? I think we'd already established that these teleporters wouldn't trigger the throttle in the first place? The throttle itself would only be triggered if the object tries to send more than 4 requests in 8 seconds....or whatever the final decision is. I thought that we were deliberately making sure that legitimate objects would be unlikely to hit the throttle in the first place. The idea of having an automatic cutoff if the throttle is continuously hit is specifically to prevent objects that are continuously sending llMapDestination() requests at higher-than-throttle rates - ie "map bombing."

In your example, of someone walking through a stargate, closing the map, and then walking through it again, it would be highly unlikely to trigger it. They walk through the stargate the first time, and are sent 3 map requests in 1.5 seconds. Ok. So they close the map, turn around, and walk through it again. It would be unlikely that it would trigger the throttle, but even if it did, that's still not related to what I'm saying. If it triggered the throttle, the person would have to walk through it again (although that would be highly unlikely). It would only be if they repeated this entire unlikely walk-through scenario 3 times without teleporting that it would happen. That's very unlikely. Do you have a better idea for a way to....oh hell, why am I asking you, you're already working on how to get around the throttle anyways.

*******************************************************************************************************************
"And our common issue is to fix the map focus so that it is not directly stealing keyboard input. As this is the issue that forces me to send the map 3 times, the reason map destinations are often reset, and the reason it makes such an effective weapon. "
******************************************************************************************************************

I agree wholeheartedly. Until this is fixed, sending the map once every 5 seconds will still be an annoyance.

If you can think of any other mechanism that will break your map-bomber so you can't fix it, and not break your other products, then let's hear it.

...and sometimes you dont have to break them. Client side mute for the map is already available in many of the alternative viewers, so LL can add it too. The focus can be fixed. The origen of the map can be shown. There are lots of options to remove the unwanted behaviour that will not break content. The only reason SOME PEOPLE are pushing for the options that will break content is out of SPITE.

Darling Brody.

http://jira.secondlife.com/browse/SVC-1038?focusedCommentId=93715&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_93715

2. I would hope that the focus can be fixed and I would also hope that the origin of the map can be shown. I am glad to see that we are in agreement that these changes would be helpful.

3. Nobody is trying to break content out of spite. We are trying to find a way to prevent the llMapDestination() function from being used as a tool of abuse. Throttling alone may not be sufficient, and thus other methods may have to be used. All that Argent and others are saying is that this is a fairly major exploit that causes serious problems for its victims. Fixing it is thus a major priority, and if it causes problems for your content in the meanwhile, well....sometimes shit happens. The problems documented in SVC-2511 have plagued my products for months now. Like I said, shit happens.

Also, as a word of advice, I'd like to point out that your continual refusal to remove the map spammer from your QC product really hurts your credibility on this issue and might make people doubt that you really want map spammers to be removed from the grid.

I can't imagine a legitimate product for being able to spawn a huge number of map calls. Presumably, you're trying to actually offer the person a place to go, so it would be reasonable for them to look at the map, see the destination, and click the teleport button. It's not like it could be used to (legitimately) set up a follow the leader game, or hide and go seek, or confuse someone as to the entrance to a maze. Teleports take a significantly non-trivial time. One trigger of the map per event really makes perfect sense to me. In fact, I'd suggest it be in the touch_start, and not touch event...

If you've got this throttled, Andrew - good on you. I think two touches in 8 seconds is good enough.

Right now I MUST do a double call to llMapDestination to work around the VWR-2060 bug. If I don't the map doesn't get set up reliably every time, and the user teleports to the wrong spot with no idea that something has gone wrong.

I pointed out that I sold such an item in my very first post here. Your obsession with pointing it out over and over again is either an indication you have no technical reason for disputing my arguments, or it means your comprehension is low. Either of those reasons leads one to wonder how well thought out your suggestions really are.

@Doran Zemlja

You are right. Other real bugs needs to be fixed before this new feature can be implemented, or else inocent content will be broken.
It is stupid to break the workaround for a bug, to implement a new feature. It is very stupid to impose draconian limits on a function that has never had a limit, god knows what stuff will be broken! You can be sure this obscure JIRA has gone unnoticed by the majority of people who make affected content.

Unfortunantly some of the vocal people in this jira have a history of tunnel vision. Over the years several of their suggested fixes have been rolled back after content got broken. Therefore it is important for those of us who make teleporters to continue to point out that this new feature they want will break stuff.

Darling Brody

Oh, PS, a SEC JIRA has already been filed on the latest DoS attack you put out. We're still trying to figure out how exactly you managed to get around the Grey Goo Fence, but trust me, I'm sure LL will fix that little exploit soon enough. Of course, if they can't, maybe they'll just decide to blacklist the object involved.

I think you will find my responses on this ticket have been technacally accurate and honest. When Andrew nerfs the spammer my customers will have WarKirby Magojiro to thank. If i choose to remove it now, the customers will be upset with me. In fact I may have a legal obligation to retain it in the product as removing it could be considered a loss of value to the customer.

Given this issue has been open for 15 months and has ONLY 23 votes, it is more than fair to say it is not the most evil weapon on the grid, despite what you would like us to beleve. In fact it is probably more of a novelty weapon due to its passive nature.

As for your SEC JIRA. I already showed a couple of the lindens how it worked. It's not getting around the grew goo fence at all. It's a single object with lots of tiny prims that form an invisible cage, which makes it hard to select the object trapping you, while not bouncing your camera around like most cages do. The particles make the lag, so get over yourself.

You have fun with your SEC JIRAs. I have often handed over totaly evil items to the techs for inspection and nerfing. Often agreeing not to sell the item due to it's negative effects. I help the lindens whenever I can, as a stable grid is good for business. You on the other hand just want to break all HUD products because they are in competition with your beloved gun market. Dont for a moment think that your motives and game playing is not crystal clear.

**************
@Andrew Linden

Your original suggestion of 4 calls in 4 seconds will not break any content or workarounds I currently sell, except the spammer which it is designed to break.

My complaints are aimed at those who want the llMapDestination function to only work once per touch event. A change such as that will break the workaround in VWR-2060 which is what I am objecting to. I understand that you are not proposing a change like that, but it has not stopped people from continuing to demanding it. If there are no voices in opposition you might think the loud people are the majority.

Sadly there are a lot of games going on in this JIRA as some people get very excited when they see me post. It dosnt matter than I sell over 30 completely original products in my 3 private regions, some people just have to hound me because one of those products is a multi-tool with weapons included. Of course you know this, I gave you a copy of it long ago.

@ ALL the Haters
The irony is that I support a stable scripting enviroment so that I can continue to make a living out of SL. I participated in havok4 beta and reported all the bugs I found. I repoted plenty of mono bugs too. I have spent a lot of time helping Vekter Linden & Co track down that script based crash that was holding up server 1.25.x. Yet some people feel the need to appose everything I suggest out of spite. Eg: On one of the other JIRAs someone who is posting here apposed, and then closed the JIRA, because I made it. Then months later they came back to complain it wasnt fixed because they relized their products were also suffering from the same bug. DU!

Cant you haters just get a life, that is not mine!?!?

Darling Brody

4 calls in 4 seconds will not prevent you from modifying your map spammer to continue to function.

And you have no obligation to continue selling your map spammer.

Yes, I admit. I have a map spammer in my HUD right now. But I am removing it in the next version, not because of this JIRA (i actually didn't even know about this JIRA until a few minutes ago) but because it's a childish spammer. The only reason I added it was because other Weapons Makers had it too. But I am moving to a less, childish, less 'spammy' type of Combat system now.

I find no use in NOT implementing a throttler to the llMapDest function. I use llMapDest for teleporting and I would only find it harmful to them if the user spam clicked the "MapTP" button. Even if they did that, it's not like the script would stop working, they'd just have to wait a few seconds.

I don't know why anyone would object to this issue. Other than they want to keep their map spammers.

As mentioned earlier, if such a thing had happened to me in my first hours on SL, I might have quit then and there. It is an agonizingly frustrating thing to deal with, one which seems to violate ToS. One option to help reduce these attacks without modifying SL has been put forward, but the one in question declines to do so, because she won't take responsibility for it. That much is obvious, she just won't face the fact, even has admitted to it.

"While customers will complain if I remove it myself, they are unlikly to miss it if the lindens remove it given the other 249+ working functions. This is why i have not opposed stopping the weapon, under the condition that teleporters are not broken."

This as well...

"When Andrew nerfs the spammer my customers will have WarKirby Magojiro to thank. If i choose to remove it now, the customers will be upset with me."

If she really wanted to help preserve legitimate content, she'd be responsible and remove this feature from her HUD system. Then maybe there won't be as many people experiencing this; but even then a real fix coded in SL should be implemented.

The fact is that my multi-tool costs $2800 to buy. Griefers dont have money.

The fact is the griefer who attacked Vittorio Beerbaum with a make shift version of the spammer probably got the freely available script on the PN griefer web site.

The inconveniant fact is that griefers do not buy weapons. They upload their own scripts after copying them from griefer websites.

The fact is the name of my BANISH object has been known to the GTEAM for 2 years. You can be sure they will try to return it and other known object names when they are called to a region to resolve a map bomb.

So why didnt they do an object ban on my banish prim? Simple, because it is not the object being used to grief people from freebie accounts owned by people who are using hacked viewer programs to obscure their identiry and avoid a permenant ban.

The very inconvenient fact is that anyone who paid $2800 for a product is NOT going to abuse it to the point of being banned from SL.

Notice I post under my real account here? I could use an alt to post here. I have the guts to stand up and face people for what I do. So don't accuse me of being dishonest when I am willing to be open about what I do any why. Just because you do not agree with me does not give you the right to say I am dishonest.

....now ....about those griefer trees. Can we have tree ownership limited to people who have payment details on file because I have seen some very dodgy looking trees. Perhaps a throttle put on tree groth? ...and whos job is it to sweep up the litter from the tree each autum?

And as for people buying your product and abusing it to the point of being banned from SL....I've seen a number of posts on your website from individuals who have said that they had to buy another copy of your product, or multiple copies, after being repeatedly banned for using it.

And as for being dishonest, Darling, a few days ago you responded to my comment about your latest DoS attack, STASIS, by saying that it was a "single prim" and that it was "particles" that caused the client-side lag. Strangely enough, our tests show that it rezzes at least 900 temp-rez prims, and that derendering particles (and everything else) does nothing to stop the client-side lag. I'm not really sure what legitimate point to having such an attack is, but you weren't even honest about its properties. Of course, I don't doubt that you showed LL something, it's just that I doubt that what you showed them was the actual attack. By the way, rezzing all those temp-rez prims recursively, and having them die after a second....that wouldn't happen to be what was causing all those region crash problems in 1.25, would it?

The specification for llMapDestination clearly says it can only work after a touch event. If you are trying to use it outside of a touch event, it's right, proper, and working, that it should fail.

Seriously. The OpenSpace/Homestead thing should have been a wake-up call. If you work outside specification you can and will be punished for it. If it results in feature stagnation in the world.. then let it happen, and the Lindens will change the specifications when the negative consquences filter through to them.

Stop twisting my words. I said it rezzes a single object, i said nothing about prims. Like many weapons the active (bullet) part of it is temp so it dosnt leave a mess. In this case it is using a temp rezzer to replace the cage when it dies. If you chose to wait around long enough you will get 900 prims appear and vanish, but only you would do that to generate yet another round of misleading statistics so that you can go around yelling "the sky is falling, and darling did it!".

It is amusing how you attempt to visit ever evil in SL on me. Now you want to blame me for the 1.25 region crashing. I spend a huge amount of time tracking down what turned out to be a totaly innocent object running a harmless script. Then handed it to the right people at LL so they could fix the error in the server code. ....Of course it is more interesting for you to imagen that it was some evil object designed to crash regions, because that is the way you chose to think.

Why dont you do the JIRA community a favor and stop responding to my posts. Your corrents directed at me are never helpfull, as evedent by your last venom filled post.

Darling Brody

"I'm sorry, but implementing a fix would be "fixing" your content, not breaking it. ... The specification for llMapDestination clearly says it can only work after a touch event. "

You have been a victim of the mis-information posted by "some people" in this jira. My teleporters most definantly DO issue the map from inside the touch_start even. There is no hacking or bending of the specifications involved. The fact that I have used a flag inside the touch event to pause the handing out of a map until an avatar has walked though a stargate has NOTHING TO DO WITH THIS JIRA beyond the fact that I make map based teleporters. My teleporter content does not need to be "fixed" as it already fully complies with the documented operation of the map function. My purpose in this jira is the ensure that any changes made to the map function does not have negative impact on my teleporters. Anyone saying otherwise is a liar.

"Seriously. The OpenSpace/Homestead thing should have been a wake-up call."

Why? I have never rented land to anyone! my two open space regions are full of water with only a couple teleporters to help me get around. Nothing happened to my openspace regions. So what was your point about open space again? Or was that just another round of "Darling Bashing" which adds nothing to helping the lindens understand the complexity of altering the map function?

Darlign Brody

The same could be said for multiple people going through a stargate, or any one of thousands of items in SL.
If you are going to do this, you MUST fix llMapDestination first. You MUST, so that we don't need multiple calls.

I love SL, but I am TIRED of things being broken through lack of foresight. This is not a bug. It is a goverance problem. Period. There are tons of things that could be done to prevent habitual griefers in SL that are not. Andrew, don't let your G-Team collegues talk you into a coding fix for a griefing problem that will break or hamper existing content. Make them do their job and... well... govern.

I quote from how Andrew Linden described the fix above:

"The throttle is target-specific so an object could handle somewhat rapid clicks from unique avatars"

There. You get 4 mapcalls per 4 seconds per unique avatar. If your content still breaks, I don't quite see the fix at fault, and I consider it a good fix given existing content, and the problem at hand.

There is nothing with adding a llSleep before the llMapDestination inside of the touch_start event. This is a totaly acceptable way to use the function. As is sending the map several extra times as a workaround for the viewer bug VWR-2060, or sending several maps for a group of people who are traveling together through a map based teleporter like my stargate or quantum portal.

Your open space comment is totaly irralavant because there are no hidden negative side effects of sending maps to people who are using a teleporter.

However there are some serious side effects to altering the normal behaviour of the map in such a way that widly distrobuted and used legacy items like stargates will fail to operate.

I have often said that griefing is a social problem, not a technological one, and that programmer should stop trying to solve social problems. Sen Pixie said it far more elegantly than I have, but no one is listening because only the anti-griefer people are being told about this JIRA. The teleporter makers are int he dark.

@ Andrew Linden

After Sen Pixie's post I relize that I did NOT take into account groups of people teleporting as is often the case with stargates. They are a very social teleporter that often sees groups of people traveling together as the explore SL through the stargate network. Your suggested fix will break this important social aspect of the stargates.

Andrew, I can no longer support the throttle levels you have suggested. They will break my Stargate and Quantum Portal when there is more than one traveler

Darling Brody.

@Andrew: "Actually, I don't think VWR-2060 is a prerequisite for a fix to this. A double-call to llMapDestination() is not going to cause any problems."

It won't cause problems if the throttling is based on the target of a call to llMapDestination(). i.e., 4 successive calls to different people works, but 4 rapid calls to the same avatar silently fails. I would suggest, however, that muting properly stop llMapDestination() and anything else that a muted avatar/object could do to an avatar.

That said, Sen Pixie is correct, and VWR-2060 is a prerequisite for another reason. You cannot apply a change like this without fixing the real problem first. That would be very irresponsible programming. Especially since you already know how to fix this bug and have refused to do so. How do I know it can be fixed? Because you already did so once. For a brief time the client popped up a landmark window and it worked flawlessly. No double-ports, no landing in the wrong spot, and no need to call llMapDestination() twice. But the mindless masses complained that things were "different" so you caved in and broke it again.

I do not understand Linden Lab's twisted logic. People beg for something to be broken and you fold like a newbie poker player. But ask Linden Lab to fix a bug that's been around for three years and you make excuses and look for something shiny to distract us.

It would probably be best to test this out on the beta grid. That's really true of all changes. If, after testing it, you find that it is not throttling properly on a per-target basis, then it would be most appropriate to mention that on this ticket, so that the behavior can be changed. However, from what has been stated on this ticket, it does appear that per-target throttling will be the method used.

As for VWR-2060, part of the problem may be either that it is not immediately obvious what the root cause of the problem i, or there may not be an obvious way to fix it that would not also break content. I am certain that VWR-2060 will be fixed at some point, but right now there is a fix for this bug in this ticket that has been developed and tested and it appears to have been integrated into the main branch code. If every fix for every bug in SL had to wait until some other bug were fixed before being implemented, every avatar would still be walking around as Ruth.

It would certainly be nice if VWR-2060 were fixed, and I imagine that it would allow for greater leeway in fixing this bug, but I'm not sure that it makes sense to hold off on releasing this fix because of that bug.

Edited to Add: I think that we also went over why muting llMapDestination() calls is unfortunately not feasible. I certainly wish that it were.

Now when all the map based teleporter start breaking and the creaters are flooded with complaints there will be demands posted here to roll back this fix until the VWR-2060 is fixed. Of course it will be too late, because the damage to the reputation of the teleporter creaters will have been done. But who cares about all those creaters and there customers when we are busy playing the griefer card to ram through a bad fix!

Darling Brody

And I think that this bug was fixed first because the fix was far simpler. The bug in VWR-2060 strikes me as being one of those really hard to find bugs that's hidden somewhere in the code. This bug was glaringly obvious, and there was a fairly simple solution.

You are at 254683.7, 255363.3, 2001.4 in Sandbox Island Extension located at sim5.aditi.lindenlab.com (8.4.131.198:13001)
Second Life Beta Server 1.26.0.116361

I tested only using a rezzed box, with all functions occurring in a touch_start() event, with myself as the owner as well as the person doing the touching (and thus receiving the requests).

I found that there is now definitely a throttle for llMapDestination(). 5 calls to llMapDestination() in a row triggers the throttle. However, placing a 0.25 second sleep in between calls does not seem to trigger the throttle. Using loops, with a 0.25 second sleep and an llOwnerSay() incremented integer count per iteration, I counted well over 60 before I eventually reset the script so it would stop spamming me.

Placing a 0.1 second sleep will still trigger the throttle after 5 attempts.

This is both good news and bad news. It is good that it will take at least 5 calls to trigger the function, thus ensuring the likelyhood that teleporters will not be harmed by this change. The fact that a short sleep prevents the throttling is good for teleporter makers as well. However, it is disturbing that a short sleep will still allow the function to be useful for map spamming. Basically, where an older map spammer that simply looped calls to this function would likely hit the throttle, the simple addition of a short sleep ensures that the object can continue to spam map calls indefinitely.

I am not certain how to overcome this problem. I am tempted to suggest adding a second throttle, if possible, that would cut off map spam after the 30-second or 1 minute mark if it were above a certain number of requests, but I would worry that this might impact legitimate functions if someone were to click on it multiple times.

I'm not sure what the solution to this would be. It is frustrating that such a useful function is unfortunately open to being abused, and it would be nice to be able to stop it.

Reference : http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.26

Issue : SVC-1038[c] Limit llMapDestination to one call per event to prevent "map bombing"

I assume this is is just an old description in the release notes and not a new throttle?

Darling Brody

If the timer is "per-event" ... reset on each click ... that wouldn't be a problem.

Actually, your "reset with each click" remark gives me an idea. llMapDestination, when called in a touch_start() event, knows the UUID of the person touching it, independent of needing to call llDetectedKey(0). What I'm wondering is whether it would be possible to cause llMapDestination() to "forget" or "reset" the clicker's UUID after 1 minute. This would prevent someone from simply looping calls to llMapDestination() with a short timer to avoid the throttle, because it would become ineffective after 1 minute, unless the object was clicked upon again.

I would think that this shouldn't pose a serious problem for teleporters, since we'd only be talking about non-owners (in another ticket, LL altered the behavior of worn objects such that they only responded to touch_start() events if clicked on by the owner, indicating that the script knows this independently).

So if a non-owner clicks on an object (or it could be set as behavior only for non-attached objects, either way it would have a similar effect), llMapDestination() gets called to the clicker's UUID, but gets "reset" after 1 minute. If, for some legitimate reason, the non-owner needs to bring up the map again, clicking on the object again would work, causing the UUID to again be stored for 1 minute each time that it is clicked.

The point of doing this is twofold:

1. It prevents objects from being able to endlessly spam, even if they are below the throttle threshold

2. It also prevents script accidents in legitimate objects, and may help clear up unnecessary script memory overload, by having the garbage collector get rid of the stored UUID. There isn't any reason for llMapDestination() to be holding the clicker's UUID in perpetuity until the next click anyways.

Now, hopefully this could be done without accidentally resetting the results of llDetectedKey(0), but even if this did cause issues with llDetectedKey(0), most of the times, in my experience, that this function is called in a touch_start() event, it is only stored briefly for conditional tests, as in:

touch_start(integer touched)
{

if(llDetectedKey(0) == llGetOwner())

}

or else the UUID is assigned to a global variable if it needs to be stored and used in another function anyuways (and presumably such a global variable would not be affected by any of this, once it's set):

key av;
integer avlisten;

default
{

touch_start(integer touched)

listen(integer channel,string name,key id,string message)

}

This would be an example of a script where the UUID of the toucher does need to be stored, but in this situation, it would be stored as a global variable, because it needs to be used in another event. This would presumably not be affected by any resetting, I would hope.

Would such an implementation be feasible? And would its implementation have minimal effect on (non-spamming) products?

We have been over this already!!! if the touch_start event loses the ability to send a map based on a timer then any product that captures the click for the purpose of sending a map at a later time will fail.

// "WAIT" is set in object desciption and removed when the avatar being teleported has walked though the stargate.
touch_start(integer x)
{
do {sleep(1);} while (llGetObjectDesc() =="WAIT");
llMapDestination(......);
}

These are just two example items that capture the touch and have a delay before sending the map.

1) A stargate takes about a minute to go though a dialing seqence after it has been touched, so under your 1 minute timer suggestion the ability to send a map is lost before the stargate has opened the wormhole which the avatar needs to walk though!

2) A tardis that captures the touch on the door switch and gives a map as you walk though the door can also fail if the avatar dosnt RUN through the door fast enough.

Your assumption about teleporters being used by their owner more than visitors is totaly wrong. other people use your map teleporters far more than the owner does. Especialy the type of teleporters that people like to go exploring with groups of friends, like stargates.

It is arrogant to say non owners can just click again. Your not the one who gets all the complaints from owners who dont understand why a product that worked for 4 years all of a sudden needs to be touched more than once to work. Breaking good content out of fear of bad content is stupid. It is bad for SL, bad for Linden Labs, and bad for the future of SL. Content creaters need stable standards to build products, and customers need to be able to buy somthing and know that it wont stop working because of some bad-fix.

Explain why is it nessisary to push for even more draconian limitations that will break a wide range of products before the current throttles have even been applied to the grid? Are you determined to break the teleporters?

Darling Brody
Griefing is a social problem than needs a social solution, not a technological one.

The reason why I am asking about additional limitations is because I went and tested the current throttle on the beta grid and found that it did not appear to be sufficient to solve the problems that have been noted here. llMapDestination() can still be spammed quite easily. I was hoping that there was a way to cut off map spam that was set to continuously send at a rate just below the throttle, which is still fairly fast.

As for social solutions to this problem, I've suggested one before: Permanently ban the accounts of people who sell and distribute map spammers. There's a social solution for you. Since that appears to be infeasible, and since persuading the people who sell and distribute map spammers to stop doing so also appears to be a non-starter, technical solutions are the sole remaining option. If you don't wish for a technical solution, if you wish for a social solution to be implemented, then by all means, suggest one. Feel free. Nobody is stopping you. But you haven't suggested any possible solutions to the problem of map spammers.

Now, would starting a 1 minute (or some similar interval) timer after the first call to llMapDestination(), after which the UUID target for llMapDestination gets reset until another touch_start() event be a feasible solution here? Would this leave your products secure...well, your legitimate products at least? Would this allow teleporters to function?

Are you able to do that? If not, then FORCE the llmapdestination() to a SINGLE popup per click, no throttling, no timeouts, no anything, after i've clicked a megainvisiprim with a infinite loop that would spam me, annoying me for the rest of my second life days, i should be able to block it IMMEDIATLY. I won't listen again from a Linden: "WE CAN'T HELP YOU, YOU SHOULD ASK FOR A SIM ROLLBACK" ...this is insane. Asking for a sim contantes rollback, because you are unable to locate a griefing object? Are we joking? Come on. The next time it happens, i'll start to ask for a refund from Linden Lab for each second i loose because im UNABLE to use the platform anymore.

So again: please limit that map spamming to ONE mapdestination per click, until you give to me the possibility to know about the object, owner name, and mute the attacking object/owner.

Thank you.

I own a major business in SL that uses llMapDestination in the entire 150 product line. I am also a member of one of SL's leading community activist/anti-griefer groups. You simply have to way all sides of a major change like this. Simple fact, any signicant change to the function of llMapDestination will break tens of thousands of items in ways none of us could have predicted. For every griefed SL citizen, you would almost certainly get two or three customers who basically got griefed by LL.

Think about it... we all hate being griefed because it affects our SL experience. Sometimes even stops it completely. I can just see ten of my customers arranging an RP session for months that involves people from all corners of the Earth only to find that their TARDIS can no longer let large groups in and out properly because of some unannounced change to one of the hundreds of LSL functions in it.

I work on both sides of this fence every day in SL, and I honestly believe that any significant change to llMapDestination (like forcing permission with every instance) would do far more damage to SL than the current griefing.

I've exposed the fact multiple times, maybe i haven't been clear, so i must repeat it: LL is UNABLE to locate the offending object and erase it, neither is capable ot identify the "abuser". If Andrew Linden or Maestro Linden will publically admit (here) that this is NOT the situation anymore, read: "We are able to identify the object, punish the offender because he/she's wrecking the TOS, and resume your client usage", so it will be ok for me.. because it would be managed and solved as any other abuse.

So yes: MY side (the user side > inworld experience > possibility to use second life > not being blocked out without i do anything) come before any merchant, that would include you and even me or any other merchant.

Do you recognize that i can block you out of a certain SIMULATOR without you can do anything to return there? Replying "YES" to this question is enough to figure that this must be blocked: NOW!

That's my point. I know that any significant change to llMapDestination would affect my business and several others. That would loose LL and me money. Not much in the grand scheme of things, but it's still money. SL is a business operation. If you don't look at it through that lense, you will always be nothing but frustrated and angry with LL.

Like you, i'm paying Linden Labs 435 euro per month, as you said it's not that big in the general scheme.. but we're not discussing the economic convenience of a fix, but the fact that IT IS possible to infringe the TOS and not being caugth because of it, and being able to lock people out of the game in a such easy way. That's totally outside of the principle of Second Life as "service". You can even read about this on the homepage:

-
5. What if someone annoys me in Second Life? Can I "mute" or report them?

Yes. Like real life, you may encounter people in Second Life that you wish to ignore. Unlike real life, in the Second Life virtual world there is a simple button that you can click to mute them. If only real life were that easy. Click here for more info on muting Residents. If you believe that another Resident is violating our Terms of Service (TOS) or Community Guidelines, you can file an abuse report. Here is a video tutorial on how to report abuse or handle griefing.
-

That's one of the key points on Second Life, it's not "all about money" as you say, but the user experience (ironically "the users" are those ones that are actually buying from merchants!). when you get attacked by this particular exploit:

• You cannot "mute" the grifer neither its object;
• You cannot abuse report the abuser because you don't know who is he/she;
• You cannot continue to use the platform as intended because LL isn't capable to solve the problem on its own platform.

In any IT business, in this situation, you would immediatly block the source of the problem, think about a fix, deploy it, and fix the problem. You wouldn't "ignore" it, because some merchants are saying that their business is much more important than other residents.

And definitively the affected merchants/residents of solution based on a "one call per click" (until something better comes...) are merely speculations, since you talk about "thousand ppl", i may have a different idea, and i would tell that none would even notice it apart those ones that are selling the griefing tools (that's IMHO the main reason why this JIRA is fullfilled of discussions while the fix should have been deploied immediatly). But again that's MY opinion, so it's better to leave "our numbers" out of the (potential) solution, because none of us may be right, since neither me or you really know about how many persons are using this in the legit way and now many others are using it to greif other ppl.

I got the impression from Linden comments that the timer is per-event anyway.

Look at how long it took for people like Cheshyr Pontchartrain to find this JIRA. He is a BIG TIMER scripter in the DoctorWho tardis community. That community makes extensive use of the map for teleporting. A large number of Tardis products use the delayed map method too.

No further throttles or limits can be placed on the map without breaking content. As I have said before it would be arrogant of us to think we can anticipate every valid use of a function.

Where we are now
===============

The throttle Andrew Linden has created will break all existing map bomb scripts posted on griefer websites. It also slows the attack to a level where the victim will be able to leave the region or use land tools to remove the offending object. The attack is no longer capable of being used as a DOS.

What Next
===========

You should be pushing for the second part of the defence, to add a mute, and origen to the map, and to be able to add the map to the things BUSY mode blocks.

Andrew's change makes map bombs into an anoyance instead of a cripeling weapon. Add maps to BUSY MODE and your immune, until the full MUTE is possible.

Darling Brody.

I have tested Andrew's throttle on the Beta Grid. I summarize my tests in a previous comment. The current throttle level does not slow the attack in any considerable fashion. It may break existing map spammers, but I have no doubt that you have already updated your map spammer to get around the throttle. As I mentioned earlier, adding in llSleep(0.25); in between calls to llMapDestination() or in between loop iterations will prevent the throttle from kicking in. The result is that the map still pops up at slightly below one call per second. This is in no way a long enough interval for the victim to do anything useful. I know this because I tested on myself. The attack is not slowed in any considerable way, certainly not enough to make a difference. I was still unable to type a single sentence in chat. I was unable to pull up my inventory, such as someone might do to use a landmark. Teleporting home or relogging is still the only option.

So this throttle, at the moment, does not seem to solve much. It will make existing map spammers break, but as I said, they would likely be updated to get around it. The attack is still capable of being used as a DoS, and I am glad that you have finally acknowledged that its use is, in fact, a DoS-style attack.

Andrew Linden already stated in a previous comment on this ticket that it is not possible to make llMapDestination() mutable. It would be wonderful if we could make it mutable, but that does not appear to be an option. However, since you did announce to your group that you have been hired by Linden Labs, maybe you can correct us on that.

As I have said, after testing these changes on the Beta Grid, and I found that they did not significantly slow down repeated llMapDestination() requests, but only managed to stop them if they were sent with no pause in between.

• You cannot stopping the attack by changing the sim! The map spam will continue even if you TP elsewhere from the originating SIM.
• You can stop the account logging out, and the relogging into a DIFFERENT sim that those one where the attack had the origin BUT you cannot return to that sim anymore, as soon you step into the SIM you gonna being spammed again even without "clicking" the offendign object.

And when i say anymore i mean litterally anymore because to return there you must have the good phate to find a skilled owner (if it's not you) that would scan the entiere SIM to find the offending objects (considering that there's no precise path to find that objects; neither scripting time is an indication in a sim fullfilled of other scripts and with multiple objects owners). You wouldn't even asking Linden Labs to "solve" the problem because they are unable to do.

Really guys i cannot believe we're discussing this, i feel like those people that would repeat "the sky is falling"... with the difference that i'm not exagerating the situation, neither i'm dreaming, this is the truth... but you already know, and that's why i'm asking (at this point to myself): what the hell are we discussing here?

It might make sense to place the throttle higher. Perhaps 4 times in 8 seconds....or perhaps extend both the number and time of the throttle, and make it 10 times in 30 seconds, or 10 times in 60 seconds. Would legitimate content be likely to call llMapDestination() on the same target 10 times in 60 seconds? Would it be likely to call it 10 times in 30 seconds? Placing a throttle at those limits would dramatically lower the number of times that the map could be called per-second, while also allowing for a longer cool-off period, and at the same time, increase the cap limit so as to minimize the odds of legitimate objects being affected.

"I have no doubt that you have already updated your map spammer to get around the throttle"

You are wrong. Stop making assumptions about my actions.

"The attack is still capable of being used as a DoS, and I am glad that you have finally acknowledged that its use is, in fact, a DoS-style attack."

I have not. but i got tired of arguing abotu the TERMS, so i used your prefered term. Stop putting words into my mouth.

"Andrew Linden already stated in a previous comment on this ticket that it is not possible to make llMapDestination() mutable. It would be wonderful if we could make it "

He didnt consider making it BUSY. The map packet can be ignored when in busy mode. This does not require the source of the map to be known, which is the reason a traditional MUTE cant be applied.

"automatically sleeps the script for 1 second."

If the wiki says that, it is wrong. I have found no sleep after a map call in my testing. Perhaps someone has incorrectly added the sleep as the description of the throttle?

"Perhaps 4 times in 8 seconds....or perhaps extend both the number and time of the throttle, and make it 10 times in 30 seconds, or 10 times in 60 seconds. "

...and if Andrew Lindens gives you that, you will just complain that the spammers are rescripted to stay below that level. Your not going to be happy until the function is broken so badly that it cant even be used for teleporting!

A better Solution
==================

Alter the server and viewer code to support a new map packet that sends the required information for muting. Then add a mute to the map page.

In the meantime include map in the packets that are dropped by the BUSY MODE.

@Argent Stonecutter

"There absolutely needs to be a hard maximum to the number of times this can call up a map. It doesn't matter if it's two, five, or ten, it can't possibly be allowed to keep spamming people indefinitely. "

What about an orienteering / tour system that might give you dozens of maps over a very long period of time? Such a thing is legal, within specs for the function, and totaly innocent!

Once again we are talking about people attacking other people. That is not the fault of the scripting language. Why break the language when we should be banning the griefer?

Darling Brody.

Reply: because you don't know who the ***** griefer is (neither Linden Labs knows). And until this information is provided, a placeholder must be applied with a top number of calls per click, until you can AR the abuser and mute along with his spamming object(s).
------------------

The funny part of this JIRA is that the thief is involved into the discussion on how to adjust the security system of the bank that he's actually robbing.
Ding dong... wake up.

Maybe you should look more carefully at the accused theif to see if she has significant deposites at the bank in question.

The origen of the maps can be traced by LL. If they can add throttles, they can add logging to trace the source for GTEAM members to view.

Darling Brody

Not relevant since the robber would grab others money along with his/her ones.

The origin of spamming object (location/key) or the object owner cannot be traced (not applying am important modification to the code), neither by LL/GTeam, that has been already mentioned before. For the same reason it's impossible to add (at the moment) the same informations you would receive from other incoming packets, otherwise all these throttiling weren't required at all > you would have been able to just mute the spamming object/owner, that would be probably the solution that will be applied when LL will have time to implement it (if they ever decide to do so).
Blatant comments.

http://jira.secondlife.com/browse/SVC-1038?focusedCommentId=93715&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_93715

**I've picked up the internal version of this bug because I happened across it during a triage pass and it looked easy enough to fix server-side while waiting for other projects to compile. It is pretty easy to throttle this, but it is much harder to make llMapDestination() mutable (VWR-3560) because the legacy UDP message format would have to be changed... and we're not allowed to change it anymore - we can only create new (TCP) messages through other pipelines. **

Now granted, he was discussing mutability, rather than simply tracing the source. However, I suspect that the two issues are related. For the record, I've done a bit of work examining this with a packet sniffer and haven't been able to find the specific packet involved in llMatDestination(). There are a number of packets related to maps, of course, but they all seem to be triggered by simply manually opening the map as well. I can't seem to find a packet specific to an external object calling llMapDestination(). Now, I haven't looked into this very deeply, so it is entirely possible that there's a Map-related packet that I haven't examined, but I've gone through all of the currently documented map packets and have been unsuccessful so far.

Thus, I suspect that Andrew's statement likely applies to tracing as well as muting. Of course, as I mentioned, it may be that I simply haven't found the relevant packet, and if someone else knows of the relevant packet, I'd love to know which one it is. However, at the moment my own experiments seem to confirm Andrew Linden's statement that the current message format does not lend itself to these sorts of measures. This is unfortunate, but I suspect that nobody at LL had reason to suspect, at the time that this feature was developed, that it could be abused in such a manner.

Now, on the one hand I can see the point that LL's developers should consider the abusive possibilities behind code, but I do not think that it is fair to expect Andrew and others to be able to anticipate every possible abuse method, nor would it be a very good use of their time to worry about the ways that new features could be abused, when that time is better spent refining and testing these features. In fact, I consider it extremely unfortunate that talented programmers have to take time away from fixing bugs and developing new features to deal with issues like this one, simply because certain residents cannot resist finding, exploiting, and marketing for profit abusive methods for destroying other residents' SL experiences.

It is unfortunate that some residents find a bug in a function like llMapDestination, or like llSetLinkPrimitiveParams() before it, or llGiveInventory() before that, and decide to exploit it, use it as an attack against other residents, and even worse, to market those attacks so that thousands of other residents can use them as non-consensual weapons to the destriment of others. It is these actions that make fixing bugs like this such an important priority, thus forcing programmers and developers to take time away from more important projects.

Fortunately, the vast majority of SL scripters, when they find bugs like these, report them on the JIRA or else at least alert the larger scripting community in the hopes that someone else will file a ticket. This is simply good coding practice. When you find a bug, especially one like this that has the potential to ruin someone else's experience, you report it. To instead use it to attack other residents is to act like an adolescent who has just discovered that certain vulgar words will elicit an amusing response from other people. In fact, the mindset almost appears to be the same: "Teehee, look at their reaction when I push this button."

After all, there's a reason that we call people who create, use, and market "attacks" like this one "script kiddies."

Thank you, Andrew, for your efforts to fix this bug. I wish that it were not necessary to have to ask you to divert your time and energy to issues such as this one, but unfortunately it feels like every time there is any loophole in the system that might allow one resident to abuse another, some script kiddie somewhere will exploit it.

People can now break my entire structure. For example, a customer rezzes the entry point in a crowd. Some slightly informed idiot sees the doors open, and clicks on the map prim repeatedly until the script error comes up. They have now locked the rightful owner out of their own structure. I verified this through tests. I had one person successfully lock me out of my own home just by clicking a couple times a second.

You "fixed" one form of griefing by creating another, and this one breaks existing content. I'm curious, while the map bombing was bad, how many businesses did it threaten? Because now I know of several that are, including my own.

I have been fighting to protect teleporters that support *** groups of people traveling together *** using a map for months now. But as normal the creaters never find out about bad fixes until after they have been rammed though by an uninformed mob of people shouting griefer.

My stargate and tardis also suffer from the same problem now. As will every map teleporter in SL. When a group of people are traveling and all touch the teleport prim the script breaks.

The throttle should have been Per avatar!! That is more than xx maps over ss seconds to the same avatar triggers the throttle.

You will need to open a new JIRA and link it to this one saying that the throttle needs to be altered to a per avatar throttle to fix 6 years worth of content that will now break.

Darling Brody.

ps. Andrew Linden, I told ya so!

''group of avatars all wanting to hit a stargate simulataneously and it breaks?'' Can you give the exact steps to reproduce that one starting with how many avatars need to click the gate at the same exact moment in order to break?

Let's get serious - the only business that was threatened by the fix was the business of profiting from LSL exploits and if these are the only 'problems' that can be conjured up after the exploit fix, it's a long way from Andrew having to worry about an I told you so O.o

In the case of a tardis the only way to simulate a bigger inside than the outside is to teleport people as they exit the building. As people like to take groups of friends on adventures with their tardis, their will be several NON-OWNERS all wanting to touch the prim at once to get a map.

A stargate is similar, in that a group of non-owners will often travel through it at the same time and will all want to click it at once. Especialy when the stargate's have traditionally only stayed open for 15-20 seconds.

There are a number of stargate networks who's creaters are no longer activly updating the products even though they still work. There are also a number of tardis' that are also not updated or were sold before their creater kept records. They will all break and remain permenantly broken without any warning when a small group of people travel together.

Jahar Aabye's fix will not work as only the owner would be able to get a map.

As I have said many times in this jira. it is arragant to assume we know all the uses for tha map teleporter. I myself am a tardis owner and i totaly forgot about that one when posting here and talked only about the stargates.

This needs to be a per avatar throttle so you can send as many maps as you like so long as they are not to the same person.

This is known as the law of unintentional consequences. And given how broken the result is, I can't even summon up a healthy dose of schadenfreude over it. I'm genuinely sorry.

There are frequently RP events in my sim that have 10 or 15 people entering and exiting a single TARDIS at nearly the same time. This will always break now. Every time. Again LeekAlpha, I did provide steps to reproduce. I had a friend stand next to my TARDIS doorway (call it the TP entry point) and just slowly click the map prim steadily. Two of us then tried to exit while he was clicking. We were locked out. And as the script errors compounded, it countinued to be non-functional for some time after he stopped clicking it.

Now, I don't expect everyone to be sci-fi fans. But TARDISes, Stargates, and similar devices are BIG business in SL.

And really Argent - did the words "less broken" just leave your fingers? Is that how bad things have gotten? How about this LL - just give us a better system of Teleporting for crying out loud!

PROBLEM HERE

When more than one person is trying to use a teleport the throttle is hit and the teleporter breaks. As people tend to click again and again when it didnt work the first time the throttle stays in effect until the people give up trying to use the teleporter thinking it is broken.

See above comments on a Tardis teleporter that has broken since the original fix rolled out to the grid.

FIX HERE

A quick fix for this would be to "reset the throttle counter when the prim is clicked" thus preventing multipal clicks from locking up the script.

Issue has been re-opened and set critical because it is now breaking content !

SVC-4453

Edit: Monday's triage @ https://wiki.secondlife.com/wiki/Bug_triage/2009-06-29

According to Andrew Linden:

"it is a region wide throttle keyed on the key of the target"

Now, what this should mean is that the throttle is tied to the number of llMapDestination() calls sent to a specific agent. At least, as I understand it, the intent of the fix was that if an object was scripted to call llMapDestination() twice keyed to the person who touched it, and Gordon, Sen, and Argent each touched it all at roughly the same time, it would not trigger the throttle, because no more than 2 requests were sent to each agent.

So one possibility is that somehow the fix that was implemented was not or is not working in this manner. However, we might want to first test and rule out the possibility that the objects in question might be sending multiple requests to the same key. Could multiple touches from separate agents roughly simultaneously cause issues with llDetectedKey()?

I may not have time to test today, I just finished up several hours of intense scripting and have a full to-do list still to go, but I'm curious whether there is any difference in behavior between using llDetectedKey(0) and using some sort of incremented loop with llDetectedKey instead.

Can we confirm that the llMapDestination() calls are all going out to different keys? If the fix was intended to throttle on a per-key basis, let's make sure that these calls are being sent to different agent UUIDs first before assuming that there's a problem with the fix.

Andrew's throttle is definitely not working as intended. It's very obvious that it completely ignores the target key, and likewise obvious that it was not tested before deployment.

please clarify which content is broken, the map destination spammer in your weapon, or the trademark violation "Stargate"?

How was your comment constructive to this jira? I mean besides serving your need to harass me in an attempt to make yourself feel better?

Darling Brody

Leaving this jira open will not get the new bug fixed. A new issue needed to be opened, otherwise any votes here will be considered as support for the original feature request, instead of the bug created when the request was implemented.

People wanting to avoid having their product broken when they are touched by lots of people need to vote here :- http://jira.secondlife.com/browse/SVC-4453

Clearly the throttle should reset each time the touch event is entered to prevent a teleporter from being broken when more than one person touches it. As a spammer must loop inside the touch event without exiting, there is no risk of re-enabeling spammers by applying a reset at the start of the touch events.

I have been true to my word and not rebuilt my original 2006 map bomber to get around this throttle.

Further a map every 10 seconds will not prevent you from being able to teleport to another region using a landmark or ctrl-shift-home. What make the original bomber so powerfull was that it prevented teleporting away too.

Map bombs are now a usless weapon just like llLoadURL and llDialog spammers. ie. anoying, but not cripeling.

@Darling, I'd suggest politely asking Warkirby to set the issue to closed which barring a Linden deciding to reopen it, would keep it closed, since it's been a year and a half since his last comment here I'm not sure what his view is on the solution or even if he still follows this issue but it's worth a try. Barring that you could ask Andrew Linden to close it since he was the one who liaised with getting the fix done.

Really this issue as it is has been solved, if you want to change it back or change it in other ways there are already some existing issues or just start a new one and link it. Other than being stubborn I don't see any reason why people keep reopening this when they know that a new issue will have a better chance than trying to keep this issue afloat.

"Then the weapon simply traps itself in an infinite loop, and spams the user endlessly"

^^ Not resolved.

"Much like blue dialogs, the map takes focus, and fills your screen"

^^ Limited but not resolved.

"One, is that there is no indication of the source of an llMapDestination call. Unless you inspect the object before clicking it. And if the object is large and invisible, and you click it accidentally, you're certainly not going to check it first. Add to this, the object shrinking to tiny and invisible, and retreating to a distant corner of the sim, and you can be attacked anonymously"

^^ Not resolved.

"llMapDestination cannot be muted"

^^ Not resolved.

"I believe the best solution to this, and the one with least impact, is to limit llMapDestination to be called only once per event"

^^ This is the original proposed solution, we can read it as a certain number of events per click (hardly limited).

So again, i really see no reasons to close this JIRA as "resolved" since none of the above points (wrote by the original poster) has been "resolved". And additionally, i'm really disappointed by the fact that someone that has interests into NOT fixing this, has closed it already two times. This is childish.

That is not correct. The region will not transmit anymore map packets once you leave the region, however there may be some internet lag before all the packets that have already been sent reach your computer. This creates the illusion that it comtinues to work once you leave the region. Give it 30-60 seconds in the new region and it will stop. Also keep in mind that you are considered to be in the region until the teleport completes. This can also take another 30-60 seconds before the original region removes you from it's active avatar list.

A hard limit has been discussed for months and Andrew Linden agreed that a hard limit would break content. This function still needs to function as originaly designed and documented. The throttle already added has been done incorrectly and broken a number of products that were not doing anything "tricky" at all. As things stand now you only need 2-3 people to attempt to use a teleporter at once and it will break. This is a serious issue for a busy region, or just a group of people treveling together. Further Limits will only break more stuff.

MapDestination() placed in a loop no longer spams someone so hard that they are unable to use second life. It is now possible to teleport out of the region. The next step should be a MUTE in the viewer to block ALL maps for those times you want to locate and remove the offending object.

The Lindens correctly set this issue to FIXED. If you want to alter the fix they imposed (as I have in a linked jira) you need to also open a new jira. Lindens will likly ignore this JIRA as their internal jira shows it as fixed.

• I've awaited 30 to 60 minutes and it didn't stopped.

"A hard limit has been discussed for months and Andrew Linden agreed that a hard limit would break content. This function still needs to function as originaly designed and documented."

• Breaking contents is something necessary to fix an exploit. It happened in the past, so it's not an "excuse" to not fix it properly.

"MapDestination() placed in a loop no longer spams someone so hard that they are unable to use second life."

• Being unable to stop the attack, and forced to move outside of a region is enough to affect your inworld experience. Imagine it in a sandbox.

"The next step should be a MUTE in the viewer to block ALL maps for those times you want to locate and remove the offending object."

The acceptable fixes are:

a) Hard limit the map popup;
b) Being able to mute (or automute) the object and the object owner after a very limited number of multiple requests (ie: 3).
c) Being able to identify the object owner to Abuse Report him/her, and being able to identify the spamming object coordinates to locate and mute/remove it.

Until this bug is fixed (until none may spam your avatar, forcing you to leave a region, because neither the spamming object or the offeder are identifiable (even if the research is conduct by a Linden [that is proven already]) this JIRA cannot be considered "Resolved", therefore i'm reopening it.

Stop re-opening this issue. You need to make a new one to have altered behaviour of the implemented throttle.
Read the JIRA rules!

You also need to read all of the comments posted by the lindens to this issue. You are repeating arugments that have already been dismissed as either undesirable or not technically possible by lindens.

PS: Andrew Linden did not say one word on this page about the undesirability of a hard limit, which is the real fix we're looking for.

I like this summary of the options:

(a) Hard limit the map popup;
(b) Being able to mute (or automute) the object and the object owner after a very limited number of multiple requests (ie: 3).
(c) Being able to identify the object owner to Abuse Report him/her, and being able to identify the spamming object coordinates to locate and mute/remove it.

I don't think (a) would work – too much content will be broken.

I was thinking that (b) would be a client-side fix, but I just had a neat idea on how it might be possible to throttle all sorts of stuff server-side. It isn't as small as a client fix, so I'll have to bounce the idea off of some other LL devs and it would probably be a year or more before it would complete even if we started today. I mention it here only because I just thought of it.

As I recall the owner info is not embedded in the message that triggers the popup. The message would have to be changed to enable (b) or (c). I may be wrong in my statement that message formats cannot be changed. There might be a way to change some messages – I'll have to ask around the lab to learn more.

Personally I think (c) is the best. But I understand it would take time to implement. We've gone for five years with a buggy llMapDestination that doesn't work right and isn't finished. Let's do it right - fix the coord bug, utilize the rotation feature that was never implemented, and solve the bombing problem with something like (c). If we're not going to get llTeleportAgent, then let's make sure our only method of intersim travel works well.

Anyway back to the original discussion: i like both b) and c) ...since a) cannot be applied it seems; while at the same time i think that temporary applying an hard limit would do the job until b) or c) can be deployed. I'm on the same side of Argent: i think that a big cut number wouldn't affect most of products, it would continue to being used to spam you (because of the high limit) but at least it would be for a limited amount of time, and not "forever", so you would have the concrete option to wait for the spam to finish and finally continue, without being forced to leave the region, and especially with the possibility to return in the same region because the spam is finished (that is more important).

http://jira.secondlife.com/browse/SVC-4453

I have descripted somthing that will probably be called a Sleep-Throttle or somthing. It is a way to apply a throttle that will break badly behaved scripts while letting legitimate content run.

Andrew Linden should consider that for ALL throttles, and the stupidly long sleeps applied to stuff like email.

Darling.