Jump to content

LL needs to implement a way to detect bots via script - urgently


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

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

Recommended Posts

3 hours ago, Maitimo said:

I wonder if there's a possibility of implementing some kind of captur task. I know its possible because years back, when camping chairs were still a thing, some places actually used this. There would be a pop-up asking a simple maths question and if you didn't answer correctly, and quickly enough, you'd be unseated from the chair and ejected from the parcel.

Not that I can think of.   If you do it all in-world, it's going to be easy for whoever develops the bot to programme it to answer the maths question, and if you direct them to an external website to complete a captcha  people will complain they're being asked to expose their IP addresses.

And whatever you do, you're going to have to do it on a region-wide basis, and be prepared to ban a lot of people over false positives because they didn't properly complete the captcha in time, or didn't see it, or couldn't be bothered.

The only way to ban bots programmatically, I think, is if there's a new flag for llGetObjectDetails, OBJECT_SCRIPTED_AGENT or something, as suggested by the OP.   

But even that doesn't address the issue that any data a bot needs to collect, it can probably collect in well under a second, so it doesn't need to stay for as long as it would take to complete a captcha, and you're going to need to run any automated scan of avatars on the region on a very fast timer, which has resource implications, particularly at busy events like Hair Fair, to stand much chance of catching a bot while it's busy doing its thing.

There's a constraint of 6 tps a minute, but if detecting bots by scripts becomes a common practice, then the sensible bot-controller will have them visit 5 regions in quick succession, too fast to be detected by anything other than a scanner on a very fast timer, then return to base for a minute's rest before continuing.

We could always try shouting !QUIT at them, I guess (I sometimes still see "anti-bot" gadgets around the grid doing that!).

 

Edited by Innula Zenovka
  • Like 3
  • Thanks 1
  • Sad 1
Link to comment
Share on other sites

Thank you everyone for your comments, here and on the JIRA, and for keeping the thread alive :)

I know the idea is a very, let's say, limited one. I also know that there have been requests to have an option on the parcel/estate settings to disallow scripted agents which have been rejected or ignored. That's why I didn't bother asking for that even though that is what we absolutely should have.

There is no real difference in what is being asked for now, the difference is this time there is some public support for it due to the persistently annoying behaviour of these bot owners. Times change, minds change... maybe. Perhaps thinking about having to implement such things would make the point that there is an underlying problem that needs addressing more directly.

