AGENT_AUTOMATED is flawed and unreliable

[Phil Deakins]

When AGENT_AUTOMATED was added to the llGetAgentInfo() function recently, I tried it and found that it always identifies one of my alts as a scripted agent even though it's set as being operated by a human. I identified what was wrong and I submitted a jira about it. The Linden who looked at the jira didn't understand it all. He told to me to go somewhere else which wasn't relevant, and he closed the jira. I didn't bother after that. I'd explained that the bit (of the flags) that's set when an account is a scripted agent, is already in use for something else, or it's being set unintentionally. The particular alt that was being misidentified was one that had to be paid for, back in the days when alts had to be paid for (2007), and I thought that maybe the bit was used concerning paid-for alts.

In the last few days I've written a scripted agent detector, and I've had it running on my parcel.

Today, I was writing something else, and I logged another alt in to test it with. That alt is also misidentified as a scripted agent, even though it isn't. It was created in 2010, so the flag bit wasn't used for paid-for alts. I registered and unregistered it as a scripted agent to see if it made any difference, but it's still being misidentified.

So AGENT_AUTOMATED is unreliable as a scripted agent detector.

[Love Zhaoying]

Is the misidentified Alt a Speedlight user? I recall a thread where Speedlight users were getting a flag bit set unexpectedly 

[Phil Deakins]

8 hours ago, Love Zhaoying said:

Is the misidentified Alt a Speedlight user? I recall a thread where Speedlight users were getting a flag bit set unexpectedly 

No, neither of them. I can't use SpeedLight for avatars that are being use for testing. They get thrown out of the parcel and it's too awkward popping them back with SpeedLight. I use SpeedLight in my normal computer - a Raspberry Pi - which doesn't even rez avatars with legs like a PC does lol.

The flag (bit) that's used for scripted agents is being, or has been, used for something else. LL got it wrong. If my memory is correct, it's bit 15. I've only logged in 4 or 5 avatars recently and 2 of them are misreported. It's not good.

Edited August 19, 2023 by Phil Deakins

[Love Zhaoying]

8 minutes ago, Phil Deakins said:

No, neither of them. I can't use SpeedLight for avatars that are being use for testing. They get thrown out of the parcel and it's too awkward popping them back with SpeedLight. I use SpeedLight in my normal computer - a Raspberry Pi - which doesn't even rez avatars with legs like a PC does lol.

The flag (bit) that's used for scripted agents is being, or has been, used for something else. LL got it wrong. If my memory is correct, it's bit 13. I've only logged in a few avatars recently and 2 of them are misreported. It's not good.

In case you misunderstood the intent of my question: did you EVER in the past (not part of this testing at all) use the misidentified avatar users for Speedlight? (That was the point of my question.)

Edited August 19, 2023 by Love Zhaoying

[Phil Deakins]

Just now, Love Zhaoying said:

In case you misunderstood the intent of my question: did you EVER use the misidentified avatar users for Speedlight?

Ah. I did misunderstand what you meant. It's a good thought.

One of them, yes. The other, no. However, there are 3 others that have been logged in with SpeedLight, one of which is me, and another is logged in with Speedlight right now. Neither gets misreported as scripted agents.

[Love Zhaoying]

8 minutes ago, Phil Deakins said:

Ah. I did misunderstand what you meant. It's a good thought.

One of them, yes. The other, no. However, there are 3 others that have been logged in with SpeedLight, one of which is me, and another is logged in with Speedlight right now. Neither gets misreported as scripted agents.

My memory is that Speedlight Gold members (whether paid or due to being Premium) are the users that had the extra bit set. So: "just in case", that's something to consider- whether the users/avatars being misidentified that had ever used Speedlight, may have been Premium and/or Speedlight Gold members. 

Edited August 19, 2023 by Love Zhaoying

[Phil Deakins]

58 minutes ago, Love Zhaoying said:

My memory is that Speedlight Gold members (whether paid or due to being Premium) are the users that had the extra bit set. So: "just in case", that's something to consider- whether the users/avatars being misidentified that had ever used Speedlight, may have been Premium and/or Speedlight Gold members. 

