Firestorm: Allows blocked residents to spam via objects

[Paul Hexem]

The Firestorm devs apparently consider spam a trivial issue, so I gotta ask here;

Anyone know any workarounds for blocking someone that's creating a new object every week? Apparently, blocking an avatar doesn't stop their objects from sending you messages, at least in Firestorm.

You'd think the obvious fix would be an abuse report, but after three weeks that's not the case either.

[Jaylinbridges]

I think you need to find the object to block it.  The object owner won't work.  Good luck searching   Those are a pain

 

[Henri Beauchamp]

1. This is not specific to FS. The bug is due to LL's new HTTP capability code for offline messages retrieval.
2. Fixed in LL's viewer MAINT-U by this commit.
3. Until this commit makes its way to all viewers and as a workaround, you may disable that capability in them, if they offer such an option, to fall back to the non-affected legacy UDP retrieval method.
4. Fix already backported to the Cool VL Viewer v1.30.2.18.
5. LL won't consider objects IMs ads as a violation of the TOS, since you can (normally) block those IMs yourself when they bother you. So, your abuse reports would be considered disproportionate and would be ignored.

Edited June 26, 2023 by Henri Beauchamp

[Paul Hexem]

3 hours ago, Henri Beauchamp said:

1. This is not specific to FS. The bug is due to LL's new HTTP capability code for offline messages retrieval.
2. Fixed in LL's viewer MAINT-U by this commit.
3. Until this commit makes its way to all viewers and as a workaround, you may disable that capability in them, if they offer such an option, to fall back to the non-affected legacy UDP retrieval method.
4. Fix already backported to the Cool VL Viewer v1.30.2.18.
5. LL won't consider objects IMs ads as a violation of the TOS, since you can (normally) block those IMs yourself when they bother you. So, your abuse reports would be considered disproportionate and would be ignored.

Help me understand how offline retrieval issues would allow blocked residents to spam you while you're online?

[Henri Beauchamp]

1 hour ago, Paul Hexem said:

Help me understand how offline retrieval issues would allow blocked residents to spam you while you're online

It won't. And I just tested FS, blocking my main avatar from an alt avatar account, and verifying a scripted object pertaining to my main (blocked) avatar IMing to that alt avatar could not get through the block: it does work as expected.

Maybe you did not properly block the avatar of the IMing object, or they used an alt account (commonly seen with griefers' accounts)...

Edited June 26, 2023 by Henri Beauchamp

[Paul Hexem]

25 minutes ago, Henri Beauchamp said:

It won't. And I just tested FS, blocking my main avatar from an alt avatar account, and verifying a scripted object pertaining to my main (blocked) avatar IMing to that alt avatar could not get through the block: it does work as expected.

Maybe you did not properly block the avatar of the IMing object, or they used an alt account (commonly seen with griefers' accounts)...

Neither is the case. I can click on the object name when it sends me a message, go to the region it's in, look at it, and it shows me the owner is blocked. It's a store so it's not a run of the mill griefer creating new accounts.

[Theresa Tennyson]

1 hour ago, Paul Hexem said:

Neither is the case. I can click on the object name when it sends me a message, go to the region it's in, look at it, and it shows me the owner is blocked. It's a store so it's not a run of the mill griefer creating new accounts.

It's probably using a commercial mailer service. Some stores add you to their notification lists even though you've never had contact with that store. Blocking the owner won't stop the mailings because technically they're sent by someone else. The stores I'm familiar with that are notorious for doing this have been using "Sastech", which allows you to unsubscribe without going through the store but it's a bit of a pain because you have to do it in-world. Here's the location:

http://maps.secondlife.com/secondlife/Wasp/196/199/992

Note: Sastech themselves don't seem to be particularly shady - it's the equivalent of your cell-phone provider sending you "extended warranty" calls.

[Paul Hexem]

10 minutes ago, Theresa Tennyson said:

It's probably using a commercial mailer service. Some stores add you to their notification lists even though you've never had contact with that store. Blocking the owner won't stop the mailings because technically they're sent by someone else

Yeah, I've seen 'em.

The problem is, I'm trying to block the owner of the object sending the message (which is also the store owner) and it shows they're already blocked.

[Wulfie Reanimator]

I've read both of your threads and I understand what you're referring to, but I'm not able to reproduce it.

If I block an avatar, llInstantMessage from any of that avatar's objects will not arrive. (It's the only grid-wide message function we have that can target avatars.) Maybe there are more special conditions (a bug) we don't know about that allow the messages to pass through a block.

[Paul Hexem]

51 minutes ago, Wulfie Reanimator said:

Maybe there are more special conditions (a bug) we don't know about that allow the messages to pass through a block.

That's almost certainly the case here, yeah. What's driving me nuts is that I can't get anybody to do anything about it for going on a month now. Governance won't clean the object up, @Maestro Linden via the Jira says it's Firestorm's fault (which I'm tempted to believe as he's generally pretty reliable), and nobody on the Firestorm Jira will acknowledge it except to mark it as "trivial".

I'm trying various different viewers to try to block it and the creator with them, but they're showing everything as blocked already.

I could stop using Firestorm if that's my only option, sure. But even if that solves the problem for me (which it kind of doesn't, there are actually features in Firestorm I do like) I still feel obligated to let people know about the bug and about the lack of a response to it.

