[opensource-dev] Known details of LL 'Firefly' client-side scripting

Dzonatas Sol dzonatas at gmail.com
Wed Mar 17 14:55:11 PDT 2010


Argent Stonecutter wrote:
> On 2010-03-17, at 16:06, Dzonatas Sol wrote:
>> This is why I pointed to the sandbox model with the tried and proven 
>> virtualization means of linux emulation as an example. One can easily 
>> allow untrusted code to execute natively in the linux emulation.
>
> No you can't. Even in a virtual machine, badly behaved code can 
> compromise you. If you allow it access to resources in Second Life, it 
> can attack those resources. If you allow it to interact with your view 
> of the world, it can substitute elements displayed in that view. If 
> you allow it to make network connections, it can take part in a 
> botnet. If you run other code in that sandbox (other untrusted code 
> from a different source) it can compromise that. If you create a 
> separate VM for each piece of code, then the overhead of your 
> sandboxes becomes unmanageable. You can't just say "it's in a sandbox".
>
>> Let's say BLIZZARD decided to release a software download inside of 
>> SL. You can use L$ to buy your next game of BLIZZARD directly inside SL.
>
> If that involves downloading a file to disk and explicitly making a 
> deliberate decision to open and install that file, fine. If it 
> involves a scripted vendor being able to download and install native 
> code through an API in some sandbox in the viewer, no, that would be 
> bad. Because if BLIZZARD can use that API, then so can the PN and 
> W-Hat and SomethingAwful.
>

What you said above has completely shown discriminatory social 
engineering of who to trust. It doesn't matter, like I said, the level 
of abstraction, and you reiterated that on your own level of your own 
viewpoint. You proved your argument against my points as completely moot.

My point is to minimize the levels of abstraction and see it from that 
viewpoint without the abstraction turtles.

If you still don't understand this, then compare a sandbox, any sandbox 
model of trusted/untrusted code, to a virtual machine. For some reason, 
you either think it is complex or you wanted to make it more complex 
than that.

Somewhere along the line Argent, you trusted to install the SL binary 
and its "badly behaved code can compromise you." Don't complain to me 
and others that want to improve user security. It seems like you want to 
parade about *spooky* ideas as if we want to make it worse.

No we don't want to make it worse. Again, re-read the threads from a 
half-year to a year ago about methods to secure and trust these scripts, 
like how to "sign-off" on them, and how to take advantage of security 
models.


More information about the opensource-dev mailing list