[opensource-dev] Client-side scripting in Snowglobe

Morgaine morgaine.dinova at googlemail.com
Fri Feb 19 05:30:28 PST 2010


Ricky, I agree with you, there are indeed two different requirements being
discussed here, and confusing them as a single requirement can never yield a
satisfactory result.  Indeed, Dahlia and I were discussing that same thing
yesterday, here<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000109.html>and
here<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000116.html>
.

I would avoid your terminology though, because both kinds of script
application employ "client-side scripting", both types create dynamic
"extensions",  and both types can be implemented as "plugins" --- your terms
directly describe the technologies that can be used in both types of
application and don't distinguish between the two differing requirements.
It would just add to the confusion.

Instead, let's call them what they are:  TRUSTED APPS, and UNTRUSTED APPS.

(We can happily replace "apps/applications" with "scripts", "programs",
"extensions", "plugins", "code", and many other words, while still retaining
exactly the desired meaning and intent --- the key differentiator is
"trusted" versus "untrusted".)

The big problem we have here at the moment though is that *apparently*,
Lindens want to support *untrusted* apps ONLY, as evidenced by the mandatory
sandbox and mandatory use of Mono.  If so, this inherently means that all
the myriad uses of *trusted* client-side scripting (many more of them than
untrusted) are left out in the cold.  LL is refusing to even discuss this
twofold requirement with us, it seems, although Q may well reconsider and
rejoin the discussion here today.  I hope so, because yesterday's response
indicated no desire to cooperate with the mailing list on this, which would
be a disaster for all.

It is very unfortunate that we have to guess at Linden's intentions in this
area instead of being able to work openly with them on requirements and core
design.  I am still hopeful though.  Lindens have committed to working with
the community on the open source client, and unless that happens visibly and
honestly, community support is going to evaporate and move to other
clients.  They probably realize this, so I'm hopeful that openness will
prevail at LL.

The present issue is a test of this, and a massively important test because
client-side scripting (of both types) is such an empowering tool for the
open source community.  We *need* that open cooperation, just as the company
needs it, so fingers crossed.

(I miss Rob massively!  A champion for open source at the Lab is so badly
needed.)


Morgaine.





=========================================

On Fri, Feb 19, 2010 at 7:16 AM, Ricky <kf6kjg at gmail.com> wrote:

> I suspect that there are two things being discussed here without
> distinction: Client scripting, and client extensions.  Confusing the two is
> easy.
>
> Client-side scripting SHOULD be sandboxed, and in a controlled set of
> languages.  For a close example think of javascript in web browsers.
>
> Client extensions, or alternatively named as "plugins", would be modules
> that can be plugged in and out of the client and run /as if/ they were a
> part of the client.  Think of browser add-ons/plugins/extensions.
>
> Client side scripts could (read might be, could possibly, needs further
> thought, etc.) be given permission to be loaded in by worn items
> automatically.  Other objects would likely need to request permission via a
> security warning.
>
> Client extensions would have to be downloaded and installed externally; not
> delivered in-world.  These would truly be programs on your computer, and
> should be treated as such.
>
> Just my thoughts hoping for a clearer discussion.
>
> Ricky
> Cron Stardust
>
> On Thu, Feb 18, 2010 at 2:27 PM, Morgaine <morgaine.dinova at googlemail.com>wrote:
>
>> On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble <dahliatrimble at gmail.com>wrote:
>>
>>> To me, an environment such as SL or the web in general tend to attract a
>>> few malicious developers, or more so, companies and individuals who are
>>> interested in collecting personal data and usage patterns. I'd prefer some
>>> level of control over what they can access without needing to understand the
>>> source code of any scripted extensions (if indeed source was available).
>>>
>>>
>> Dahlia, I agree with part of that, to the extent where it applies:
>>
>> The "malicious users" argument presupposes that scripts come from 3rd
>> parties, some of whom are malicious.  When people write their own scripts,
>> which is very common in this opensource-dev community, they are not
>> malicious 3rd parties, and they do not generally want to be treated as such.
>>
>> Quite the opposite, they want all the power that scripting on their local
>> platform can give them.  Therefore the "malicious users" argument applies
>> only to a subset of scripts, the downloaded ones, and it is perfectly valid
>> there.  However, it does not apply to one's own scripts, nor to any other
>> power-users' scripts that one wishes to trust.
>>
>> This leads directly to a rather fundamental requirement:  the sandbox must
>> be optional, applying only to the use case of unknown downloaded scripts,
>> and not applying when the user wishes her scripts to be used as an interface
>> to local facilities.
>>
>> It is considerations such as this that Lindens should be exploring
>> together with the community here, because it impacts on the future of
>> Snowglobe directly and in a colossal way.  We are all affected.  Designing
>> this behind closed doors is not adequate, nor is it appropriate in an open
>> source community viewer.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> ==========================================
>>
>>
>> On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble <dahliatrimble at gmail.com>wrote:
>>
>>> I haven't been following this topic in any office hours so I hope my
>>> comments aren't too off base.
>>>
>>> Personally I'd prefer to be able to run extensions as sandboxed, and
>>> maybe have the option of running them unprotected on a per-extension basis.
>>> To me, an environment such as SL or the web in general tend to attract a few
>>> malicious developers, or more so, companies and individuals who are
>>> interested in collecting personal data and usage patterns. I'd prefer some
>>> level of control over what they can access without needing to understand the
>>> source code of any scripted extensions (if indeed source was available).
>>>
>>> Concerning Morgaine's list: while I may not fully agree with reasons 1-4,
>>> they appear to reflect valid concerns and are presented in a agreeable
>>> manner. Reasons 5 and 6 seem to imply political overtones to me, and I
>>> suspect any platform choice will carry some political burden with it.
>>> Personally I believe mono to be a reasonable choice for a scripting
>>> environment, especially given LL's experience with it in their servers.
>>>
>>> And now since I don't contribute to the LL viewer source, I'll shut up :)
>>>
>>> -d
>>>
>>>
>>> On Thu, Feb 18, 2010 at 4:57 AM, Morgaine <
>>> morgaine.dinova at googlemail.com> wrote:
>>>
>>>> A line got lost from my post owing to finger trouble.  Item 6 about Mono
>>>> should have read:
>>>>
>>>>
>>>> 6. Some parties identify other reasons for avoiding Mono in general.
>>>>  Without getting into that subject at all, requiring Mono for client-side
>>>> scripting would make scripting unavailable to that portion of the user
>>>> base.  Since client-side scripting without Mono is perfectly feasible, Mono
>>>> should not be made mandatory for scripting, so that the widest user base can
>>>> be supported.
>>>>
>>>>
>>>> Morgaine.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ========================
>>>>
>>>>
>>>> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine <
>>>> morgaine.dinova at googlemail.com> wrote:
>>>>
>>>>> I referred recently to Linden's internal project "Firefly" to add
>>>>> client-side scripting to SL viewers.  This has been the topic of open
>>>>> discussion at several Office Hours with Lindens in SL, but that openness has
>>>>> not extended to many design details --- the Firefly design process is not
>>>>> open to the community.  The only technical details that are being disclosed
>>>>> about Firefly appear to be:
>>>>>
>>>>>
>>>>>    - "Scripts" are actually *Mono assemblies*, so that only languages
>>>>>    that compile to Mono will be allowed.
>>>>>    - The programs run in a *sandbox*, which means that most platform
>>>>>    resources are not accessible to them.
>>>>>
>>>>>
>>>>> Please note that I quite like C# as a language, but the following
>>>>> remarks are about Mono use *in the SL viewer*, only, where its
>>>>> tradeoffs are poor.
>>>>>
>>>>> The first known detail about Firefly (mandatory Mono) is problematic on
>>>>> several fronts:
>>>>>
>>>>>    1. Only a tiny fraction of the world's applications, libraries and
>>>>>    languages work on Mono, so client-side scripting will be unable to benefit
>>>>>    from the huge mountain of resources available on the Internet.  This is an
>>>>>    extremely severe limitation, and an unnecessary restriction in the context
>>>>>    of client-side viewer scripting.  If I want to use a locally-installed
>>>>>    package X from within my client-side script, I should be able to.  What runs
>>>>>    client-side should always be our individual choice, not someone else's.
>>>>>    2. Programmers want to write client-side scripts in the language
>>>>>    that they know best, because that always yields the fastest progress and
>>>>>    highest quality results.  There was a good technical reason for forcing
>>>>>    everyone to use LSL server-side, but there is no technical reason to impose
>>>>>    this requirement on all client-side scripting.  It is counter-productive to
>>>>>    force CLR compatibility on client-side script developers when there is a
>>>>>    simple alternative:  define a *socket-based viewer API* for
>>>>>    client-side scripts instead, hence usable from any language.
>>>>>    3. Mono runs poorly on Linux, so from being rock-solid on Linux
>>>>>    now, the LL-derived viewers will become second-rate on this platform.
>>>>>    4. The viewer is already extremely bloated and a memory hog.
>>>>>     Adding a Mono dependency will compound that horribly.
>>>>>    5. There is only one effective supplier of Mono:  Novell.  That is
>>>>>    a very bad situation to encourage and to support in the viewer.
>>>>>    6. Some parties identify other reasons for avoiding Mono in
>>>>>    general.  Without getting into that subject at all,
>>>>>
>>>>>
>>>>> The second known detail about Firefly (mandatory sandbox) is
>>>>> problematic on two related fronts:
>>>>>
>>>>>    1. Sandboxes by design do not allow most platform resources to be
>>>>>    accessed, as a security measure.  This is fine and important when scripts
>>>>>    are being downloaded from unknown places (like Javascript in web pages), but
>>>>>    that same protection also means that client-side scripts would be powerless
>>>>>    to do useful things for us in concert with local applications, files,
>>>>>    devices, etc.  Sandboxing client-side scripts effectively hardwires in
>>>>>    script weakness for no reason discussed as a requirement.
>>>>>    2. Sandboxed applications cannot be linked with user-chosen native
>>>>>    libraries since allowing native code breaks sandbox protection.  This means
>>>>>    no accelerators, no extensions, and no interop with other systems since
>>>>>    sockets are inaccessible from any strong sandbox.  This also means no
>>>>>    evolution or progress outside of what the sandbox designers permit.
>>>>>
>>>>>
>>>>> This mailing list is concerned with development of open source viewers,
>>>>> in particular Snowglobe.  This is heralded as a *community* viewer,
>>>>> embodying *community* requirements much more directly than the LL
>>>>> mainstream viewer.  Client-side scripting will impact on every single aspect
>>>>> of Snowglobe bar none, yet the community is being excluded from the design
>>>>> of its most powerful infrastructure element.  This is entirely wrong, far
>>>>> beyond the normal observation that secrecy in design has no place in open
>>>>> source.
>>>>>
>>>>> It is hard to assess things technically when the design requirements
>>>>> are formulated in secret.  The Snowglobe community has design requirements
>>>>> too.  Those deserve to be examined here openly, not limiting Snowglobe to a
>>>>> design that stems from Linden requirements alone.
>>>>>
>>>>>
>>>>> Morgaine.
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/03e804e9/attachment-0001.htm 


More information about the opensource-dev mailing list