Edited June 26, 2023 by Paul Hexem

[Quistess Alpha]

Interesting. I just tested it with 2 simultaneously logged in accounts, one on Firestorm (6.6.3) and one on Kokua (6.5.4):

Firestorm receives object IMs from objects owned by blocked persons (the behavior Paul is describing as bad), whereas Kokua seems to receive them (the nearby chat tab flashes orange) but does not display them to the user.

[Paul Hexem]

11 minutes ago, Quistess Alpha said:

Firestorm receives object IMs from objects owned by blocked persons (the behavior Paul is describing as bad)

Oh, so the viewer is allowing spam from blocked residents! That's pretty huge. The real question is why it hasn't shown up for more people. Or why nobody else has said anything.

Could you do me a favor and comment that you were also able to replicate it?

[FIRE-33016] Blocklist not working - Firestorm Bug Tracker (firestormviewer.org)

Edited June 26, 2023 by Paul Hexem

[Quistess Alpha]

17 minutes ago, Paul Hexem said:

Could you do me a favor and comment that you were also able to replicate it?

I'm too lazy to create an account for a firestorm specific jira when I rarely use firestorm, sorry.

[Wulfie Reanimator]

1 hour ago, Quistess Alpha said:

I'm too lazy to create an account for a firestorm specific jira when I rarely use firestorm, sorry.

Could you explain it here? Which sims were the avatars/objects on?

[Quistess Alpha]

6 minutes ago, Wulfie Reanimator said:

Could you explain it here? Which sims were the avatars/objects on?

I was on my parcel at Baylor's Haunt*, I had myself and an alt each create a box with a basic llInstantMessage("UUID of other avatar","spam"); script. I suppose the other item of note is that I'm friends with my alt, but behavior is as above, when mutually blocked (each user blocks the other but not their new object), firestorm (6.6.3) gets messages from the object (which is not blocked but the owner is) whereas kokua (6.5.4) does not.

http://maps.secondlife.com/secondlife/Baylors Haunt/193/119/2036 (where I am right now, working on something else, building is open if you're nice and don't bother me. . .)

Edited June 26, 2023 by Quistess Alpha

[Beq Janus]

I cannot reproduce this problem (Using the current release Firestorm 6.6.8, I have no recollection of a prior issue that would have affected 6.6.3 though TBH ) 

Here is a 90-second video showing an alt clicking coloured spam cubes. https://i.gyazo.com/0a6927db782c04c2543c926e4511631b.mp4 (you might want to click off the audio, which I recorded by mistake, just lots of background)

Each cube has the same basic script in it. 

As we see, clicking on each cube in turn yields a "spam" message.

The centre cube is then blocked. We see it appear in the block list.

The centre cube no longer posts "spam", it has been blocked.

both the others continue as expected.

I then block the owner (me). We see that appear in the block list and further evidenced by the attractive grey monstrosity that I become. 

clicks now fail, no more spam and all is right with the world

I unblock, and things return as expected too.

(I'll add this to the Jira, at the moment, I have nothing more to go on, it seems fine, suggesting we're missing some subtle detail).

If you can add captures (to the JIRA) that show your  block list and the object and the owner in question on it then that might yield more info, perhaps (worth a look)

Note: I have also relogged, and confirmed that things remain blocked after relog.

 

 

[Paul Hexem]

42 minutes ago, Beq Janus said:

I cannot reproduce this problem (Using the current release Firestorm 6.6.8, I have no recollection of a prior issue that would have affected 6.6.3 though TBH ) 

Here is a 90-second video showing an alt clicking coloured spam cubes. https://i.gyazo.com/0a6927db782c04c2543c926e4511631b.mp4 (you might want to click off the audio, which I recorded by mistake, just lots of background)

Each cube has the same basic script in it. 

As we see, clicking on each cube in turn yields a "spam" message.

The centre cube is then blocked. We see it appear in the block list.

The centre cube no longer posts "spam", it has been blocked.

both the others continue as expected.

I then block the owner (me). We see that appear in the block list and further evidenced by the attractive grey monstrosity that I become. 

clicks now fail, no more spam and all is right with the world

