Request for Review: Anti-Defeater strategy

This isn't a request for a specific scripting technique. It's more of a request for a review of a proposed strategy.

Since I'm the one who released the original CopyBot Defeater into the wild, I think it's my responsibility to try to combat the resulting mess, if I can just avoid making the cure worse than the disease.

I've put a bit of thought into it this past week, and I've come up with a strategy that seems like it'll work reasonably well. OTOH, the original CopyBot defeater seemed to me like it would work reasonably well, so I have compelling evidence that my judgment isn't to be trusted without some feedback.

So, before doing anything at all this time, I'd like to field my idea for criticism.

Here's the idea so far:

1. I'll make a one-prim, no-copy, no-mod item available for free on SLExchange, in the style of a political campaign button.
   
2. The item MUST be worn as an attachment. It won't function if left free-standing.
   
3. As wearers move about the grid, the attachment will operate silently, doing a low-frequency (every 20-30 seconds) scan for recognizable instances of my original Copybot Defeater device. It can't work against thoroughly renamed objects, nor will it pick up most other folks' similar efforts.
   
4. It'll sparkle slightly to let the wearer know when it's picked up something worth reporting. But no chat or IM.
   
5. It'll maintain a small cache of recently-discovered devices, so it's not killing your experience or my server with duplicate reports.When it finds a target it doesn't remember, it'll post the device info, the owner's key and the coordinates to me. Over time, I'll build a list of owners and a map of running instances.
   
6. In the near future, I'll send one notecard to each unique owner with a plea to remove all such objects and a short explanation that they've outlived their very brief and marginal usefulness.
   
7. I may provide an opt-in way for CopyBot Defeater owners to retrieve a list of locations for their own currently-deployed instances, in case they've lost track of some. I'm still thinking through the implications of that.
   
8. Everything will be as anonymized as possible. No publishing of names on either side of the issue. I think I should be the face on this, since I'm the one who let the cat out of the bag (well, most of the cat). The goal is to cause minimal additional strain between otherwise-amiable neighbors, so I'll be the bad (Keystone) cop.
   
9. The roving network of scanners will have a maximum lifespan of a few days from the time I first release the item on SLX. After I start getting diminishing returns on new unique sightings, I'll take the item off SLX, and shortly thereafter, any inworld copies of the item will erase their internal scripting and become passive prims.
   
10. Only the information described above will be collected, and will be erased after the project runs to completion.
    

Does that sound like a reasonable approach? Am I missing anything obvious or fundamental?

Thanks!

-- ethan

PS This whole debacle pushed me into setting up a hosting account with Site5.com, which I'd been planning to do anyway. (So far, their feature set, pricing plan, and tech support have been uniformly impressive.) But this is the first time I've ever tried to write and deploy a Ruby on Rails app from scratch, so I think I still have a couple of days of slogging ahead of me before I'm ready with anything at all.

I hope you read all of the feedback in this thread. It was not all bad:

/54/89/148951/1.html

I will repeat that I was the first to point out that it may be a problem but you should not feel bad Ethan. You tried to help the community and there was no greed involved. You could have made a heck of a lot of money by selling it for $50 a pop. No one could have forecast the extent of the mass hysteria. We have another thread here with a couple of different versions of detectors that do a decent job of locating the spammers and gives options for sending an IM to the owner or we can send a message directly. We can also change the name of the spammer that we wish to locate.

The spammers have evolved and the original version isn't the most common, most places I go now.

I wonder if you would be willing to help us with that detector script we've been developing.. I don't think YOUR creation is in use to the degree that it seems.. I think now the issue is that there are so many "copycat anti-copybot bots" out there.. many of which ARE being sold.. (with names like "this really works, my friend tested it"

You created blue goo.. that while it isn't SELF replicating.. it replicates itself through symbiosis.. the defeater raises the level of fear, the fear alerts people that they must surely need this, they install one and pass the fear another 96m. Well intentioned as it may have been.. obviously it got out of control... and obviously, it's mutated repeatedly over time.

Once again, I'd like to publically show my respect for your response to all of this. You have really stepped up to the plate and accepted responsibility for things getting out of hand. You're a stand-up guy.. and I salute you for it. I also REALLY like that you brought this clean-up idea to the forums for discussion.

Basically.. with the hunter-seeker script, the ultimate goal iis for us to have a nice, sanitized, concise, non-harrassing notecard we can pass out to people who are running these things. Many of us are willing to do the legwork to pass out the notecards, but we need a little help creating that notecard. It sounds, frankly, like the notecard you hope to send to the users of your devices.

BTW.. you want the "!quit spamming" graphic for your buttons?

Oh, and I worked out an expiration date system at one point... might be of some use to you in expiring the scanners. It was for a demo model of a genital attachment (long story) but you could probably mod it.

string Date;

default
{
    on_rez(integer param)
    {
        Date = llGetDate();
        
        if (Date == "2006-10-10" || Date == "2006-10-11" || Date == "2006-10-12" || Date == "2006-10-13" || Date == "2006-10-14" || Date == "2006-10-15")
            {
                llOwnerSay("Free trial will expire at 4:00 PM PST on Oct 15 2006");
            }
        else
            {
                llOwnerSay("Sorry, your free trial has expired.");
                llGiveInventory(llGetOwner(), "Scripted Cock, only L$100");
                llDie();
                llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
            }
    }
    run_time_permissions(integer perm)
    {
        if(perm & PERMISSION_ATTACH){
            llDetachFromAvatar();
            llDie();
        }
    }
}

Personally I think anything we do is pretty much pointless. This has reached epidemic proportions and really needs LL to get involved.

However as a scripting problem I would suggest that rather than using llGetDate, usellResetTime andllGetTime with a reasonably high number, say 604800 (1 week).

The other idea would be to make the script slightly more complex. Include some form of email registration so when it changes owner / is rezzed it registers its key with the central server. Then the server could at a future date send a !quit message to turn it off.....((SORRY JUST COULDNT RESIST....))

EDIT:
Think along the server lines, it would be possible to write the code such that the server could even send updates, i.e. new bot names to look for. Although it would add its own problems lag wise, it would be possible to have multiple sensor scripts, each searching for a different bot name and controlled by a 'master' script. Think dance machines.

Jesse,

Thanks for the encouragement

Winter,

Thanks for the sample code! Your attachment handling logic actually cleared up a bit of hassle for me. And I've already designed a button, but I do appreciate the offer.

As to the notecard: I'd been revising that in my head; let me get it down and I'll send it to you to see what you think. Probably sometime tomorrow. I have to work tonight.

Newgate,

I appreciate the thoughts on adding other objects. I don't want this to become something that can be gamed, though....let me see what I can come up with.

As for the end-of-life logic, I think I'll just keep that serverside. LSL makes robust date handling way too complicated, and I may want to change the drop-dead date in the middle of the project. So, my thought is to have a "!quit" command sent back to badges as they make a routine post, and to have idle badges (instances which haven't found anything worth reporting recently) do a periodic keep-alive kind of thing to the server. Say, every two hours or so.

-- ethan

Not sure what the term 'gamed' means but then I speak queen's english dont you know... (I just cant spell it....)

The idea was purely that if you are informed of new bot names then the server can update all the buttons to start scanning for them as well as the ones it already knows about. A form of future proofing, <insert-deity-of-choice> forbid we ever go through all this again.

I agree with keeping the time out server side, thats why I suggested it. Anything else would be a bit limiting / short sighted for the very reason you state, you may decide to extend the life of the hunt at anytime.

A couple of 'multibot' enabled scripts have been added to the other spambot thread
Just to outline the kind of thing I was on about.