Solution for Privacy Violating Bots
Darling Brody
The problematic bots are those that are not marked as bots so that they may enter locations where bots are banned.
The solution is for LL to actively monitor for avatars that are teleporting all over SL while sending data from a LSL script to an offworld or inworld server. I'm talking about data that can't be collected by the viewer/bot-software directly. The pattern should be quite distinct - teleport, data collected, data transmitted, repeat. Or even several teleports and then transmit the data if it's cached for a while in the script. Ditto for detecting the LSL commands being run after each teleport. The regions are in the best position to detect and collate this bot-like behaviour from avatars that are not flagged as bots. With the unmistakable bot behaviour being the frequent teleporting, collection and transmission of specific information.
Once the offworld/inworld server is identified all avatars sending information to this server should be suspended from being able to login immediately to prevent new bots being created to replace suspended bots. This will ensure new bot accounts are instantly blocked the moment they start reporting data to their database.
The goal is for all bots to be flagged as bots in their profile so that people can block them by using the region setting to deny bots entry to the region. Of course we will need similar functionality to block bots from mainland parcels too.
What we should not be doing is adding limitations to existing LSL commands, or the ability for new accounts to explore SL as some people have suggested.
Bot behaviour is quite distinct and detectable by the regions and this is where we should be enforcing the bot policy on the bots directly.
Log In
Darling Brody
ADDITIONAL :
Websites have this file called Robots.txt that tells bots (like google) what parts of a website the bot can visit.
I propose a similar thing for bots in SL. They could be required to listen on channel xxx for a NO_BOTS message to tell them not to collect information and to not return for 6 months. Any bot that does not obey the restriction can be reported and banned by LL.
The message could include partial restrictions too, such as NO_TRACK_AVATAR, NO_TRACK_OBJECT, NO_TRACK_ATTACHMENTS, NO_TRACT_LAND_SALES, NO_TRACK_LAND_OWNERS and anything else that people want to keep private could be made part of the protocol. But if the message simply says NO_BOTS then the bot is to leave and not return for 6 months. If it contains a list of restrictions the bot can collect non-restricted information, and if there is no message at all on channel xxx the bot can collect anything permitted by the SL TOS.
Daisymaedreams Resident
I can see no reason Bonniebots & the likes of should be in SL or gathering data like that. If a seller wishes to know who many are wearing a product they should run an instore poll. Same for regions. That is what visitor trackers are for. I find the new influx of madisoncybernetic ai bots to be disturbing alongside those who target people to hack their accounts etc. I would like SL to do more to protect the real people and up security, and deal less with these specific bots.
Beatrice Voxel
I'd go along with this, WITH the caveat that certain external domains be 'whitelisted' for web-based attachments that communicate with external servers. For example, the Sunset Muscle League (SML) weightlifting system would likely fall victim to this, as the approved method of teleporting is to remove the HUD, teleport, then add it again (allowing it to resync). There are also companion HUD's that sync with Google Docs, keeping track of daily boards and the like. One of the ways those docs are kept up to date is to ... have a team of volunteers teleport from one gym to the next and see which boards are present, then report that info up via a Google API.
This is but one example where legit users would be flagged as bots and banned/suspended. I'm sure people can think of others.
I am NOT a fan of the bots dropping onto my doorstep every day, filling up my Casperlet ban list. But at the same time, we need to be very judicious about how to deal with them.
RestrainedRaptor Resident
LL STILL refuse to ban the BonnieBots that are literally designed to scrape SL data across the entire grid and violate privacy in the process. They are teleporting all over the place as rapidly as possible, 24/7. If the staff can't even deal with a group so blatantly breaching the rules, what hope do we have?
primerib1 Resident
RestrainedRaptor Resident What rule is being breached?
Izzatooona Enthusiast
I have some concerns with this. First, I teleport a lot. I love going through hundreds of landmarks to see what's still good. And, because I am a toddler most of the time, I frequently have my scanner stuff running. This scanner stuff keeps me alerted to who is nearby, who is wearing adult things, etc. Being a toddler on SL is more difficult now, and it's a constant job to keep myself out of places that could be inappropriate. Because of my love of exploring and the tools I use to stay safe, I could easily be flagged as a bot and banned from places, parcels, regions, or whole estates. It is my sincere hope that LL can find solutions that will not cause explorers like me to be punished.
Jessica Hultcrantz
No!
The approach has a huge risk to impact on legitimate geological surveys. Too big risk of cathcing the innocent.
Bavid Dailey
WHile i support what i perceive as your intent; I am also sure that this would initiate an arms race of changing the pattern you describe and thus requiring the pattern recognition to be constantly modified. An unintended consequence that would inevitably flag real avatars as bots
Not trying to be negative, just realistic. I watched the growth of email spam ,wherea similar arms race evolved.
Off top of my head alternative strategy. On a random basis, the region chooses to test some non bot entrants as follows. A dialog is opened asking the avatar to enter a phrase in local chat within a small time period. If they do so, they're not bots.
Peter Stindberg
Bavid Dailey Yes, and yes. I know Darling Brody for a while now, and while we disagree about the means, we agree a lot on the causes and problems.
I also agree with Bavid Dailey that this will cause an arm's race, very much like we have it already between malware-developers and antivirus products, or spammers and antispammers.
What those arms races have in common is that there are long periods of "peace", then a sudden boost in spammer/virus/bots until the antispammers/antivirus/antibots have caught up, and then a long period of peace again.
Those periods of peace would be better than what we have now. Only region owners have the means to get a modicum of peace - only interrupted by what I call "rogue bots".
Darling Brody and I take the opposite approach in detecting bots (Darling uses large scale statistics, I use micropatterns), but we can both detect rogue bots rather successfully. And so could the Lab.
Lou Netizen
Peter Stindberg Darling Brody thinks I'm a bot, so that's going well.
Peter Stindberg
Lou Netizen Darling Brody meet Lou Netizen, Lou Netizen meet Darling Brody - I know both of you for a while, neither of you is a bot (unless a VERY clever one), now shake hands and be nice to each other.
Darling Brody
Bavid Dailey I added a CAPTCHA link to my testing for anyone who appears to be a bot, and it worked for a couple years until one bot owner started completing the CAPTCHA because he is running some kind of AI bot search engine. I now think the solution is to implement the SL equivalent of the internet's robots.txt files. Telling bots where they can go and what they may collect with LL making compliance with it as part of the TOS.
The NO_BOTS restrictions should be binding on the bot owner and all bots they own, so if one bot encounters a restriction, all bots owned by that person/business must respect that restriction. This way they wont just send a different bot every time.
-----------------
Channell xxxxx
NO_BOTS:180 <--- dont return for 180 days.
---------------
...other possible flags could include...
NO_TRACK_AVATAR, NO_TRACK_OBJECT, NO_TRACK_ATTACHMENTS, NO_TRACT_LAND_SALES, NO_TRACK_LAND_OWNERS