Dean’s Pants

At some point in the history of Second Life, Linden Lab decided that griefing and spamming were such terrible problems that they put in little speed bumps all over the place to prevent abuse of things like automated inventory offers, external URLs, object rezzing, instant messaging, and others.

For instance, say you want your script to offer inventory to the person who just clicked on your object. As a new LSL scripter, you do the straightforward, obvious thing:

1. Detect a touch.
2. Give a virtual nickel bag to the avatar who just touched the object.

You may even go so far as to detect multiple touches and offer everyone who just touched the object their own nickel bag. Soon you find that your everyone loves the quality of your hydroponic, closet-grown product, and people start complaining. “You got something against furries? Why I can’t I have a nickel bag?” Or “Your MJ vendor is broken, dude.”

You scour the documentation and soon find that there’s a built-in delay to giving inventory. In particular, llGiveInventory() has a built-in delay of three seconds. Crazy! How do you make sure to give everyone who wants it their own piece of chloroplastic heaven?

The most common technique seems to be what is affectionately known as the “multiple-slave-comm-script” trick, or as I prefer to call it, the “dispatcher-to-agents” technique. In this technique, there is one dispatcher and many agents. In this example, the dispatcher would work like this:

1. Detect a touch.
2. Send a message to one of the agents (via a link message).

An agent would work like this:

1. Detect a message from the dispatcher.
2. Offer a nickel bag to the avatar who touched the object.

The dispatcher should start with the first agent and work its way down to the last one before starting over. This way, only the agent is affected by the script delay. The dispatcher is immune and can happily go along ordering the agents around all day with no script delays. Beautiful!

If your happy grass gets really popular, you may start to notice that the dispatcher loops around to the first agent before its script delay is done; you got caught by the inherent race condition in this technique. So, to beat it, you make some more agents, and more agents, and more agents, until you discover that all of your agents stop working. “WTF?” you may ask. WTF indeed.

In yet another effort to reduce griefing and spamming, LL implemented further so-called protection. They knew people would use the dispatcher-to-agents method, and when a single object starts doing something griefy or spammy too quickly, they just disable the guilty scripts through some unknown means. There seems to be no warning. And all you can do is reset your scripts and start over. It also seems that this new “protection” only takes effect if there are enough scripts doing the griefy/spammy actions too fast. In my brief experimentation, 16 seems like too many, and the agents are quickly disabled, but 10 is too few, and they run along happily.

But for a popular vendor, 10 agents are simply not enough to avoid the race condition, but at this point, you give up and rationalize that you’ve mitigated the consequences of LL’s anti-griefing and anti-spamming measures as best you can. You console yourself that these protections are also stopping griefers and spammers from maliciously offering inventory too quickly.

But wait, aren’t you an honest avatar, trying to give away your pot in peace? You’re not spamming anyone. You only give it out to people who ask for it!

Here’s the problem with LL’s LSL speed bumps: They don’t prohibit griefers and spammers from working around the problem. When it comes down to it, does a griefer or a spammer really care if they hit the race condition? A spammer may, but they’re still able to spam. A griefer probably doesn’t. But you, the honest avatar who wants to write robust software that works reliably so your customers are satisfied is the one who suffers. The spammer still spams. The griefer still griefs. You and your customers suffer.

(On a side note, this problem is orders of magnitude worse when dealing with XML-RPC.)

What is a virtual person to do? Vote for JIRA issue MISC-686, and ask Linden Lab to remove script delays and grey-goo mitigation, and let honest developers write truly robust and reliable code.