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. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
