The dialogs also need a mute-owner button if the object is not the owners'.

Mute Owner on dialog should be out of the way, say small and upper right hand corner of the dialog, and require confirmation.

(I am adding this comment to all relevant jira issues in the hopes that someone will finally get their thumbs out and pay attention)

In addition to being a really irritating griefing tool, the blue dialogs stealing focus can be troublesome when you keep get interrupted mid-typing when you're trying to use text chat.

Or, in other words: NO viewer message and NO Operating System message that needs user confirmation, e.g. by pressing "Enter", may be allowed to steal the focus while the player is typing in chat or IM.

Imagine the situation that the player is entering an IM or chat message and is just pressing "Enter", while in the exactly same second a viewer or Operating System message pops up that needs to be confirmed by pressing "Enter", too. The player will press "Enter" - but not because he wanted to confirm the pop-up viewer message, but because he wanted to send the IM or chat.

This is a general bug, not only in SL, but in any other software environment (imagine an Operating System message that pops up while you are playing SL and are about to send IM or chat and confirm it by pressing "Enter" -> the OS will misinterpret your pressing of the "Enter" key as a confirmation of the OS message, which it is NOT).

So: please change this behaviour in SL completely. No message box whatsoever must be able to interfere with chat or IM typing!

Concerning the flooding: this is not only an issue concerning "blue box messages", but any other flooding, too. I have often enough been in a situation where a script was flooding sims with temporary items floating around, one time it were dozens and hundreds of images flowing in the sim, another time it was floating objects with attached annoying sound. The servers should block any "flooding" abuse of scripts, whatever the scripts do.

This is a general issue that needs to be fixed. As of now, it's a basic architectural problem of SL.

I agree in general that more things that can be used for annoyances/griefing, like this, should be mute-able.

The problem here is that the dialogs can pile up indefinitely. And the solution to it is a client side stack depth limit and/or a serverside throttle on the use of such functions. I'd really like to see both implemented, personally.,

As for crashing the client, there a quite a few different ways to do that and I can't see a stop to the evolution of technology any time soon. Adding something to your product that allows this ability is not a wise idea..

EDIT: The attacks are getting worse. I cannot even sign in without getting spammed off of SL. Why should I pay money for a game I cannot play? At the very least, muting the person should stop the dialogs, but it doesn't.

EDIT2: I decided to do a little digging around in the code while I'm unable to log into second life. It seems that when a LLNotifyBox is added to the stack, if it is crammed in the back, it is set to visible, which causes intense clientside lag. It should be set invisible, although that's only part of the crashes. I sometimes receive so many that regular SL traffic can't get through and the sim logs me off.

If you are having issues with some kind of dialog spam, it must be from some other function other than llLoadURL

((CLOSSED))

http://wiki.secondlife.com/wiki/LlLoadURL <---- 10 second sleep after each dialog

There is also another JIRA i listed about the BUG introduced by this fix that also slows down a URL given to the owner when their own HUD opens a URL for them.

http://jira.secondlife.com/browse/SVC-3514 <--- bug cased when this issue was fixed.

You will not see a linden post to this jira because they fixed it and posted to another one.

((CLOSED))

I was JUST CRASHED by llDialog spam two bloody minutes ago. READ THE JIRA, THIS DOES NOT PERTAIN TO ONLY llLoadURL! This is about ALL blue dialogs, NOT just llLoadURL. llLoadURL is handled by a different class in the client now, and LLNotifyBox, the class that handles llDialog() boxes and several other important notification systems, IS STILL AFFECTED BY THIS PJIRA. DO NOT CLOSE THIS UNTIL IT HAS BEEN FIXED.

Note this JIRA was original about llLoadURL which was fixed. Someone recently renamed this JIRA to cover all dialogs. A new JIRA should have been opened as it is unlikly the lindens will look in on a jira they have previously fixed.

I am sure it is an abuse of the JIRA to rename the jira heading just so you can grab all the votes from the issue and say the problem has existed for 2 years by having an older number. but, hay, if that is what you people want to do.. go right ahead.

