We can, for example, easily say that we don't trust your LSL code from your sim to run in my sim. No difference.
Some suggest the script must be "in the clear" (as in not compiled). Ok, I argued for that last year, yet here is agruments against it? Or, people want binaries? Or, people really don't understand this whole enigma now. (Or, people just take sides to just to take sides and to argue just to argue. *rollseyes*) Given the example of the sim to sim situation of rather if the script should be transferred by human readable code or binary... start there. Think of the sim as the sandbox. Then... move that sandbox to the client-side. Just got to put it in the obvious viewpoint. OpenSim thinks firefly is a trollish topic. Go figure! Jesse Barnett wrote: > Sorry but I have to agree with Argent on this one. > > I use a sandbox all of the time for testing code and programs. > > The whole point of and inherent safety in a sandbox is that everything > is contained within. If any code is allowed to interact with anything > outside of the sandbox then it is NOT a sandbox. > > Jesse Barnett > > On Wed, Mar 17, 2010 at 5:46 PM, Argent Stonecutter > <secret.arg...@gmail.com <mailto:secret.arg...@gmail.com>> wrote: > > On 2010-03-17, at 16:55, Dzonatas Sol wrote: > > Somewhere along the line Argent, you trusted to install the SL > > binary and its "badly behaved code can compromise you." > > The SL binary does not contain a mechanism to automatically download > and execute untrusted code from in-world content. > > > 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. > > Adding the ability to download and execute untrusted code from in- > world content is a significant decrease in security. > > > 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. > > > I have been dealing with such security models professionally since the > '90s. They are inherently hazardous. They have been used as the basis > of far too many compromises to consider trusting them. > _______________________________________________ > 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 > > _______________________________________________ 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