I unblock, and things return as expected too.

(I'll add this to the Jira, at the moment, I have nothing more to go on, it seems fine, suggesting we're missing some subtle detail).

If you can add captures (to the JIRA) that show your  block list and the object and the owner in question on it then that might yield more info, perhaps (worth a look)

Note: I have also relogged, and confirmed that things remain blocked after relog.

 

 

I'll update the JIRA with a screenshot of the blocked resident and objects. Thanks for looking into it.

It actually does look like Governance is returning it and the person is just putting out a new one each week, which gives me a new UUID to block, even while the owner is still blocked.

[Beq Janus]

47 minutes ago, Paul Hexem said:

I'll update the JIRA with a screenshot of the blocked resident and objects. Thanks for looking into it.

It actually does look like Governance is returning it and the person is just putting out a new one each week, which gives me a new UUID to block, even while the owner is still blocked.

Thanks,  it still begs the question of how that evades the user block; we're missing something here, just no idea what yet 🙂

 

[SilenzZzz Mistwalker]

i have ran into this from a blogger that i never remember subscribing to .. blocked their avie after numerous notecards and such sent to request removal as their messages stated... and each time it was a new prim that was rezzed out sending the message... after several months it stopped finally tho

[Beq Janus]

If anyone has information that is anything other than anecdotal please add the logs and any step-by-steps to the JIRA, it may be the hint we need to determine what this missing detail is. 

[Quistess Alpha]

9 hours ago, Beq Janus said:

If anyone has information that is anything other than anecdotal please add the logs and any step-by-steps to the JIRA, it may be the hint we need to determine what this missing detail is. 

Video: -redacted-

Log: -redacted- (Very big! I turned debugging on, maybe TMI?)

Script in the mystery cube (not that it should matter too much):

default
{
    state_entry()
    {
        llInstantMessage("-redacted uuid-","Spam");
    }

    touch_start(integer total_number)
    {
        llInstantMessage("-redacted uuid-","Spam");
    }
}

 

Edited June 27, 2023 by Quistess Alpha

[Beq Janus]

5 hours ago, Quistess Alpha said:

Video: https://files.catbox.moe/z5vq6k.mkv

Log: https://files.catbox.moe/a8mf5n.txt (Very big! I turned debugging on, maybe TMI?)

Script in the mystery cube (no that it should matter too much):

default
{
    state_entry()
    {
        llInstantMessage("68686474-391b-44ea-b68f-9b88a566af9f","Spam");
    }

    touch_start(integer total_number)
    {
        llInstantMessage("68686474-391b-44ea-b68f-9b88a566af9f","Spam");
    }
}

 

Ty,

my test script is essentially the same (I didn't bother with the state_entry completeness). 

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llInstantMessage("c7d8bc3e-3b7d-45a8-94f6-080913a47999", "spam!");
    }
}

 

The only thing I see that strikes me as odd is that you don't get any update from the remote server when the viewer requests the mute list. It seems to only use the cached version. 

I need to do some digging to see if that is "expected".

In the meantime if you have the opportunity to test the same cube setup on a completely different region that'll help remove that variable too.
 

[Henri Beauchamp]

15 minutes ago, Beq Janus said:

The only thing I see that strikes me as odd is that you don't get any update from the remote server when the viewer requests the mute list. It seems to only use the cached version. 

The mute list is only actually received on first request, at login. The rest of the time, the viewer uses its local mute list. Note that the server got no notion whatsoever about what a mute/block is (it's entirely a viewer-side feature) and only stores the mute list as a convenience (so that for each avatar, the same, up to date list is used when you switch to another computer or another viewer).

[Quistess Alpha]

19 minutes ago, Beq Janus said:

In the meantime if you have the opportunity to test the same cube setup on a completely different region that'll help remove that variable too.

I had a spare minute. but was a bit unscientific and changed the expiramental procedure slightly: with the blocked avatar wearing the cube as an attachment and teleporting both sender and receiver to arbitrary regions, no change: ~I always seem to receive messages from objects owned by blocked persons (Also forgot to mention I upgraded to firestorm 6.6.8 before the last test.)

[Beq Janus]

1 hour ago, Henri Beauchamp said:

The mute list is only actually received on first request, at login. The rest of the time, the viewer uses its local mute list. Note that the server got no notion whatsoever about what a mute/block is (it's entirely a viewer-side feature) and only stores the mute list as a convenience (so that for each avatar, the same, up to date list is used when you switch to another computer or another viewer).

Thanks  Henri,

Yeah, I was expecting to see at least a processMuteListUpdate() for the initial response though. I've not had a chance to walk it through and see where it goes. It might just write to file then load the cache, which would explain what I see, or don't see.