The basic bug is the same whether one is using llLoadURL() or llDialog(). Yes, it is a different function on the LSL/VM side, but this is a VWR ticket about the client-side effect that blue dialog popups, whether caused by llLoadURL() or llDialog(), have on client performance. A fix was put in place to prevent one method of blue dialog box spam, involving the llLoadURL() function, but the ticket itself cannot be considered to have been fixed, since the initial complaint was:

"Blue dialog boxes are a nasty weapon, as I'm sure we're all aware. In addition to the focus stealing, they are also capable of overloading the victim's viewer. By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load."

As blue dialog boxes are still capable of overloading the viewer, the issue should remain open. As this involves the ability to overload the client, Critical is an appropriate level. Hopefully a fix will be possible soon. As it is, this exploit is as simple as a single function called within a loop. Having such basic open exploits in any coding system is simply a bad idea. As SL continues to expand, it is essential to close off these exploits in the code, especially something like this that is so simple that someone fresh off of Help Island with only a basic rudimentary grasp of LSL could probably execute it.

I missed you. been so long since I have seen you post.

Thanks for the input.

SERVER-SIDE: (Will make a new JIRA for this)

• Throttle llDialog/llMap/llRequestPermissions for the RECEIVING USER (not the script or object) to, say, 1 per second. THis will prevent some guy from running around on several accounts planting llDialog spammers all over the place to spam someone.
• Excessive llDialog/llMap/llRequestPermissions calls from the SENDING OBJECT should set the script to non-running.
• llDialogs should only be sent to a user if the object is within the same sim.
• llDialog, etc network messages should be given a lower priority than connection-critical SL traffic, to prevent logouts from excessive llDialog spam.

VIEWER-SIDE:

• No more than 10 LLNotifyBoxes in the stack at a time.
• Dialogs sent to the stack should be sent to the back and HIDDEN unless there are no dialogs active to prevent SL from crashing.
• Allow ALL lsl-sent LLNotifyBoxes to be muted.

— You do mean if the destination person is not the object owner dont you? Or are you going to make people using a dialog based menus wait a whole second before they can click on the next menu? (a second is a very long time when you have clicked a button and your waiting for somthing to happen, like the next menu to appear)

"Excessive llDialog/llMap/llRequestPermissions calls from the SENDING OBJECT should set the script to non-running. "

— So all the existing menu systems will BREAK if someone presses buttons to quickly!

"No more than 10 LLNotifyBoxes in the stack at a time. "

— and what happens if your one of the people who own a busy shop and go afk for 30 minutes? Are we to just miss out on the notices about incomming sales? Or worse group notices that came in after the 10th sale.

"OK, LL. At least assign this fix within this week or I will cancel my account,"

— Seeya, bye bye. have a nice first life.

A whole second is nothing in the world of SL. It takes me longer than a second, on average, to operate a button on a HUD, whether it be one of your products or otherwise.

> So all the existing menu systems will BREAK if someone presses buttons too quickly!

If they're legitmately responding to a dialog, they'll be fine as they won't be firing off dialogs too fast. Say that, instead of a legitimate menu-using system, someone has it hooked up into a master-slave spamming system to bypass delays. The sim could detect this and disable it.

> and what happens if your one of the people who own a busy shop and go afk for 30 minutes? Are we to just miss out on the notices about incomming sales? Or worse group notices that came in after the 10th sale.

You have a sales log on both XStreet, Second Life, FlexMarket, and HippoVend that is not delivered over llDialog. If one were smart, they would disable the in-world notifications when their shop is busy enough so they aren't utterly spammed to death with sales notifications. I run a shop too, and the effects of this don't concern me since I have the ability to get a summary of sales online. You can easily factor in a system that notifies you over IM or email when you get a sale.

> See ya, etc

I will.

