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

[Tigro Spottystripes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I do install and run programs i don't trust in a sandbox in my computer,
and i think people are wanting much more than just client-side LSL
scripts...

On 17/3/2010 14:31, Dzonatas Sol wrote:
> You install a program on your computer, and you either trust it or you 
> don't. It comes down to that, so it doesn't matter if it is .NET or Java 
> or some binary made by company XYZZY.
> 
> What some people want is to separate a way to run a sandbox version of 
> their LSL code on the client-side, which is a bit different than the big 
> picture of client-side scripting in any program language.
> 
> 
> Erik Anderson wrote:
>> Not to mention that .NET does not have an uncontroversial licensing 
>> arrangement, with many lawyers not able to figure out whether or not 
>> most linux distributions are in technical violation...
>>
>> On Wed, Mar 17, 2010 at 9:51 AM, Argent Stonecutter 
>> <secret.argent at gmail.com <mailto:secret.argent at gmail.com>> wrote:
>>
>>     > I don't follow you here. What I read in the above was a combination
>>     > of a well defined client side extension API and a mechanism to load
>>     > code that can be granted a level of trust based on criteria it needs
>>     > to do its job. �That might include code signing and metadata about
>>     > the capabilities the client plugin needs. I don't see any mention of
>>     > "untrusted binaries" other than the implication that a module that
>>     > doesn't negotiate additional capabilities gets started in a
>>     > sandboxed environment with minimal capabilities.
>>     >
>>     Any code not explicitly installed by the user is "untrusted".
>>     Executing untrusted code in a sandbox is an extremely difficult
>>     operation to perform safely. Doing so in a way that also accepts
>>     "trusted" code through the same mechanism is something that even
>>     Microsoft has notoriously failed to successfully pull off... a good
>>     number of the exploits of the late '90s and early '00s were due to
>>     failures of this security model.
>>
>>     Doing this securely enough to ship is an extremely difficult
>>     undertaking, ranking alongside the whole of Second Life in ambition
>>     and scope, and not doing it securely could destroy Second Life.
>>
>>     I would not use nor recommend using any viewer that implemented it.
>>
>>     _______________________________________________
>>     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
> 
> _______________________________________________
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuhfu8ACgkQ8ZFfSrFHsmVIjACdHy/ughz1ZKM4EUMA1VOXy6dH
pAgAoI22HKSwvYpXppWg6tefol72L9np
=jloj
-----END PGP SIGNATURE-----