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

Dzonatas Sol dzonatas at gmail.com
Wed Mar 17 10:31:01 PDT 2010


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



More information about the opensource-dev mailing list