Obviously any changes need to exclude the owner. Darling is actually right on this one, many of my objects will give a menu to the owner when touched, or when the command "menu" is recieved, and when the owner pushed a button on the dialog, it will often bring up a submenu. Limiting this to 1 second would create a serious problem. One extreme example would be where we have menus to adjust velocity, rez offsets, fuse times, and other integer and float settings that can have a variety of possible values within a broad range. We usually have several buttons on a menu that can increase or decrease the value by a few increments. When the value is adjusted, that menu then pops up again, allowing the user to keep pressing +1 (or whatever the appropriate increment is for that setting) until the desired value is reached. This would result in a decent number of llDialog() menus being sent over a short period of time. A 1 second wait would be extremely unwieldy, and if this number of calls caused the script to be set to not-running, it would break the product.

One thing that could be done server-side is to prevent llDialog() and llRequestPermissions() from running in loops. There is really no good reason for them to work in loops anyways. llRequestPermissions() especially would make no sense in a loop.

The ability to mute llDialog() and llRequestPermissions() would be great. Unfortunately, it may not be possible at the moment. Even LordGregGreg Back's PAR plugin that offers protection against some forms of spam does not seem to work against llDialog() (I have tested this myself, although I was the owner of the object, maybe it only stops dialogs from others). However, since the dialog and permissions menus seem to be able to display the name of the object and the object's owner, clearly that information is being sent somehow. It would be nice if muting the object or the owner would prevent these requests from happening.

One other stopgap measure might be that if permissions requests are denied, or are denied multiple times, that should at least create some delay before more requests can be sent to that individual. Also, it would be interesting if the client could be configured to simply ignore all permissions requests that are not implicit...in other words, those that would not be granted by sitting on or wearing an object. Or they could even be set to ignore anything from the non-owner. This would obviously not be a default setting, but as a debug setting of some sort, it could offer temporary relief to someone who is being spammed, during which time they could AR the asshole who is doing the spamming.

One other useful feature might be if the location of the object that is sending the dialog or permissions request were included in the blue popup. This would make it easier to track down the offending object.

Also, instead of limiting the LLNotifyBoxes stack to 10, perhaps having a debug setting so that the user could decide what level to limit the stack? That way Fred could limit his stack to 10 and be happy as a clam, and Darling could set her stack to unlimited (or to some larger number), and not worry about missing noticed.

NOTICE ON VIEWER :-
I understand the reason notices crash the client is because the client renders all the notices. So it is costing CPU time to render notices that are behind the current notice. I understand this is already being fixed so that only the current notice will be rendered witht he other ones cued up to be displayed. This wont stop the spam, but will stop the crash. And i feel it is a better option for the viewer than a fixed number of notices, even if the number is user defined.

There is a major project going on to re-do the notice system and the render system. I nderstand the RC is starting to show some of these changes. (and some pretty god awful bugs in the current release too

LOOPS ARE FAIL:-
I think you will find there are a fair number of product sthat will LOOP around a permssions request, perhaps with a sleep and a timeout when requesting permissions from owners in situations where exiting the event are not desirable.
Also I remember the lindens saying they cant detect loops in code when you made a similar suggestion about another looped weapon.
Finally using the timer even will give much the same function as a loop and wont be detectable by somthing looking for loops inside the events/functions.

SOLUTION :-
1) Owners have no restictions on what their own objects can send them, thus avoiding any broken content that is trying to legitimatly communicate with the owner.
2) Toss in a throttle of how many notices can be sent to someone within a time period, and reset the timer if that person responds to the notice with anything except for ignore. Thus avoiding any menu system that operates for non-owners from breaking when someone is legitimatly using it.
3) Once a throttle is in effect it will not deactivate after user responce, it will require the object to stop sending dialogs until the throttle resets.

These options will work because a spammer will have blown the throttle limit before the victim has pressed any buttons in responce. So it will not matter if they pressed OK, YES, Whatever, or even IGNORE because the throttle will already be in effect.