I'm also fully aware that by the time a bot gets detected it's likely too late to stop it gathering whatever data it wants; the best we can do with this is to eject them before they are really noticed. Even using llGetObjectDetails(), which would be quicker than my initial suggestion (although I suspect more difficult to implement, hence why I really didn't bother going that way), it would still be reliant on a timer which no-one wants running too quickly and adding server load. Having a "I am not a bot" test when an agent is detected is pointless and would lead to false positives. I have a system in place on my land already that I could leverage for that in a few minutes' code changes, but it just wouldn't work.

Should someone wish to file a JIRA with a better solution - count me all in! I guess what it comes down to from my perspective is that we are supposed to have control over our land with regards to who is allowed in, yet we have not been given sufficient tools to do so in the case of bots.

I don't want to get into the previous debates - most of us here are on the same page and there are other places we can do that. Yesterday, having three bots visit my parcel while I was there ended up spoiling my enjoyment of my land. If it continues and no action is taken to allow us to control access to our land more effectively then all I can think of doing is leaving SL. I'm trying to find a way of doing something about the situation, before that happens.

Edited by Rick Daylight
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Something you can do on private islands is to require payinfo or access group membership at the estate level. That's just a checkbox, no script required, and gets rid of basically all the gridbots, since none of them are payinfo.

The madlands is another story. Bots don't have to be in your parcel to use https://wiki.secondlife.com/wiki/LlGetAgentList (or, ya know, to poke the viewer library for the same kind of info), and good luck getting the lab to make a payinfo-only continent.

Edited by Toothless Draegonne
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 minutes ago, Toothless Draegonne said:

Something you can do on private islands is to require payinfo or access group membership at the estate level. That's just a checkbox, no script required, and gets rid of basically all the gridbots, since none of them are payinfo.

   There are actual users who don't have PIOF too, though, and there's nothing really stopping a bot operator from setting their bots up with it. 

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

I think what I like about this proposal is that it gives scripted agents, bots, whatever, the opportunity to behave as good citizens. I think we should be supportive of people who want to run things like this in a way that's meant to be above board. If such services or groups suddenly don't want to identify their agents when it means they could be subject to detection and restriction, well, then we can have a different conversation.

Edited by Ezbeharra
department of redundancy department
  • Like 3
Link to comment
Share on other sites

2 hours ago, Coffee Pancake said:

Why does that matter. We're not trying to rules lawyer out he perfect sentence that will product the desired result, this isn't an incantation or magic spell.

Some things take many requests before the message gets though.

 

It was just a question, sheesh. I don't like seeing good ideas get shot down because there isn't enough to differentiate them from previous suggestions made. I see it every single day in my job and I hate it there too. I think it helps to put the differences out there ahead of time so those who can make the changes needed will be forced to read them, hopefully will understand them and then the ideas are more likely to get put into place. I have to drill this into people's heads at work all the time. Help me get those who need the information get it, so we can implement the changes we need to implement. It does matter, a lot, even if you don't understand why it does.

I even said it's a good idea, because it is. Maybe I should stop posting on this site, some of the attitudes people put behind their words make having conversations about important things impossible. I'll just go back to read only, its ridiculous. 

Edited by Caeruleiae
Link to comment
Share on other sites

I can't help thinking what I could do if access required accepting an Experience... 'they' would soon figure out how to accept it. Then... meet my integrated Experience/RLV system. Oh, the fun I could have with 'people' who can't file an AR!

Seriously, accepting an Experience is one way for island owners that would still allow non-paying members access. I don't want to shut people out. That's not applicable to most though, and not me, and still isn't ideal.

The means we have to control access to our land is no longer sufficient - that needs to be changed.

Edited by Rick Daylight
  • Like 2
  • Haha 1
Link to comment
Share on other sites

Out of curiosity, I wonder if you can beat them at their own game, generate a list of whatever huds or attachments they are wearing that are responsible for gathering whatever data they are after and then create a security orb that auto ejects them from your land if they are using any such attachments.

Edited by Istelathis
Link to comment
Share on other sites

14 minutes ago, Istelathis said:

Out of curiosity, I wonder if you can beat them at their own game, generate a list of whatever huds or attachments they are wearing that are responsible for gathering whatever data they are after and then create a security orb that auto ejects them from your land if they are using any such attachments.

Isn't there a script, that recognizes certain aspects of a script or certain scripts used in those bots/object. Think some clubs have a system that recognizes scripts in an object or even hud and based on that eject the person who is wearing it, if he/she doesn't remove it.

Edited by Dorientje Woller
  • Haha 1
Link to comment
Share on other sites

At the moment we cannot detect HUDs by script... I believe that is being changed though. One of those JIRAs that got approved.

I would argue that the exact same reason for that, land owners being able to see what their visitors are doing, applies to detecting bots.

Edited by Rick Daylight
  • Like 2
Link to comment
Share on other sites

The problem with using a script to detect and eject the Bots - no matter what the script is checking - has already been mentioned in the thread as something that will only sort of work.  The bots will very likely gather whatever info they want faster than the security system will eject them.

We really do need a tick box, as someone suggested, that says 'no scripted agents allowed'.  And yes, even that won't work if the bot is not actually marked as a scripted agent., but it at least would work better and be less performance intrusive than a script for the bots that are properly registered. 

And that particular check box needs to apply to ALL HEIGHTS, not just the first 50m above ground.

Edited by LittleMe Jewell
  • Like 12
Link to comment
Share on other sites

26 minutes ago, Dorientje Woller said:

Isn't there a script, that recognizes certain aspects of a script or certain scripts used in those bots/object. Think some clubs have a system that recognizes scripts in an object or even hud and based on that eject the person who is wearing it, if he/she doesn't remove it.

No, there's no way to detect by script what scripts an object contains, unless you happen to know that the script you're looking for responds by being pinged on a particular channel.

And bots aren't scripted objects.  They're regular avatar accounts logged into SL via particular viewers which control the avatar from the remote PC by code rather than by a human interacting with the interface.  The bot might (and I stress might) be assisted by scripted objects, but a great deal of information is exposed to the viewer anyway and is therefore available to the bot-operator's PC.   

But if the bot is supplementing the viewer's capabilities by  wearing a hud that runs a sensor or llGetRegionList on a timer, processing the data and then passing it back to the bot via IMs or llOwnerSay, you're not going to be able to detect that.

 

  • Like 3
Link to comment
Share on other sites

18 minutes ago, Rick Daylight said:

At the moment we cannot detect HUDs by script... I believe that is being changed though. One of those JIRAs that got approved.

I would argue that the exact same reason for that, land owners being able to see what their visitors are doing, applies to detecting bots.

Unless that's very tightly restricted -- e.g. scripts set to a particular experience can tell whether people are wearing HUDs temp attached by that experience before they try to attach another one, which would be very helpful -- that  would raise some serious questions about privacy, I think, and probably more than do any bots. 

  • Like 2
Link to comment
Share on other sites

@Innula Zenovka I tend to agree, that was my first thought when I read it.

It's a tricky one to my mind though... I have a right* to privacy and to wear a HUD without people knowing, but land owners have a right to know what people get up to on their land. To be honest I'm on the fence about it right now. I'll have to check up on the facts, if I can find the details again.

Certainly though if that is allowed by LL, not allowing the same level of detection for bots seems very one-sided towards the bot runners and against land owners.

Of course, there is really no such thing as rights. It's a concept that we have to fight for.

Edited by Rick Daylight
  • Thanks 1
Link to comment
Share on other sites

Technical question, just to confirm: If the function migrates from llRequestAgentData() as specified in the original Jira to instead be on llGetObjectDetails(), how long after the agent leaves the region will it be possible to execute that function? I'm pretty sure it's reliably longer than a few seconds, and that's kind of important in this case, where the agent may be detected (perhaps by collision) but be gone from the region before the query can execute.

Note also that not all responses to a positive scripted agent result involve restricting access to that agent.

  • Like 2
Link to comment
Share on other sites

Good question... according to the wiki,

"A single valid result may be returned after the avatar leaves this zone"

"Information for avatars that can no longer be found will still be available for a short period (about 45 seconds) but it is not updated."

And yes, booting the bot is not necessarily the outcome. If I wrote the script there would be a whitelist. It's a long time since I used my own bots, but it has been known.

I do know that detecting and booting, simply based on a timed llGetAgentList() and a UUID blacklist can be so quick the agent never seems to get in, it's like the TP failed to happen from their view of things (my test alt in this case). That's lucky when the timer just happens to run as they try though.

Edited by Rick Daylight
  • Like 1
Link to comment
Share on other sites

55 minutes ago, LittleMe Jewell said:

The problem with using a script to detect and eject the Bots - no matter what the script is checking - has already been mentioned in the thread as something that will only sort of work.  The bots will very likely gather whatever info they want faster than the security system will eject them.

We really do need a tick box, as someone suggested, that says 'no scripted agents allowed'.  And yes, even that won't work if the bot is not actually marked as a scripted agent., but it at least would work better and be less performance intrusive than a script for the bots that are properly registered. 

And that particular check box needs to apply to ALL HEIGHTS, not just the first 50m above ground.

I really want a box to tick now, Linden Lab.

I am annoyed. It is like pest control for me. I want it to be there, regardless if I need it or not.

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

Recently I logged in world and noticed a lot more bots then before. Place I landed at was a couple of people talking how they're sick of them.  I put my 5¢ in and gave them the link from the Jira and the bots issue is on everyone's radar. One of the persons thinks some might belong to a big company and he was planning to post it here on the boards.  I suggested he lodge a ticket instead.

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

6 hours ago, Marianne Little said:

I want to be able to stop bots too. I wish it was an option under "land". Tick it, and bots-b-gone.

...Feeling contrary, Lindal considers making a Bot Haven, a parcel dedicated to feeding, housing, and succoring poor discriminated-against bots.

  • Like 1
  • Haha 7
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 328 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...