Jump to content

AGENT_AUTOMATED is flawed and unreliable


Phil Deakins
 Share

You are about to reply to a thread that has been inactive for 235 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

That's it then. They are not going to tell us why it happens. Maestro Linden just posted this in my JIRA, and then closed it.

I can confirm that those agents are flagged as scripted agents internally, so the script is returning the correct result (as is the sim refusing entry).  If you have an account in this state, I recommend filing a support ticket requesting a fix for the agent.

They are not set as scripted agents in the way that we understand it. They must have been stealthily flagged as bots at some stage in their careers, without any communications with them.

It means that AGENT_AUTOMATED is intentionally modified by something else that has to do with bots. They won't tell us what it is, and I have to assume that LL flags agents as bots in another place and, once spotted and flagged, it is never changed. It means that requests for AGENT_AUTOMATED can't be relied upon to return the correct answer. Accounts that get manually flagged as bots, however long ago, are typecast for life as far as LL is concerned.

It was interesting finding the flag for Speedlight Gold accounts though, even though that flag can't be relied upon to be correct at the time :)

Edited by Phil Deakins
  • Like 3
Link to comment
Share on other sites

5 hours ago, Phil Deakins said:

They must have been stealthily flagged as bots at some stage in their careers, without any communications with them.

It means that AGENT_AUTOMATED is intentionally modified by something else that has to do with bots.

I don't know why you insist on this conclusion, even in your original Jira ticket. I mean, I kinda do, since were also fixating on Speedlight Gold. This (the quote) just seems very unlikely considering everything that has been said in this thread and by Lindens/Jira/support.

What if it's literally just a bug in their backend systems (instead of anything LSL-related or flag fudging/re-use)? What if the account page is displaying the wrong value? Have you tried to change your scripted agent status yourself?

I see a lot of very nitty-gritty technical speculation, but nothing that hints at the problem being... even in that direction.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

4 hours ago, Wulfie Reanimator said:

I don't know why you insist on this conclusion, even in your original Jira ticket. I mean, I kinda do, since were also fixating on Speedlight Gold. This (the quote) just seems very unlikely considering everything that has been said in this thread and by Lindens/Jira/support.

It could be coincidence that the 2 Speedlight accounts that were Gold for short time, are the same 2 accounts that have bit 16 set, while none of the other account have it set. I'm not insisting that bit 16 is the flag for it, but I do think that it's a very reasonable conclusion to make. Nothing has been said in this thread or by LL's jira/support about bit 16, except by me.
 

4 hours ago, Wulfie Reanimator said:

What if it's literally just a bug in their backend systems (instead of anything LSL-related or flag fudging/re-use)? What if the account page is displaying the wrong value? Have you tried to change your scripted agent status yourself?

I see a lot of very nitty-gritty technical speculation, but nothing that hints at the problem being... even in that direction.

I no longer see it as being bug. I'm now convinced that it's behaving as intended. I simply don't believe that a bug causes the Scripted Agent account pages to display the wrong settings. Yes, as an experiment, I did set one of the accounts to scripted agent, and back again to human. It made no difference.

LL won't tell us the details of why it happens, but Maestro effectively told us why it does - the accounts are set as scripted agents internally. We know it has to be bot-related ("in that direction") because AGENT_AUTOMATED is only about scripted agents and, even though the user-facing accounts pages are set as human, they are returned as scripted agents; i.e. they are set as scripted agents internally, as Maestro said.

I see it like this. When a bot is recognised, probably from an AR, a Linden sets a flag for it in a programme form, but not in the user-facing account's page. And that's the flag that is checked along with the user-facing flag when AGENT_AUTOMATED is requested.

As far as I am concerned now, what appeared to be a bug is not a bug at all, and we've learned that there is an internal bot/no-bot setting as well as the user-facing setting. It does make sense from LL's point of view, because LL keeps scripted agents out of Bellisseria and other places. If that relied solely on the agent-automated flag, then users could set the accounts as human and the ban on bots wouldn't work. From that point of view, an internal flag is necessary.

We have the answer and I'm now satisfied :D

Edited by Phil Deakins
Link to comment
Share on other sites