Speedlight changed recently, so anyone can stay logged in 24/7, and not just Gold accounts. When that started, 2 of my avatars were set as Gold, but they are back to free accounts now, even though they can stay in 24/7. I was one of the Gold accounts and I'm not returned as being a scripted agent. I may be mistaken but I think that maybe one of the false positives was also Gold for a while. The other false positive has never been logged in with Speedlight.

I'm relying on memory here, which can never be counted as totally reliable

ETA: I've submitted another jira because 2 false positives out of 5 or 6 avatars logged in is quite high, and some of the 5 or 6 were never checked for scripted agent status. I think I'll log in a load more and see what I can catch

Edited August 19, 2023 by Phil Deakins

[Phil Deakins]

I just had 16 avatars logged in, of which 4 were returned as scripted agents, but they were all set as being controlled by a human.

That's 25% false positives!

Speedlight doesn't come into it at all with these.

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

Edited August 19, 2023 by Phil Deakins

[Ron Khondji]

I just tried this (not very sophisticated) script:

default {
    state_entry () {
        llSetTimerEvent (30.0);
    }
    timer () {
        list agents = llGetAgentList (AGENT_LIST_REGION, []);
        integer num = llGetListLength (agents);
        while (--num > -1) {
            key id = llList2Key (agents, num);
            integer info = llGetAgentInfo (id);
            string t;
            if (info & AGENT_AUTOMATED) t = "BOT.";
            else t = "AVATAR.";
            llOwnerSay (llKey2Name (id) + ": " + t);
        }
    }
}

and it seems to work just fine.
Tested it in 'Boardroom' and 'Violet'.

[Phil Deakins]

The fact that it identifies scripted agents means nothing. What's being addressed here is that it identifies too many avatars as scripted agents that are not scripted agents.

It's been known to return at least one false positive since it was introduced. Yesterday or the day before, I discovered it returning another false positive, so today I checked 16 avatars, and 4 of them were returned as scripted agents, even though they are not registered as such. Saying that it works fine because it returns scripted agents is meaningless.

[Fenix Eldritch]

It may be prudent to also file a support ticket for your affected accounts. It's possible that maybe there is some breakdown in communication under the hood between your dashboard and wherever llGetAgentInfo reads its data to generate the bitfiled it returns.

[Phil Deakins]

It's not just some of my avatars. I'm not the only one who has seen it returning false positives. Rightly or wrongly, I actually believe that whoever did the programming for AGENT_AUTOMATED was unaware that the particular bit s/he used is or was allocated for something else. It may have been way in the past, and it's no longer used. If it was, it means that it's flawed and ought to get fixed. Maybe I could get my accounts fixed but the system would still return false positives for other people's accounts.

Edited August 19, 2023 by Phil Deakins

[Rider Linden]

@Phil Deakins,

Open a support ticket (Not a JIRA.)

They should be able to help you with the flag.

[Phil Deakins]

1 hour ago, Rider Linden said:

@Phil Deakins,

Open a support ticket (Not a JIRA.)

They should be able to help you with the flag.

I opened a support ticket yesterday for one of the 5 accounts that are wrongly returned as scripted agents, hoping to find out what the cause is. I'm not bothered about getting an agent's flag changed, which I think is what a support ticked would be for. I'm only interested in reporting a bug. It is troublesome for SL that AGENT_AUTOMATED returns false positives, and must be regarded as unreliable.

If it's a bug, then surely a JIRA is the way to go. But if it behaves as intended, then I think we need to know why it does it. I've developed a very rough idea of what might possibly be causing it, but I do think we need to know.

ETA:
Incidentally, there isn't a category that's even remotely suitable for a support ticked so I has to choose one that has nothing whatsoever to do with it. Maybe it won't even be accepted.

Edited August 21, 2023 by Phil Deakins

[Fionalein]

This raises the question: "Am I a bot?"

[Phil Deakins]

3 minutes ago, Fionalein said:

This raises the question: "Am I a bot?"

We have cat bots now? 

[bigmoe Whitfield]

On 8/21/2023 at 3:41 PM, Phil Deakins said:

We have cat bots now? 

meow

[Phil Deakins]

The support ticked I opened achieved what I expected. The account was fixed so that it no longer comes back as a scripted agent, which was not the purpose of it. But I have another 4 accounts that are wrongly returned as scripted agents so it's ok. My JIRA has received  a bit of activity (Whirly is on it ), but nothing to indicate what the cause of the false positives is. This is my current theory...

