Goo Fence Error Message
Monday, October 9th, 2006 at 8:21 PM by: Robin LindenMany of you are seeing an error message associated with scripts that were working and now report a “rez failure”.
This weekend we took some aggressive measures to mitigate the ‘grey goo’ attacks, including one which is resulting in this error message because it’s misidentifying your content as grey goo. Your content may be fine, but you’ll be seeing this message for the next 36 hours until we close for the Wednesday update. There are some changes in the update which will fix your object so you no longer receive the error message.
In the meantime, you can take your content to the beta test grid tomorrow to verify that your content will be ok after the update.
October 9th, 2006 at 8:27 PM
question: at Terminus we have some single-prim replicating plants that germinate, grow, seed, etc…and we had about 600 of them or so. They were identical except for some genetic parameters. They reproduced slowly, maybe every 15 minutes at most.
Saturday, they disappeared before my eyes. At first I assumed the owner had sent out a viral update to them and had borked them somehow. Now I’ve begun to suspect that your “agressive measures” ate them. That’s cool. I understand it, and have no problems there, but I’d like to know for certain. Is there any record of large events hitting the grey goo fence? Is there anyway for someone to check this sort of thing?
Thanks!
October 9th, 2006 at 8:28 PM
Thank you Robin!
Now, what about the database today? Money transactions failing 99% of the time since the grid came back online. Searches, attempts to rez items, all failing. Can’t pay anyone or get paid. What is going on? Many of us have to conduct business to survive here.
The system is currently unable to process your request. The request timed out.
Money transaction denied because the request is stale.
October 9th, 2006 at 9:10 PM
also….would a sim rollback to restore the lost plants at Terminus be possible? I only ask because this was an evolving ecosystem and had settled into a nice equilibrium….or something close to it.
Releasing new plants, ab origine, would be fine but it would represent a lot of lost data about complex interactions.
Thanks.
October 9th, 2006 at 9:46 PM
I understand what you are trying to do, but SL REALLY needs content creators (plus I like doing it).
How about a scheme whereby scripters need to get verified to write scripts that rez stuff?
I wouldn’t mind something like giving LL my email and phone number and responding to both to be allowed to use any of the rez or give inventory commands in my scripts. Then include the scripters personal UUID in the call.
October 9th, 2006 at 10:25 PM
This seems to affect both my Vendors. Union Micro and another that I don’t know the name of, both rez 3D objects.
I’m OK as long as this is going to be fixed, but it could upset a few sellers.
October 10th, 2006 at 12:50 AM
Ralph: I’m ok with this if it could make SL more stable and stil give me flexibility. It’s great idea. I think something like unintentionally uncotrolled release of self replicating objects would not be punishable with lost of scripting permissions, but intentional release of grey goo would, for all accounts of a person.
October 10th, 2006 at 12:59 AM
Hmm, I can see where you’re coming from, Ralph, but….imagine the amount of people producing guns, bows, even the plants mentioned previously. I’d estimate that around 20% of scripted products in SL use llRezObject somewhere or another, and, if we take that to be true, surely too much of Linden Lab’s time, which could be used on protecting the system against such attacks, would be wasted on authenticating the thousands of denizens of SL. Then, you’d all complain about how there was no content being released by Linden Labs. I personally beleive that a better idea would be to have each script with llRezObject needing to be authenticed by five other /residents/. As it is, when a person hits edit, on another persons object, and go to “More > More” ….there are the options of “Rate Owner”, “Rate Creator”, “Mute”, and “Report Abuse”. They could add a button called “Authenticate” which, when done by five people, allows the object to do potentially disruptive stuff, such as RezObject.
October 10th, 2006 at 2:35 AM
A responsible scripter would set their objects to STATUS_SANDBOX while testing anyway, so they should be quite safe
October 10th, 2006 at 5:11 AM
The more I hear (and think) about the verified-scripter proposal, the more I like it. Would it really be that much of a hoop for someone to jump through before starting to script? I think not.
However, the only way it would be 100% effective is if you require verification before a user can run ANY replicatiing script, not just those they write. I could, for example, have one verified account and a number of non-verified ones. I write a grey goo script using my authorized account and give a copy to one of my unverified alts. That’s the one I use to do my griefing. We’re back to square one.
October 10th, 2006 at 7:09 AM
Its amazing just how much we depend upon llRezObject() at the Shelter, and many items are broken at the moment.
After Wednesday’s update, should scripts using llRezObject in a reasonable way simply begin working – or will we need to recompile them? Just want to prepare
October 10th, 2006 at 8:40 AM
Michael – That’s the point to having the UUID in the bytecode. If you write a gray goo script it doesn’t matter who runs it, you are responsible and hopefully will get prosecuted. The idea is that the scripter is responsible for what (s)he writes.
October 10th, 2006 at 9:13 AM
If the scripter is reponsible for any use of the script, then I will certainly not be giving away my scripts and letting people modify them any more. I was just trying to be helpful, but it seems like it’s just possible to make me responsible for bad stuff. Because as far as I can tell, I could make an innocent script, and then someone could modify it to be malicious. I haven’t tried to see what happens (personally with an alt account) to the ownership/creation permissions when I give a modified script to someone else and they modify it. And even when I do check that out, LL could always change the way things work on an update without me realizing it.
(Of course, I can still post my scripts to the LSL wiki site. So, the person who takes them in-world would be the creator.)
October 10th, 2006 at 9:18 AM
I don’t like any of the proposals people have come up with for “verified scripters”. This is just getting into another arms race like the llPushObject situation. We’ve gotten rid of third-party llPushObject for most places, fine, now people are using other physics calls to get the same result. Blocking grid attacks through self-rep won’t stop griefers, and it won’t even stop mass assaults that are almost as annoying and frustrating. The only way to get rid of people using throwaway alts to stage attacks is to get rid of throwaway alts.
Get rid of the whole idea of an “unverified account”. It’s an experiment that didn’t work. Come up with new schemes to validate users and associate them with SOMEONE who takes responsibility for them. Cellphones. Sponsorships. Subcontract account validation by selling “bulk” accounts to people who take responsibility for the folks who sign up through them. There’s dozens of alternatives.
October 10th, 2006 at 10:04 AM
Firelight – If someone takes your script and modifies it and it has one of the “dangerous” LSL instructions in it, they won’t be able to compile it unless they are verified themselves, and their UUID would be embedded in the code, not yours.
October 10th, 2006 at 11:35 AM
There are no “dangerous instructions”… or else, all are dangerous.
Trying to figure out all possible combinations of code that could be “dangerous”, without breaking working code, is equivalent to solving the halting problem.
October 10th, 2006 at 12:15 PM
Firelight: If you make a script that’s modifiable, and give it to someone else, and they modify it, it will still list you as the creator, and the only place their name is on it is in the owner field. And obviously if they give it to someone else, then they won’t be the owner anymore either.
If there were a ‘last modifier’ field, that would make it easy to see who last edited a script or object (although a grey-goo-attacker could still use an unverified alt to paste in their script).
October 10th, 2006 at 12:20 PM
Dear Lindens:
Your changes have prevented furniture that spawns sex postions from working, essentially bringing my business to a halt while you sort of the problems that were created only by your lack of foresight. If you had taken action a year or more ago, when these attacks started to become popular, we wouldn’t have to deal with this today. Good Going.
October 10th, 2006 at 12:55 PM
Rich – but if only verified scripters could use things like rez or give inventory, then they couldn’t use an unverified alt, they couldn’t compile and save the modified script.
While I suppose it’s conceivable that there could be scripts that could be used unchanged to launch attacks and also have reasonable non-griefing uses, I think they are pretty esoteric. If someone writes a such a script and it’s used in a griefing attack, they’d better have a darn good explanation of how it was used in an innocent application and then got subverted to griefing.
October 10th, 2006 at 1:47 PM
I suppose the Idea of “grey goo” is acceptable, though i dont fully understand the concept. But in the previous post, the thought was brought up of verification and “trusted” accounts, i dont life the idea of verification. And i totally agree with Ralph, Anyone using a malicious script should have an extremely good reason to have it, otherwise they should be held totally accountable for their use of the script, whether that includes banning, or prosecution. Case closed.
October 10th, 2006 at 1:56 PM
I want to make sure you all realize that you can’t assume that the objects which have caused problems were necessarily scripted or launched by the person named as the creator or last modifier.
The griefers are able to use objects they didn’t create (for example one that Philip Linden created) for their attacks. It’s quite possible, and probable, that the attackers are not only attacking the Second Life community, but also trying to pin the attacks on someone they’ve chosen as a victim.
October 10th, 2006 at 2:42 PM
Robin, that’s the whole point to my suggestion. Don’t attempt to pin the responsibility on the person listed as the owner, pin it on the person who wrote the script.
The idea is to have an extra verification step for people who want to be able to compile and save scripts that include LSL statements like rez, give inventory, probably the messaging commands, etc. This would be some combination of a paypal account, phone number and email that are verified, etc. Anything that lets LL have a high confidence that they can actually get to you.
If you aren’t verified, when you attempt to compile and save a script with one of these “dangerous” statements, it will error out. Any other scripts work fine, and anyone can run any scripts with or without these statements. This has no impact on distributing scripts, free accounts, etc.
If you are verified, the LSL compiler or the asset server will embed your personal UUID in the code – presumably there’s some kind of metadata in the scripts. Then if that script turns up in a griefing attack, you’re in trouble, and since you’re verified LL can actually trace you, ban you, call the FBI, etc. LL could also go through all the scripts written by the same person and disable them as well.
Anyone who writes a griefing script is held responsible, no matter who actually runs it.
October 10th, 2006 at 4:07 PM
how hard would it be to attach a mod-history to each script to track who has changed it? Obviously creator applies to the user that created the document record… obviously tracking who added the malicious code is more difficult… not allowing TBD “untrusted” to compile when one of the TBD “dangerous” calls are made would prevent a lot of headaches….
IMNSHO: Any distributed coopertive trust system is not a good idea… it’s too prone to being gamed. Next thing you know we would end up with some committee that rates scripters and offers their “trust-approval” to scripters for a fee…. or some other onerous social-exploit
I’d rather have LL be the sole authority on “Trust.” It is their server array, after all is said and done.
And they are the only one’s that “trust” is really important to… We users just experince the fallout from LL not establishing “trust” from their customers…
I don’t want any in-world indication of who is trusted by LL and who isn’t… your “trust” relationship with LL is none of my business.
“Trust” for my user being on the grid should be between LL and me, not me and thee…
Put another way… My “trust” relationship with LL is none of your business.
even showing verified/unverified/paid is heading the wrong direction in my opinion.
We already have a system for establishing in-world trust via ratings. Use it.
=B-)
October 10th, 2006 at 4:19 PM
Ralph, this solves nothing. The three forms of identification can be easily faked. 1. throwaway e-mail account at google/hotmail/yahoo/or any other e-mail site. paypal account created with the same e-mail. And as for phone number, if it’s any way possible it would have to be an automated system. Phone numbers can be faked through throw-away cell phones, calling from payphones, piggybacking on phone networks, and general other phreaking methods. it’s even possible through a simple skype account validated to recieve incoming real world phone calls set up on a computer with a spoofed IP address. What you are suggesting will make it more difficult for people who don’t have malicious intent, but no more difficult for those who have the knowledge and ability to hack (which is proven by the simple fact that they are scripting malicious content to take a grid down).
October 11th, 2006 at 12:54 AM
Stop trying to look for automated solutions to a human problem. All these limits and delays in LSL? They just make it impossible to get any legitimate work done. And they don’t seem to be stopping any griefers. You’re throwing the baby out with the bath water.
Make it easier for *humans* to defend against griefers. Thats the real solution. Its already easy to ban greifers off your land, but the problem is when they leave objects around. Banning someone should return all their objects with them. And prevent them from moving in to the parcel, ever. The only protection against malicious humans, is vigilant humans capable of defending themselves. There is never going to be a magic automated solution. You only hurt the community by trying to add more “This time for SURE” measures and “trusted user” systems.
October 11th, 2006 at 4:14 AM
I hope Lindens realize that none of my teleports work, due to their “aggressive measures”. GRRRRRRR…..
October 11th, 2006 at 7:54 AM
Thanks for the comments about what happens if someone else modifies one of my scripts (in-world). I think I won’t give away any modifable scripts for now – at least until this stuff gets better sorted out. And, they’re not really ready, anyway – so it’s no big deal.
For the imbedded code idea to work, there would need to be a history. Otherwise, a user could give their script to someone else (after making it malicious) and get them to compile and run it. Not every user is going to understand the scripts or that they probably shouldn’t compile someone else’s script and use it. So, without a history, the user who compiled it (but may not have written it) would be the culprit. And, then there’d have to be some record of what was added/written at what point to really figure out who the culprit was since it could go through many hands. That seems too complicated and resource intensive to implement what was changed. So, a history would only give you a list of possible culprits.
While many of the suggestions are useful and could help with tracking down or reducing problems, I think the real solution is to build something into the core system which can figure out an attack and then stop it. That, of course, is much easier to say than to do.
October 11th, 2006 at 9:22 AM
Firelight – If there were verified scripters, the whole point would be understanding the seriousness of using the restricted instructions.
If a verified scripter is given a griefing script by someone and recompiles and runs it without looking at it, they’re out forever. LL should make sure that fact is publicized so all other verified scripters understand what this is about.
If you aren’t a verified scripter and the script you are recompiling and saving has the restricted instructions in it, it will fail.
Scripts aren’t very big, the 16K limit ensures that, it’s not like you’re running Ant on 150 modules to do a clean build.
October 11th, 2006 at 10:08 AM
None of this was caused by accident or script errors or someone moding a “harmless” script. Lets get this straight righ out front. It was a dedicated attack by someone who wanted to destroy or hurt us. Not just LL, us! You and I. This place may run on LL’s machines, but it is our world. And the person(s) who did it are different than the terrorists who attact us in 1L. And like those attacks, if we make it overly difficult or impossible to do things we used to do by giving up give up scripting tools, etc. (read freedoms) in the name of protection. They win.
Script restrictions, verifed script approvers, taking away some of the functions, all do one thing, hurt the responsible individual, and do nothing to stop those that intend harm. I’m sorry, but I still believe that the quickest way to put a dent in griefing is to go back to verification of the people using the system. It won’t stop someone who is truly bent on wrecking havoc on us, nothing will. Just ask Microsoft. But it will slow down the more casual greifer as there will again be consiquences. If you can find me and take me off the grid forever, it might just make me think before I do something dumb or as a lark. And at least I can only do it once.
Since all the publicity has come out about SL, and the free unverfied accounts have come into play, I have seen a dramatic increase in the level of griefing and harrassment, especially the more casual types. Why would that be so, jeolousy and no consiquences!
Right now, LL only really has to deal with the big probs like goo or the party hats, but we have to deal with the disturbances caused by griefing every day. So, if you believe as I do that the unverified accountents are a big piece of all this, I have a suggestion. Make the everyday griefing we have to contend with LLs problem.
Write the darn reports. Running nude in a pg sim, report ‘em. Pushing, report ‘em. Invading your land, report ‘em. Weapons in a no weapons, report ‘em. Get the idea? File enough reports and LL will have to something to stem the flow of the reports themselves.
Just a thought. But hey, what do I know, I’m real am I ?
October 11th, 2006 at 10:47 AM
As I posted on the forum, another advantage to embedding the scripter id in the code would be that in the event of an attack, the id could be extracted from one of the objects, then all the servers given that id and any script with that id would be prevented from running.
This would be a very quick way to stop an attack in it’s tracks. Once things calmed down, all the dangerous scripts by that scripter could be disabled and/or removed from SL.
October 11th, 2006 at 1:44 PM
I think what would help is better land controls personally. Imagine if you could set your land to only allow people to rez objects on your land if they are on a list. What if we had a setting where it wouldn’t let any objects enter our parcels whos owners weren’t on that list. I think the root of the problem is that objects don’t have the same restrictions avatars do, and they should. An object can move onto a property that you may be restricted to. Why was this allowed? My objects should have the same restrictions my avatar has. Sure you can set up an auto-return, but that doesn’t stop attacks on your land. Just a thought.
March 25th, 2008 at 5:19 AM
hypanthial cysticercoidal hop boviform reload pseudoindependent cymographic callistephus
Barak
http://www.maureendawson.com
日本語
April 17th, 2008 at 5:55 PM
hypanthial cysticercoidal hop boviform reload pseudoindependent cymographic callistephus
Marlborough Military Models
http://www.warmplastic.com
日本語