|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 09/Aug/07 09:11 AM
Currently the only way to get this kind of information is to enable the "Send offline IMs to Email" option and then log off and let LL spam your email box.
Right, thanks! In the particular attack that we were seeing that didn't seem to work, presumably because the malicious object was sending its llInstantMessage()s only to people that were logged on (either because it was finding them via llSensor, or it was checking for logged-on-ness via llRequestAgentData).
Changed the title, and set this to a bug, not a feature. I consider it a bug that such messages can be untraceable.
Ferox just got attacked by a spammer. Places an object, maybe several, in neighboring parcels, whouting spam all across the sim. Being in neighboring parcels, disabling scripts didn't help, nor could the objects be returned. We eventually found them, and banned the owner. After being spammed foir ~20 minutes
We need a way to instantly find the owner of a spamming object. Right clicking the object's name in chat history should do this. I've got code in my viewer for this. Downloadable at http://sl.daleglass.net
Currently not yet at the point where a patch can be submitted, but should work, As Lindens want to get less involved rather than more, and creating new alts costs nothing, being able to AR the offender is of limited utility. A better solution is to put grey-goo-style fences on messages of all types, including friend requests, inventory transfers, IMs, etc. Make the limits apply per account rather than per object. Increase or remove the limit for objects on land owned by the object's owner.
Unfortunately an accounts based system would quite easily be able to hit limits. A thousand IMs a day limit? Anyone with a couple of dozen scripted vendors could hit that. Ten thousand? Popular products update servers and things such as Tringo boards could hit that in twenty four hours.
Being able to click on the name for details would be an ideal solution. It would be a sensible interface feature and make abuse easily traceable.
Overall limits are a very bad, unworkeable idea. For any throttles, the best way is to cut use if it's used abusively. IE. The grey goo fence is triggered if you rez more than x objects within Y time period. The exact numbers are secret and ever changing. But they are such that any reasonable use will not be bothered. But mass rezzing, which is almost always a sign of griefing, is throttled. Going over the limit cuts rezzing ability, until it stops trying to rez.
REgardless, though. I don't care about ARing at all. I just want the tools to protect ourselves. IM spam goes away easily if you mute the offender. Thsi issue is simply asking for a way to identify who that is, so they can be muted. Currently, that's very difficult to do. If you have that sort of Abuse, do the report with a Linden name as the abuser and give the location, in the report give lots of details and state that it is done under Linden Name as it is an untracable object.
Closing issue. This issue isn't fixed and should not be closed as such.
EDIT For further clarification. This item has a Linden Lab issue ID. This means it is checked in to their internal JIRA and is in queue to be worked on. Meghan, this is a highly serious issue, and a great security flaw in the client. Requiring linden intervention for each and every case is completely unacceptable and unscaleable. In addition, as Thraxis pointed out, this issue has already been imported, which proves linden lab considers it a problem in need of fixing. Please do not close issues without properly investigating circumstances.
It's been over 9 MONTHS since my last comment on this issue, and it's still present.
Anyone who likes, can spam a target untraceably, to the point where their client is overloaded with IMs and crashes. The client provides no information to the user about the source of such an attack. Dale Glass was apparently working on a patch for this, but it's pretty clear by now that it's not coming. His client hasn't been updated since 1.18 . We need a linden to step in and sort this out. Dale's client is here, by the way: http://sl.daleglass.net/
It provides the perfect solution, via a simple checkbox in the chat history, which adds the name and location of any object sending an instant message, or speaking in chat. unfortunately, this client is extremely outdated in many other ways. I'm not sure if it can even login anymore. this needs to be fixed. serious security hole. as always, it's open for over a year, new features and arbitrary changes of colors are much more important than this. also, can dale submit his patch to LL?
Note that just name and location aren't all that useful, since an object can change its name and location quickly at any time. It should also be possible to get the name of the OWNER of the object (for ARing purposes), and (ideally) to be able to mute it as well (and to be able to mute all objects with that same owner).
I'm glad to see it has an Issue ID; I hope the issue will get some attention... My bad, I meant that it gives the name of the owner. Of course the object name is almost entirely useless, unless you're trying to find it with a sensor.
In Local Chat, clicking the << to show a list of active participants will display the object for about 15 seconds, selecting the object and then clicking on the Profile button at the bottom will display the owner's profile.
Are you sure, Harleen? In what viewer version? I just tested in the current release viewer, and while objects that chat via llSay() show up in the Active Participants list, objects that llInstantMessage() do not.
It's relatively easy to catch objects that spam via chat, because scripts can listen. It's objects spamming via llInstantMessage() that this JIRA is about, and it doesn't look to me like those show up in Active Participants. It would be nice if they did! Maybe that would be a good fix for this JIRA even, or at least a start... hmm, I will test again, objects using llInstantMessage did at one time show up maybe they no longer do.
It would be a not bad solution, but not the best.
A way to find the coordinates of said spamming object would really be most preferable. Seems to still be a nuisance. Current location would be nice.
I am currently having someone harass both me and friends using object instant messages. I suspect it is a particular someone... but as I cannot trace... I cannot know. I sent AR'd that person anyhow, and made it clear that i could not be certain it was them.
In any case, this needs to be fixed!!! I like Dale Innis solution, and would love to see the main client patched with that code and the check box defaulted to on. Listening for objects on channel 0 has got to be laggy even for text. Moving this to the client would have to help servers I made this a bit ago: My partner, friends and I are also being harassed by a scripted object sending anonymous instant messages. It must be something like the Secret MSGR HUD sold on the Linden Labs-owned Xstreetsl!
I abuse report the person who I suspect is sending the messages, but I cannot know for certain if it is them or an alt. This needs to be fixed ASAP. Dar Innis: This is about llInstantMessage(), not llSay() :>
As Harleen described, Objects that use llSay() gets shown in the local chat tab in the participants list and can be selected,/inspected/owner profile'd. As for llinstantMessage(), sadly enough the internal message sent to the viewer only serves the object name and object key. I have a switch in my client that allows the object's key to be shown in llInstantMessages, but one still has to go through the hoops of running an LSL script that uses the dataserver to determine the owner. All in all, the IM system message needs an owner_id field. I have no idea how easily that can be added tho. I think that the owner UUID is included in the data for most packets, so I can't imagine that this would be a huge stretch to add it in. I can sort of understand not having the owner's name appear in chat for objects that use llSay(), simply because that could, for example, break the flow of an RP where an object is scripted to give out clues or something, and llSay() is easy enough to track.....but I cannot imagine any good reason why showing the owner's name in object IMs would be a problem. At the very least, the ability to click on the object name and get the owner's profile or something, similar to how clicking on a person's name in chat does it, would work just fine as well.
As long as muting the owner stops the spam, then the simplest method is quite clearly to allow residents to know the owner of an object IMing them. That way we don't have to deal with throttling and various Wile Coyote fixes that may or may not work and might break content. Allowing residents to see the owner seems to make perfect sense. In the meantime, is there any chance you could publish that patch, Chalice? Even being able to see the object's UUID would be useful to plug into llGetOwnerKey().....although as you rightly point out, it'd require a dataserver event if the owner wasn't in the sim to use llKey2Name(). Me and a bunch of people in the sim nuba got spammed in this way (starting with me, then it moved onto others). I filed an AR, but this is a serious problem. I could wake up the next morning and find all my IMs capped because of excessive spamming (among other who where there at the time).
I mention this because this was used as an attack on a group of people all at about the same time. This can be a powerful griefer tool to attack large groups of people with no warning, and no solution, and has been used in this way now. This is now possible in Second Life 1.23.0 (117724) Apr 17 2009 21:19:23 (Second Life Public Nightly). you click on the object in chat history and it pops up a floater with location SLURL and owner name.
Woot!! This should get rid of a whole category of automated griefing device...
Excellent. That solution sounds perfect. Between this and the other new features that I've been hearing, the 1.23 client should be a blast.
This is a wonderful new feature!
I hated that there was no way to A) find spamming objects. and B) tell Object IMs apart from normal object chat this takes care of both. I recall mentioning to CG, when we could first click on names in our chat history, that this would be useful for objects as well.
Shouldn't it be doable on client-side? That is how it works in 1.23, you click on the object name in chat history.
I'm happy that this is nearly fixed
 but since you have to click on the object's name, if the object's name is "" (a zero-length string), there's nothing to click on. Could the fix here be fixed so that (say) you can click on the colon following the name as well? That should pliug the zero-length-name hole... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Object Chat/IMs are untraceable
