Gray Goo vs. Family ID vs. Permissions
|
|
Tuach Noh
Ignorant Knowlessman
Join date: 2 Aug 2006
Posts: 79
|
09-18-2006 21:01
Some neighbors and I were having a discussion about why a two-year old resident with hundreds of positive ratings would have been griefing with gray goo.
Then I realized what probably happened. Early on in the attack on our sim, the objects tried to give my partner and I copies of themselves. Had I rezzed one to see what the fork it was, I'm confident it would have started replicating anew with my name all over it. Ick! (I realize most of you already probably knew this.)
I know that part of the gray goo wall is the family id. This seems like an attempt to get around that wall by "changing owners."
Would it be a big deal if llRezObject() and llRezAtRoot() required PERMISSION_REZ_OBJECT against the object owner before being allowed to work?
This would break a lot of existing rez scripts, I'm sure, but they would be easy to fix, and forcing the would be griefer to click to grant permissions once per object would pretty much eliminate gray goo. Allowing me to kill "surprise rezzes" from an object I rez out of inventory would also be a nice line of defense.
This wouldn't be a big deal for your favorite 300-bullet-per-second gun, because it would only need to request permission once. It would be a bigger problem for guns that rez bullets that rez explosions/shrapnel. People who use "auto builders" that self-replicate a couple of times would have to click a couple of times, but that's hardly the end of the world.
So maybe if there was a "generation" counter (which I think might already exist), and if an object is 3rd or successive generation since being rez'd from inventory, it needs PERMISSION_REZ_DEEP or something; that would still kill off gray goo and would probably avoid implications for most legitimate uses for the rez functions.
Bad idea? Or just plain stupid?
|
|
Aakanaar LaSalle
Registered User
Join date: 1 Sep 2006
Posts: 132
|
09-18-2006 21:15
Like the idea, but there are definately problems to it..
Holovenders or many of the 0 prim rezzers (rezzing temp_on_rez objects to avoid prim count for legit reasons) would definately break.
Perhaps there might be some kind of middleground?
maybe when you rez and object it has to ask permission to rez any other objects. Once given that permission stays with that object untill reset or taken into inventory?
Even that has it's share of problems.
|
|
Bosozoku Kato
insurrectionist midget
Join date: 16 Jun 2003
Posts: 452
|
09-19-2006 04:23
I agree, there'd be some potentially serious issues with a PERMISSION_REZOBJECT perm. You're post about the object giving itself to you definitely is a probable method used to hide the identity of the malicious person(s), and your idea for a rez permission would help save oneself from rez'n on_rez(). But it would definitely bork most, if not all, legitimate rez routines (example: even once granted, permissions occasionally fail and get lost requiring the owner to reboot the device or otherwise get permissions again). It'd seriously hose complicated rez heavy works. So, overall, I'd like to not see a rez permission. From: Tuach Noh I know that part of the gray goo wall is the family id. This seems like an attempt to get around that wall by "changing owners." Today I discovered a method that can completely mask the creator/owner of an object and all it's contents (malicious object/contents). I've sent my theory (more like fact, because I made a self-replicating toy tonight with zero traces to the actual creator for any part of the device (prims/contents, contents of contents, etc..)).. anywho, emailed LL about it.
_____________________
float llGetAFreakingRealTimeStampSince00:00:00Jan11970();
|
|
Angel Fluffy
Very Helpful
Join date: 3 Mar 2006
Posts: 810
|
09-19-2006 05:50
From: Bosozoku Kato I agree, there'd be some potentially serious issues with a PERMISSION_REZOBJECT perm.
You're post about the object giving itself to you definitely is a probable method used to hide the identity of the malicious person(s), and your idea for a rez permission would help save oneself from rez'n on_rez(). But it would definitely bork most, if not all, legitimate rez routines (example: even once granted, permissions occasionally fail and get lost requiring the owner to reboot the device or otherwise get permissions again). It'd seriously hose complicated rez heavy works. So, overall, I'd like to not see a rez permission.
Today I discovered a method that can completely mask the creator/owner of an object and all it's contents (malicious object/contents). I've sent my theory (more like fact, because I made a self-replicating toy tonight with zero traces to the actual creator for any part of the device (prims/contents, contents of contents, etc..)).. anywho, emailed LL about it. You might want to email Brent about that. It sounds like an exploit to me - one that removes accountability that's meant to be in the system.
_____________________
Volunteer Portal (FAQs!) : https://wiki.secondlife.com/wiki/Volunteer_Portal
JIRA / Issue Tracker : http://jira.secondlife.com (& http://tinyurl.com/2jropp)
|
|
Bosozoku Kato
insurrectionist midget
Join date: 16 Jun 2003
Posts: 452
|
09-19-2006 06:09
From: Angel Fluffy You might want to email Brent about that. It sounds like an exploit to me - one that removes accountability that's meant to be in the system. You're the second person to suggest that. Problem is, I'm not privie to knowing any Linden's emails (I'm a hermit, super hermit, my Linden fan club consists of...[]). The only emails I could find, other than [email]support@secondlife.com[/email], which I used, was a 3 item list on the "Contacts" page (billing, technical, and umm something else totally useless).
_____________________
float llGetAFreakingRealTimeStampSince00:00:00Jan11970();
|
|
Ordinal Malaprop
really very ordinary
Join date: 9 Sep 2005
Posts: 4,607
|
09-19-2006 06:12
Bug report it and check "exploit".
|
|
Jesse Malthus
OMG HAX!
Join date: 21 Apr 2006
Posts: 649
|
09-19-2006 06:25
From: Ordinal Malaprop Bug report it and check "exploit". Agreed. Also, [email]lindenname@lindenlab.com[/email] should work for getting in touch with a specific Linden.
_____________________
Ruby loves me like Japanese Jesus. Did Jesus ever go back and clean up those footprints he left? Beach Authority had to spend precious manpower. Japanese Jesus, where are you? Pragmatic!
|
|
Rich Cordeaux
Registered User
Join date: 8 May 2006
Posts: 26
|
09-21-2006 14:08
I think a better fix would be allowing people to view scripts in free-to-copy or $0 objects without having to copy/buy and re-rez them, and/or, allowing people to open objects in their inventory to see what's inside.
Then you wouldn't have (as many) people rezzing things out of curiousity and then going "OH SNAP A REPLICATOR!"
|
|
Tuach Noh
Ignorant Knowlessman
Join date: 2 Aug 2006
Posts: 79
|
09-22-2006 16:46
From: Rich Cordeaux I think a better fix would be allowing people to view scripts in free-to-copy or $0 objects without having to copy/buy and re-rez them, Well, if the script is no modify, that won't work. From: someone and/or, allowing people to open objects in their inventory to see what's inside. Yes, that would be really great. Perhaps also a "scripts enabled" checkbox on an inventory object's "Inventory Item Properties" floater so you can disable them and then rez it to satisfy your curiosity without destroying the world. This functionality already exists on the Tools menu, it just doesn't work on inventory items. So it ought to be possible.
|
|
Sera Rawley
Registered User
Join date: 7 Apr 2006
Posts: 9
|
09-22-2006 20:11
PERMISSION_REZ_OBJECT would be a disaster for artificial life. The fence gives us enough problems. Simple rule of thumb is if you don't know the source don't rez the object if it's given by an object be very suspicious. If you must rez that unknown object go to a no script area.
|