An account's flags are stored in an integer - probably a 4-byte integer, which means there can be up 32 flags, one of which is the AGENT_AUTOMATED flag (bit 15).

When AGENT_AUTOMATED is requested for an account, the code does a logical AND on the flags. For AGENT_AUTOMATED, the flags  would be ANDed with 0x4000 to check bit 15. That's what requests for the Scripted Agent Page does, and it comes back correctly. But I'm leaning to the theory that it's not what an AGENT_AUTOMATED request does. I'm thinking that it does an AND on 2 flags - the AGENT_AUTOMATED flag and another. If the result > 0, 'scripted agent' is returned. So when the scripted agent flag is 0, and 'scripted agent' is returned, the other flag must be 1, and It's the other flag that causes the false positives.

Since it's been happening from when AGENT_AUTOMATED was introduced, I'm thinking that the other flag is current, and not an old forgotten one. It may have been implemented a long time ago, but it's still taken into account or it wouldn't be affecting AGENT_AUTOMATED requests. And since it's being included, I must be to do with bots. I won't expound on the pros and cons of my false positive accounts.

In a nutshell, my theory is that processing script requests for AGENT_AUTOMATED inspects 2 flags, one which is the agent_automated flag and the other is set when an account is thought to be a bot. If it's true, then everything is behaving as expected and there is no bug.

Edited August 23, 2023 by Phil Deakins

[Love Zhaoying]

13 minutes ago, Phil Deakins said:

Since it's been happening from when AGENT_AUTOMATED was introduced, I'm thinking that the other flag is current, and not an old forgotten one. It may have been implemented a long time ago, but it's still taken into account or it wouldn't be affecting AGENT_AUTOMATED requests. And since it's being included, I must be to do with bots. I won't expound on the pros and cons of my false positive accounts.

But, for them to "fix" your account, they must have changed your "flags" to so the "mystery flag" would not override your AGENT_AUTOMATED bit.

My own theory is similar to yours, except my opinion is that the "mystery flag" is static, rather than dynamic (some old use-case).  That is why "fixing" your account worked: they just "cleared" the "mystery flag" for your account.  Since that flag will no longer get set (by whatever deprecated use-case there was for the flag), your account should "stay fixed".  

On the other hand, if the "mystery flag" were still use, then the problem would not "stay fixed".

I'm sure you will misunderstand and challenge my opinion. LOL!

 

Edited August 23, 2023 by Love Zhaoying

[Phil Deakins]

@Love Zhaoying

Yes, the second flag has presumably been reset for that account. Also, yes, it's a static flag - once set, it stays set. It's probably an old flag that may or may not still be used, but it was still intentionally included in the code for when scripts request the AGENT_AUTOMATED status. That's my theory, anyway.

I don't think I've misunderstood your post

 

[Fenix Eldritch]

48 minutes ago, Phil Deakins said:

An account's flags are stored in an integer - probably a 4-byte integer, which means there can be up 32 flags, one of which is the AGENT_AUTOMATED flag (bit 15).

Are we certain of this? Just because llGetAgentinfo returns a 32-bit integer bitfield, doesn't necessarily mean that's how the data is stored internally. For all we know, the function may simply be generating that for the return value and is instead reading the data from multiple other sources.

It's possible that the function itself is working as intended, but whatever source it pulls from got corrupted on some accounts - hence support being able to rectify it on the reported account. Garbage in, garbage out as the saying goes.

Edit: Also, AGENT_AUTOMATED is just a constant... a mask that can be applied to the bitfield returned by llGetAgentInfo. As you say, with a value of 0x4000, that means the 15'th bit (and only the 15'th bit) is set. So there is nothing wrong with the constant itself, because again, it's just a mask for checking the 15'th bit of any integer. As far as I'm aware, llGetAgentInfo doesn't use any of the AGENT_* constants for generating the returned bitfield. Rather, we as users utilize those constants to make sense of the bitfled ourselves. That's why I'm leaning more towards thinking the problem is per-account rather than anything with the function itself.

Edited August 23, 2023 by Fenix Eldritch

[Phil Deakins]

2 hours ago, Fenix Eldritch said:

Are we certain of this?

No certainty at all. It's just a theory that could fit why an account's Scripted Agent Page returns the correct result, but requesting agent_automated for it a different result is returned.

