Grey Goo Fence

Related to this thread about ways to detect and inhibit runaway self-replicating scripted objects (which LL affectionately calls 'grey goo') I've written a 'grey goo fence' which is supposed to be deployed today, and will probably have an adverse effects on a few legit scripts.

The way it works is it counts the rate of llRezObject(), llGiveInventory(), and llGiveInventoryList() for a particular family of objects (owner_id and asset_id are used to key the counts) and if those exceed a threshold then they will thereafter fail until they stop trying for an while. So this will also throttle objects that simply rez a lot of objects (such as aggressive machine guns) or who give lots of inventory objects around.

Initially the threshold is 240 events per 6 seconds with a 12 second quiet time.

What this means is if you have a machine gun that shoots more than 40 objects per second, and if you hold down the trigger, it will rez 240 objects and then hit the fence at which point it will stop rezzing. If you hold the trigger down it will continue to NOT rez until you let off the trigger for longer than 12 seconds.

The fence will clamp down on the whole family of objects, so if you were shooting bullets that also rez shrapnel then the bullets that exist when the threshold is passed will also fail to rez or give inventory. The bullets and any children will not be able to rez or give inventory. Also, if you happen to be holding two identical guns and one hits the threshold then the other may also be affected.

If the object and its army is temp-on-rez then whenever one hits the fence it will be simply deleted.

Any object that hits the fence will lose all of its 'energy' budget. The script will not be descheduled, but all pushes and most movement methods (hover, apply implulse) will become severely attenuated.

Granted, there are some holes in the fence and a clever scripter can aim for them at their peril, but I'm going to add some improvements in the second version that will try to plug those holes.

I'll be interested in hearing feedback and opinions about this feature in its initial incarnation. Of course, I'm going to revise it, tweak the numbers, and add special intelligence to it in a effort to make it smarter about distinguishing the difference between true grey goo and simple vigorous objects,. but it seemed pretty important to get something out there as a start.

That sounds reasonable. (Well, actually, I was just going to add shrapnel to some cannon shells that I was designing, but I can always tone down the rate of fire a bit.)

What would be the effect of a sudden mass assault on the fence? I'm thinking of a self-replicator that initially works quite slowly, generates a lot of copies of itself and then suddenly *bang* they all start trying to replicate at the maximum possible rate....

Dot-com business plan...

1) Collect a large number of cool freebies from all sorts of creators.
2) Create a new script in each of them, paste time-delayed, or externally activated malicious code into it.
3) Go on a cruise for a few months. Large parts of the grid are now filled with lots of different objects from different owners and creators.
4) Press the big red button (eventually without even needing an SL account)
5) ???
6) PROFIT!

Ordinal, as soon as the fence is hit then it comes into effect. So the slow-building goo may grow under the radar, but as soon as it tries to burst it will burst to 240 events.

Thank you for the help Eggy, we already know you're clever. I mentioned in the original post that there were holes in the system.

The fence done on a per-sim level. Distributing the attack doesn't prevent the sims from counting to 240, but this fence is only for explosive grey goo and is not a magic spell.

It might be impossible to protect something as permissive as SL 100%. If that is the case then the virtual worlds that will thrive will be probably be small or restricted. Time will tell.