39 minutes ago, Phil Deakins said:

It does make sense from LL's point of view, because LL keeps scripted agents out of Bellisseria and other places. If that relied solely on the agent-automated flag, then users could set the accounts as human and the ban on bots wouldn't work. From that point of view, an internal flag is necessary.

This convinces me. They need to prevent "known" bots from flipping the only record of their botness by merely using the Scripted Agent Status page. This way of doing it seems the path of least resistance: The value returned by llGetAgentStatus is a logical OR of those records, and known bots are allowed to operate the Scripted Agent Status page like some elevator "CLOSE DOOR" buttons connected to nothing beyond their own lights.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

30 minutes ago, Qie Niangao said:

They need to prevent "known" bots

Yes. But it puzzled me why only a few of mine are "known". From way back, yes, but there were plenty of others from way back, so why only them. For instance, after traffic bots were banned, and just for the enjoyment of doing it, I created more than one bots system that had around 8 bots wandering round the sim in unpredictable routes and they ran on my bot software. I don't remember all the accounts I used, but I do remember some of them and they aren't 'false positives'. I didn't religiously set them as scripted agents because, although they were using bot software, I was actually in control at the keyboard. I can't fathom why the particular 'false positives' that I have came  to be flagged. ARs don't make sense in these cases.

Anyway, it is what it is, and I'm happy that we got to the bottom of it.

Edited by Phil Deakins
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Phil Deakins said:

Yes. But it puzzled me why only a few of mine are "known". From way back, yes, but there were plenty of others from way back, so why only them.

If LL published the "why", it may help Bot creators evade detection. We wouldn't want that, would we? (Recognizing that most users are not BOTH bot "bot creators" and "security creators" such as yourself). If I were LL, I certainly wouldn't tell why an avatar had been flagged as a Bot!

Edited by Love Zhaoying
BOTH!
  • Like 1
Link to comment
Share on other sites

16 minutes ago, Love Zhaoying said:

If LL published the "why", it may help Bot creators evade detection. We wouldn't want that, would we? (Recognizing that most users are not BOTH bot "bot creators" and "security creators" such as yourself). If I were LL, I certainly wouldn't tell why an avatar had been flagged as a Bot!

That might be why the accounts weren't informed, but I don't recall any of them being booted out and, if a logged-in agent is determined to be a bot, it would surely be booted out at the time.

It's all a very long time ago (I assume lol) and it really doesn't matter. It's just puzzling, that's all. I can have them 'fixed' if it matters but it doesn't, and it may be useful to have some that are "known" for tests in the future. You never know :)

Link to comment
Share on other sites

Actually this raises some serious concerns.

For example region owners have the option to disallow scripted agents in their region,and would reasonably assume the setting only bans those who have set their account to scripted agent.

This means region owners (myself included) could unwittingly be banning genuine guests. Said guests also have no way to know this is the reason they can't access the sim and assume they are banned by the sim owner manually.

In effect it becomes a 'shadow ban' where neither the region owner is aware they've banned a genuine user or the user is aware the region owner didn't specifically ban them from entering the sim. This is bad.

  • Like 1
Link to comment
Share on other sites

10 hours ago, Extrude Ragu said:

For example region owners have the option to disallow scripted agents in their region,and would reasonably assume the setting only bans those who have set their account to scripted agent.

That would be a very reasonable assumption. An example would be that, when I was testing the bot detector that I offered for free in GD, I was surprised to see that it had banned a stranger from my little 512. Since then, no other scripted agent has been on the parcel, so I've no idea if is was a potential customer that was booted from my store or not. I suspect it might have been, and, if it was, the person may not have known that he is internally registered as being operated by a programme. Wicked Leigh, my original alt, was never used as a bot and yet she was internally registered as one.

I finally went through all my accounts and I have 6 left that are internally registered, but not set as scripted agents. I didn't know about any of them. I did register some since the rules changed way back when, and I'm wondering if the internal flag is set when the user changes the status to scripted agent, and is left set that way when the user changes it back to human. I.e. once a bot, always a bot. It could account for why some of my accounts are internally set and not others, but I can't be sure about that.