The only possible spam method left will be to send them really slowly below the throttle to bother the person, which is easy enough to mute without any drama. Especialy if the throttle is somthing like 1 dialog every 10 seconds when dealing with a dialog that is NOT responded to or from your own objects.

Darling.

Responding to llDialog is not limited to 20 metres. When you click a button on the dialog, it causes you to say a message on the appropriate channel with your message origin point being at the exact place where the sending object was. In the case of cross-sim dialogs, clicking a button only works properly if you've been in that sim you recieved it from without disconnecting from it since.

Therefore since it can still be useful at range, llDialog should not be throttled based on distance.

The best way to deal with this (along with fixing the frame rate issue) is to discard llDialog popups if the object owner is muted, to add a mute button that mutes the object owner and discards all their dialogs, and to add an "ignore all" button that instantly discards all open dialogs.

This would not effectively solve the issue. At the end of the day greifers can bomb a client with hundreds per second using delay by pass scripts and the like. By the time you have much time to react your client is on its knees. Rate limiting either client or server side to something like 25 or even 50 a minute and discarding the rest would be a much better approach since your solution allows the client to fall to its knees which can happen with the current setup.

I'm on a Quad Core with a decent graphics card and my SL will almost totally freeze. For those who don't have a higher end system this solution would be pretty pointless to and fight the 0.00001 fps and mute / "ignore all"

That will not be the case for much longer. the memory limits and cpu limits that LL are rolling out to the grid this year will break the hacks used to bypass the pause built into these functions.

The biggest threat at the moment is custom viewer programs that can send thousands of requests for friendship or teleport requests at the press of a button. No limitations on these at all because the region trusts the viewer and assumes it is human controlled and therefore sending requests slow.

Again the work the lindens are doing on the graphics engine so notices are not rendered unless they are on the top will help here. and one would hope a mute will clear all notices in the que too.

There is no need to further cripply the LSL language. LL are finally addressing the reason these attacks work instead of trying to block them from being launched.

Your last name ain't Linden - care to offer a citation for that factoid and how it's going to fix this problem? O.o

..The biggest threat at the moment is custom viewer programs that can send thousands of requests for friendship or teleport requests at the press of a button. No limitations on these at all because the region trusts the viewer and assumes it is human controlled and therefore sending requests slow...

Why don't you put in a JIRA on it with a repro, but calling attention to another problem doesn't resolve this problem.

...There is no need to further cripply the LSL language...

Nobody wants the LSL language 'cripply' O.o How is LSL going to be 'cripply' if they prevent dialog spamming?

Many SEC JIRAs have already been lodged about the custom viewers. I dont use them myself as they are a security risk. However I have been on the receiving end of a demonstration.

Adding extra throttles to LSL functions when the problem is with the viewer forcing someone to respond to every single dialog is a bad fix.

It is better to have a MUTE that deletes all pending dialog requests from the que, so you only need to answer MUTE once, even if there are thousands of dialogs.

The other part is not to rending one dialog on top of another. This is why the frame rate drops when they type of weapon is used. Each dialog is renered like a 3d object placed over another dialog, and so on. I understand this is being fixed by queing the dialogs instead of rending them all at once.

Somthing else that might be worth considering is clearing the que of all identical requests when one is answered. so if an object sends two requests, answering one will clear the second. This is usefull because there is no feedback when someone preses IGNORE, so the script often sends another dialog thinking the first was lost. I am talking legitimate objects here, like vending machines that might re-send permission debit every 30 seconds until it gets an answer.

Darling.

—

The above is not quite correct. While shared memory pools for parcels and avatars are going to be implemented, they will need to be high enough (in order not to break normal content) for an user to use dozens of tiny scripts consisting of only a few lines of spamming functionality.