I used to have many bots logged simultaneously before traffic bots became illegal, but they were never logged in individually, so the accounts I have that return the wrong scripted agent status didn't make sense; i.e. why would those few be flagged as bots but not lots of them. I complied with the traffic bot ban even before the date it came into force (we were told the date in advance). But I didn't set them all as scripted agents because I wasn't using  most of them any more. Those I did use since then were set as scripted agents. But I used add ones for different brief purposes, logging them in with my bot software, without even thinking about setting them, and it may be that a few of those were ARed and set as bots in the LL system.

There's no way I can remember which accounts I might have logged in like that or for what reasons, so odd ones may have been ARed and flagged as bots, and they may be the ones that return false positives now. The idea of an account's flags being in the same integer is just my imagination. I like it better than a separate set of flags, that's all. Whatever causes the false positives must be to do with bots because it's taken account of in the new(ish) AGENT_AUTOMATED constant.

Edited August 23, 2023 by Phil Deakins

[Phil Deakins]

I decided to check 32 bits for flags and I now know that there are more 16. So it's probably a 4 byte integer.

I'm pretty sure that the 16th bit is the Speedlight Gold flag that (I think) @Love Zhaoying mentioned somewhere. I feel sure of that because I had 2 accounts that were changed to Gold out of the blue when Speedlight was changing to allow everyone to stay logged in 24/7. Their Gold status was turned off when they'd done it, but those 2 accounts are the only ones that it happened to and bit 16 is set for them, but not for others

I know there's at 17th bit being used because, while I was testing, an avatar entered the store and she has the 17th bit set. I've no idea what it indicates though. She has payment info used in her profile, so it could be that [ETA: it couldn't be that or bit 17 would be set for me, but it isn't]. And I saw an av a few days ago whose profile stated that it's a Premium account. She didn't have that in her profile so it doesn't indicate a Premium account. Whatever it is, it doesn't matter. I'm only interested in what causes the false positives.

So I discovered that whatever changes the correct scripted agent status to being incorrect when it's returned as a false positive is not in  those 4 bytes of flags. It's something else.

On the plus side, we can actually check if accounts have Speedlight Gold accounts - if we're so inclined lol.

Edited August 23, 2023 by Phil Deakins

[Qie Niangao]

1 hour ago, Phil Deakins said:

I decided to check 32 bits for flags and I now know that there are more 16. So it's probably a 4 byte integer.

Probably, although of course they could pack two bytes of AgentInfo below two bytes of something unrelated and promise never to need more AgentInfo flags. That would be pretty silly unless bits were at an extreme premium for some reason.

Anyway, whatever's happening in those upper bytes, it can't be too important because mine are all zero 😜—at least as far as llGetAgentInfo knows. See, that's the thing: just because the function returns an integer doesn't actually tell us there's a neatly packed sequence of bits anything like this integer stored anywhere. The function at runtime may assemble this integer from diverse sources (perhaps where the information is most efficiently used internally), and that assembly may involve arbitrarily Special Logic to decide that an account qualifies for AGENT_AUTOMATED.

However that was decided for Wicked Leigh, somebody in Support was able to convince the function to decide otherwise going forward, when merely toggling the Scripted Agent Status didn't have that effect.

It may seem as if it doesn't matter, but (to repeat myself) the reason could tell us how many false positives to expect and whether their incidence is specific to some group of accounts. 

[Phil Deakins]

@Qie Niangao

Yes, the returned integer could be a combination of data pulled from more than one source, but bit 16 and bit 17 (the 1st bit of the 3rd byte) are returned, and we are given no constant for either of those, so I think that the whole integer is returned, but modified for AGENT_AUTOMATED to take account of other data.

I still favour the idea that some avatars have been flagged somewhere as bots, although it's flag isn't in the main set of flags that we're talking about, and that the other flag is intentionally used to modify, if necessary, the returned integer when AGENT_AUTOMATED is requested. As you said, someone at LL easily fixed Wicked's account, which does sound like it's known about and the simple resetting of a known flag - the unchecking of an element in a programme form - fixes it for an account.

Maestro Linden asked another question in my JIRA today, and I've given him the account name of one of the false positives to see for himself.

Edited August 23, 2023 by Phil Deakins