The system isn't perfect but, on the whole, I think it works. A few people will have accounts that can't get into Bellisseria for instance but they can probably get it fixed with a support ticket.

Edited by Phil Deakins
Link to comment
Share on other sites

10 hours ago, Gabriele Graves said:

It seems likely from what I have read in these topics that the only additional people who would be getting banned would be accounts that LL have marked as bots and don't want to have that status removed for whatever reason.

They probably wouldn't know why they got banned from somewhere, and probably wouldn't even consider a support ticket. This is why the system isn't perfect. I remember discussions about whether or not we should set ourselves as scripted agents when we stay logged in for hours but are nowhere near the keyboard. Some people like to leave their avatars sleeping when they go to bed in RL. If they set them as scripted agents and it sets the internal flag, they won't know why things happen later in life. They'll think the owner of some bot-free place actually banned them.

Now that we know about the internal flag, we can suggest trying to TP into Bellisseria to those who post that they were banned from somewhere but don't know why.

Edited by Phil Deakins
Link to comment
Share on other sites

1 minute ago, Phil Deakins said:

They probably wouldn't know why they got banned from somewhere, and probably wouldn't even consider a support ticket. This is why the system isn't perfect.

I didn't mention support tickets though.  It's possible you misunderstood me.  When I said this:

"and don't want to have that status removed for whatever reason."

I meant LL under these circumstances doesn't want that status to be removed when a person "unregisters" themselves as a scripted agent.
I didn't mean that the banned person didn't want it removed.  I'm guessing that's where I caused confusion.

To me this means LL considers the account to still be a bot account and that requires special handling to change.
I'm OK with that personally as LL are in the best possible situation to assess that for us all based on the account history.
 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 minutes ago, Gabriele Graves said:

I meant LL under these circumstances doesn't want that status to be removed when a person "unregisters" themselves as a scripted agent.

Ah. Yes, I did misunderstand it. I thought you meant that the user didn't want it removed. My mistake.

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Phil Deakins said:

I did register some since the rules changed way back when, and I'm wondering if the internal flag is set when the user changes the status to scripted agent, and is left set that way when the user changes it back to human. I.e. once a bot, always a bot.

Maybe if the user set their scripted agent status "way back when", but done more recently that bit is quite reversible by the account itself, as my alt can attest.

For completeness, that alt had filed a support ticket, which is how he was reminded of his scripted agent status and hence why he was banned from all Bellisseria. So it's conceivable that the Support person flipped some special persistence bit, allowing that alt to clear his own scripted agent status, but I think the more parsimonious explanation is that the special "sticky" botness status is set Lindens, not a consequence of self-declared status.

  • Like 1
Link to comment
Share on other sites

I have written my own JIRA feature request.

https://jira.secondlife.com/browse/BUG-234331

I am proposing that the dialog message presented to users when they attempt to enter a region that does not allow scripted agents is changed to reflect the real reason they are unable to enter the region, to prevent hard feelings/misunderstandings amongst residents.

  • Like 2
Link to comment
Share on other sites

i think the cleanest solution would be that when Linden set on the Internal bit then this also sets on the AGENT_AUTOMATED bit, so that script returns are accurate

then on the account page, when both bits are set then the account AGENT_AUTOMATED bit is set and disabled, so it can't be flipped/unset by the account holder. To have it enabled the account holder has to file a support ticket

to save a lot of hassle I would make it so that this is a one-time ticket for the account

Edited by elleevelyn
~on
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 8/27/2023 at 2:16 PM, Extrude Ragu said:

I have written my own JIRA feature request.

https://jira.secondlife.com/browse/BUG-234331

I am proposing that the dialog message presented to users when they attempt to enter a region that does not allow scripted agents is changed to reflect the real reason they are unable to enter the region, to prevent hard feelings/misunderstandings amongst residents.

Unfortunately, the suggestion was declined. What was suggested made perfect sense, and is very desirable, so I can only assume that it was declined because they can't be bothered, or because the programming would have to include differentiating between Linden Homes and everywhere else, so that both the internal setting and the user setting are taken account of for Linden Homes, but only the user setting is taken account of for everywhere else.

It's a pity, but it is what it is, and it won't affect a massive number of people anyway.