Maybe I'm being paranoid, but personally, I'd have preferred that changes that could potentially break every rezzing device and vendor in world (as if llGiveInventory isn't already flakey enough!), might, just be tested on the preview grid first for an appreciable time.

Maybe we'll be lucky, but I remember the mess over the Base64 Xor function...

Testing would have been good, I agree.. but a big thumbs up to the idea. Not foolproof, but a nice start.

This sounds like a good idea-- but it sounds like it will only help with the less refined attacks. Rezzing tons of replicators is a simple attack, but DoS attacks by flooding the asset server still seem to be possible, even with the inventory transfer restrictions.

Also, perhaps you should be able to increase the limits for some trusted residents who need the extra activity. Perhaps alert users when they're being throttled, and then they can optionally contact a Liaison to request more event activity.

This sounds like a good idea-- but it sounds like it will only help with the less refined attacks. Rezzing tons of replicators is a simple attack, but DoS attacks by flooding the asset server still seem to be possible, even with the inventory transfer restrictions.

Also, perhaps you should be able to increase the limits for some trusted residents who need the extra activity. Perhaps alert users when they're being throttled, and then they can optionally contact a Liaison to request more event activity.

Decent solution. At least it will take care of one kind of problem with minimal new problems introduced.

Good to see some work done on this.
Let's just hope the evil griefer kind doesn't read this.

Andrew/Torley/Pony

Any chance we could get this in the annoucements forum as well? That way it'll at least appear on the community page?

-K

So let me get this straight, for legitimate uses of large-scale rezzing... say, boxing up and switching between multiple looks for a whole sim, since the asset ids would all be different and I'm only rezzing one of each asset, there is no chance of hitting the rezzing limits?

So would you rather not be able to rez a bunch of stuff or have the grid crash?

This sounds like a good idea-- but it sounds like it will only help with the less refined attacks. Rezzing tons of replicators is a simple attack, but DoS attacks by flooding the asset server still seem to be possible, even with the inventory transfer restrictions.

Also, perhaps you should be able to increase the limits for some trusted residents who need the extra activity. Perhaps alert users when they're being throttled, and then they can optionally contact a Liaison to request more event activity.

Eggy, you started that plan in Beta, didn't you?

Does it also mean it'll affect things like unpackaging pre-built houses, holo-vendors and scripts which repeatedly spawn temp-on-rez objects to walk around the lot prim limits..?

edit: Asking because "owner_id and asset_id are used to key the counts" doesn't tell much, i.e. doesn't explain how these are used to track the spawn rate...

Unpackaging houses, yes, if they're over 240 prims, I think. That's a point.

Temp-on-rez walkers should be okay as long as they're properly written. At 5m/s or so, in six seconds you'd have to be rezzing six prims a metre to go above the limit, and no way should any walker be doing that....

Did you even read what I wrote? Doesn't look like it.

I don't know what 'walkers' are ^^;; meant more something like this which i presume can wind up rezzing a lot of large prim-wise stuff frequently. Which is likely a bad thing on its own, but that's another story.

Actually, probably not, those things don't re-rez that frequently. Unless you put a very high-prim object into one.

I think they're abusive personally, but that's another argument.

By "walker" I was talking about the objects out there that rez little temp platforms under you as you walk around.

Andrew,

If you can implement this that "severly attenuates push", then it mustn't be too hard to implement the "no-third-party push" parcel flag, right?

We've got about 350 votes on the proposal now.

I don't see anything about push here...

I think I may be getting confused with this "family" vs "owner id and asset id". The "family" of objects, including all children etc, gets clamped down on, but is the count of the entire family or just of things with the same owner/asset id?

I'd like to see it in practise, but it does seem like a reasonable move. It will break some things, sure, but it will leave most or all reasonable scripts, save shrapnel guns, intact, or probably intact. House rezzer's might be at risk - but including something saying "your house will rez over the next minute because of anti-grid attack controls on the system" is not going to unduly worry the purchaser as long as the house DOES eventually appear, and might actually make most of them more confident about buying a house because the grid's more likely to stay up for them to enjoy it!

How about adding an extra bit of granularity to all the land controls too. At the moment we have "no build" and "no outside scripts", but how about a "no outside rez calls"?

People that run *ingo can still set their parcels to work.
People that have damage enabled might lose the right to turn it to no outside rez calls (although from the point of view of courtesy it will work a treat if the landowners can shoot the griefer and they can't shoot back...)
Folks that choose to can allow people to build on their land if they're willing to be friendly, but stop the goo attacks by denying them a place to start with the scripted assault.

From the sound of it, any system that obeys the "rules" for llRezObject won't be affected by this. It'd take a sustained rate of 40 calls per second to llRezObject to trigger this fence, from Andrew's description, but a single script can only call llRezObject at most 5 times a second. It seems to me that I could set up a shapemaker to rez a huge sphere, using up every single prim in my sim, and still not run into this barrier. It also seems like customers that buy my build packaging system won't have to worry about houses failing to rez.

The only legitimate thing this might affect is a machinegun... and everyone knows that the only way to rez bullets that fast is to "work around" the script-delay system by using multiple scripts. It would require more than eight rezzer scripts to run into this limit with a single object. At that point, you're so blatantly pushing against the implied "don't rez so fast" rules that you kind of have to expect something else might stop you.

One question I have: what happens if I rez an unlinked set, or a 255-prim object, with one call to llRezObject()? Does that up my "family's" counter by one unit, or is it upped by one per object in the unlinked set, or is it one per prim? Because if it's the latter, then this could end up being a lot more of a nuisance than I thought... and if unlinked sets only count for one, this might be a good way to get around the limitation for a grey goo attack. Then again, the llGiveInventory limits would still apply, so I suppose that's not a problem.

Basically, we're not being limited here very much more than we already were, as I see it.

The only concerns I'm having, at first glance are as mentioned house-rezzers.

The problem is not so much correcting the rezzers to take into account the fence, this is trivial -- but rather the unknown number of already distributed items that'll break.

The second, has to do with things like Shape Makers -- but agian, the fix should be fairly trivial.

The last concern, would be very successful merchants that may have many many vendors, particularly if they're "holo" vendors could hit this limit. I don't shop enough in-world to know if there are any merchants out there now that would run this risk.

Out of curiosity, will scripts that hit the fence get a debug/error message saying what's wrong? This would help quite a bit in debugging and customer support in-world.

Actually, I made an assumption in my last post that may be incorrect.

If I have a vendor, and I rez 10 copies of it -- do they all have the same "asset id?" Or by asset id, are you refering to the object's key (UUID)?