Four times this week the Grid has been attacked by a plague of self-replicating objects, as evidenced by this report on the Grand Unified Linden Blog and these two reports over on Second Life Insider. These objects spawn copies of themselves, kind of like the classic UNIX “fork bomb” that spawns new processes until the system is overwhelmed, and quickly overwhelm, not just the parcel or reagion that they’re in, but the asset server itself, which causes a world of hurt for Residents, breaking Search, the map, and teleportation. (The objects may also exhibit other annoying behavior.) The last couple of times this happened yesterday, LL actually had to pull the plug on every single freaking script on the Grid to be able to stop these things. This causes a hell of a lot of stuff to stop working…and nearly caused Danielle to lose L$1000 in a texture vendor.
So, my question is: What is Linden Labs doing to find the perpetrators of these acts, to get them off the Grid, and to ensure that this sort of thing can’t happen again?
Creating objects that interfere with the functioning of the Grid to such a degree that LL has to disable all scripting functionality in order to clean the mess up…that sounds like a pretty damned clear violation of TOS 4.1(viii) as well as “Disturbing The Peace” under the Community Standards. Any user doing this really ought to be kicked off the Grid, for good. But…will they stay kicked off? Thanks to the removal of account verification on the beastly day of 6/6/06, a user whose account has been terminated “with extreme prejudice” can simply create another account and be back online in mere minutes. LL has supposedly implemented a “machine hash” so they can block entire systems from accessing SL…but I don’t know how well that’s working. Even so–and this is a point many critics of the open-registration policy overlook–there’s nothing stopping a kicked-off griefer from contacting his buddies via AIM (or what have you) and passing along his griefing techniques to ten of his closest friends. Result: up to ten more attacks. Theoretically, this could replicate in much the same way that these objects themselves replicate. Lack of open registration would slow down the onslaught, but would probably not eliminate it entirely.
So…how could LL prevent this from happening altogether? I don’t know if there’s a good way to do so without breaking script behaviors that many existing objects rely on. Some have glibly talked of restricting the use of llRezObject(), or even scripting itself, until an account becomes verified and/or has been in-world long enough. Aside from the fact that it still wouldn’t stop a sufficiently-determined griefer, I think that would add a slowdown to the operation of scripts that need to rez objects, by introducing a whole bunch of extra security checks into the process. Is this a necessary evil? I don’t know.
One thing I do know: Danielle said, in response to news of the latest attack, “The griefers got smart.” Here’s hoping LL gets smarter in response.