Edited by Phil Deakins
Link to comment
Share on other sites

There's something "meta" about the way this jira gets a "CLOSED" Status which divulges the very least about Lab's intent for ever revisiting the request. There used to be more meaningful Statuses, but they quit using those in the public-facing jira, presumably because those Statuses might be contentious. Do you really want your jira relegated to "WON'T FINISH" Status? They used to be, but apparently those have all been swept into the CLOSED bucket, with some innocuous Resolution, at least as far as we jira-watchers can tell.

Thing is, that's likely why they weren't eager to complete this one: It reveals to the banned agent that they were banned for being a bot as well as why they're considered a bot, all information that might be more contentious than just saying they're banned and hoping they'll go quietly (as most probably will).

It's quite similar to the way Abuse Reports follow a process from which no information emerges: better to say nothing than to say something that might be contentious.

(In all these cases, though, it's indistinguishable whether the true razor is "contention avoidance" or "sloth".)

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

20 hours ago, Qie Niangao said:

There's something "meta" about the way this jira gets a "CLOSED" Status which divulges the very least about Lab's intent for ever revisiting the request. There used to be more meaningful Statuses, but they quit using those in the public-facing jira, presumably because those Statuses might be contentious. Do you really want your jira relegated to "WON'T FINISH" Status? They used to be, but apparently those have all been swept into the CLOSED bucket, with some innocuous Resolution, at least as far as we jira-watchers can tell.

That "don't hold your breath" response is indeed most frustrating.  But even when they DO accept one, the very next week two Lindens are talking about that very topic and getting the very same ideas handed to them in the meeting (in one case, an idea that had been specifically pointed out as sub-optimal in the *accepted* Jira), like it's an entirely new concept.  Gah.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

[3 weeks later...]

If the logical OR applied to two bit values is close to storage and thus far from the client, then perhaps much of the pipe between storage and client would have to be changed in order to inform the client which of the stored bit values resulted in the delivered result.

[Edited to mock the forum's psudo-necro narco.]

Edited by Ardy Lay
  • Thanks 1
Link to comment
Share on other sites

4 minutes ago, Ardy Lay said:

[3 weeks later...]

If the logical OR applied to two bit values is close to storage and thus far from the client, then perhaps much of the pipe between storage and client would have to be changed in order to inform the client which of the stored bit values resulted in the delivered result.

[Edited to mock the forum's psudo-necro narco.]

True! 

Link to comment
Share on other sites

On 8/24/2023 at 4:08 AM, Phil Deakins said:

It could be coincidence that the 2 Speedlight accounts that were Gold for short time, are the same 2 accounts that have bit 16 set, while none of the other account have it set. I'm not insisting that bit 16 is the flag for it, but I do think that it's a very reasonable conclusion to make. Nothing has been said in this thread or by LL's jira/support about bit 16, except by me.
 

I no longer see it as being bug. I'm now convinced that it's behaving as intended. I simply don't believe that a bug causes the Scripted Agent account pages to display the wrong settings. Yes, as an experiment, I did set one of the accounts to scripted agent, and back again to human. It made no difference.

LL won't tell us the details of why it happens, but Maestro effectively told us why it does - the accounts are set as scripted agents internally. We know it has to be bot-related ("in that direction") because AGENT_AUTOMATED is only about scripted agents and, even though the user-facing accounts pages are set as human, they are returned as scripted agents; i.e. they are set as scripted agents internally, as Maestro said.

I see it like this. When a bot is recognised, probably from an AR, a Linden sets a flag for it in a programme form, but not in the user-facing account's page. And that's the flag that is checked along with the user-facing flag when AGENT_AUTOMATED is requested.

As far as I am concerned now, what appeared to be a bug is not a bug at all, and we've learned that there is an internal bot/no-bot setting as well as the user-facing setting. It does make sense from LL's point of view, because LL keeps scripted agents out of Bellisseria and other places. If that relied solely on the agent-automated flag, then users could set the accounts as human and the ban on bots wouldn't work. From that point of view, an internal flag is necessary.

We have the answer and I'm now satisfied :D

IYKYK

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 235 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...