I don't see any custom viewer spammers as the biggest threat. Compared to normal dialog spammers their usage lies in the one-digit percentage range, if that, and when used it's almost a guaranteed suspension. (As always, it depends on the victim filing an AR. But that's always the case.)

—
Fred does have a good point that llDialog() should only operate if the object is in the same sim. Hell, the button push on llDialog() will only actually be useful within 20m anyways.
—

This, interestingly, is not true. The dialog buttons seem to work all across the sim now, last I tested. But yes, only allowing it in the same sim makes sense, logically. However I think that already is the case?

Personally I like the idea of one's own objects not being limited/blocked in any way when it comes to sending dialogs to their owner, and rate-limiting dialogs/urls/permission requests on a per-sending-object's-owner basis otherwise, while also making sure that all the above also can be muted effectively permanently.

in llviewermessage.cpp – approx line 5030

void process_script_dialog(LLMessageSystem* msg, void**)
{
S32 i;

ScriptDialogInfo* info = new ScriptDialogInfo;
..........
for (i = 0; i < button_count; i++)

// twisted ignore dialogs from others when busy
// get requestor name
std::string fullname = first_name + " " + last_name;
// if we are busy
if(gAgent.getBusy())
{
// get our name
std::string name_str;
gAgent.getName(name_str);
// if it doesn't belong to me, then delete the structure and return
if(fullname != name_str) { delete info; return; }
}

LLStringUtil::format_map_t args;
args["[TITLE]"] = title;
.........
}

Also it's not a duplicate of the server issue, because as I said fixing the server issue won't fix the client's inability to handle many dialogs at once.

Delaying the function would also be bad to many scripts that use this for adjustment or other uses that require reopening the dialog right after a selection.

I am not sure Iposted this here yet, but the changes in the viewer that we will see very soon will solve the problem.

What happens when you have thousands of dialog boxes on yoru screen at once is that the viewer is rendering them as if they are 3d objects piled up on top of each other. So the more dialogs you have open, the more memory and cpu it takes to render them. even if you only see the top one, the others are being rendered behind it!

I understand LL are working on the viewer to only render the one on top, and to fix a lot of other rending issues too. There is another JIRA about it where the lindens state what they are doing, but i didnt set a watch on it, so i cant give you a link.

Soft Linden is correct, this issue's is a duplicate that can be fixed by better throttles, and by the soon to be released optinisation of the viewers rendering system.

Soft Linden resolved this issue as a duplicate of the server issue. Fixing the server issue will not resolve the client side issue. The client would still be possible to over load either by attacking while the person is idle so after time the user will come back to an unusable client, or attacking alongside many other attackers.

This issue needs to be reopened until they solve that or unless there is another issue about this that was created BEFORE this one. The current issue that is set as "duplicates" is incorrect. This is not a duplicate of the server issue.

As I said before. the two sepperate issues are being fixed in other jira's. One for viewer and one for server, so migrate to them because this one is closed in favor of them.

You should be happy Soft Linden has taken an interest and is working on a fix, instead of complaining.

Either way, I talked to Soft about this in world recently and since it is apparently fixed in 1.23 code now I'm not as worried anymore.

---- he is not stupid ya know

"Fixing the server issue will not resolve the client side issue. The client would still be possible to over load either by attacking while the person is idle so after time the user will come back to an unusable client, or attacking alongside many other attackers."

Client Side overload is a bug in the rendering engine. Go download the new viewer. I suspect you will find this problem greatly reduced if not removed.

I am watching 6 different jiras that are all related to this issue. Soft closed them all in favor of the two that he is fixing. One for throttles, and one for viewer rendering.

Soft is solving this problem, so please stop arguing with him!

... and stop arguing with me about weather your arguing with him.

llDialog still works unlimitted (altho my client isnt crashing but a restart would be better instead of clicking all the dialogs away)
I'm not sure if the 1 second delay was always there, but that could be circumvented (for griefing) by using multiple scripts.

llTextBox (whatever its function would be) has no limit, no throttle and also no delay of 1 second. By the time llDialog can
send 40 dialogs, llTextBox has sent already 1000 requests.

Tested with 1.21, 1.22, 1.23 on server 1.26 and 1.27.