[opensource-dev] The Faces Of Client-Side Code

[Ricky]

I agree 100%.  Yet, as this topic is about the different faces of client
code, having the terms well-defined will help in the future.  We are both
agreed that there are sandboxed and non-sandboxed parts, and each has it's
purpose.  I just wanted to establish common terms, with some generic
examples, so that we can further discuss how to implement each piece in
another topic.

But on the topic of sandboxing, I believe that some local storage could be
allowed and still have a sandbox.  The plugin implementor would create a
special file in the profile directory that creates a virtual filesystem that
has constraints such as limited total size and limited I/O per unit time,
and would then limit all file I/O calls to it.  But that is plugin design,
which is orthogonal to what I believe the next discussion should be of how
to design the plugin system.

I'll post in just a few on that topic.  I like how this discussion has
progressed.

Ricky

On Sun, Mar 7, 2010 at 12:16 PM, Morgaine <morgaine.dinova at googlemail.com>wrote:

> User perceptions are completely orthogonal to the engineering issues here
> though, Ricky.  We could certainly make all use cases look entirely uniform
> from a user perspective if we wanted to, but we don't advocate that because
> the security and responsibility issues are so different in the two (and only
> two) cases.
>
> This is why we separate this area into wholly sandboxed and wholly
> non-sandboxed parts.
>
> The non-sandboxed "viewer extensions" are always "run at your own risk".
> They are acknowledged to be inherently dangerous because they are powerful,
> just like every other native platform executable.  You bear the full and
> explicit responsibility of deciding whether to trust them or not when you
> install them or accept them, and this applies regardless of how
> transparently they arrived and/or are installed (eg. Firefox add-ons are
> fairly transparent).  And just as with any other executable that you
> download off the net and choose to execute, if the program sells your spouse
> and kids into slavery and exchanges your house for 500 Britney Spears
> albums, the responsibility for having misplaced your trust is yours and
> nobody else's.
>
> In contrast, sandboxed programs would implement "world extensions" within
> the viewer without needing to touch local PC facilities.  Because they don't
> need local access they can easily be sandboxed with a good degree of
> confidence in the strength of the sandbox walls, *bugs and exploits
> excepted*.  To some extent (but not fully), this means that trust in
> sandboxed code can be assigned automatically by those who do not possess a
> well developed sense of risk and of program frailty, nor an awareness of
> programmer fallibility and human malevolence.  It also means that if the
> designers of the sandbox imply that it is strong and that your trust can be
> given automatically to sandboxed scripts, then you might well have recourse
> against them when your 500 Britney Spears albums arrive.
>
> In practice, these two categories are hugely different in human impact,
> even if implemented using common infrastructure plus an optional sandbox.
> Of course it's possible to find subclasses within each of them and it's
> possible to find commonality between them, but this serves little purpose,
> and if it obscures the risk differences then it becomes highly dangerous.
>
>
> Morgaine.
>
>
>
>
> =======================================
>
> On Sun, Mar 7, 2010 at 5:09 PM, Ricky <kf6kjg at gmail.com> wrote:
>
>> Carlo, both you and Morgain make very good arguments as to why various
>> parts I separated are, technically, the same.  However, while I understand
>> that Dynamic Scripts (loaded from serverside) and UserScripts are completely
>> the same thing (just like in a browser, the JavaScript loaded from
>> the server-side alongside the web page, and GreaseMonkey UserScripts are
>> both just seperate views of the same thing,)  they are made distinct in
>> the terminology here due to the fact that a user will see a difference.
>>
>> I also understand how you would see the Extensions and Plugins as also
>> being nothing but the same thing.  Setting up an IPC layer in the C++ is
>> absolutely required, but I don't think that we need to put /multiple/ ways
>> of connecting plugins into the code hooks.  I'd prefer the most direct
>> method of using a form of dynamically loaded shared library that implements
>> a common object Interface that the client then calls.  This provides the
>> most direct, most capable interface.  It is also not very abstract, as the
>> underlying code could easily change in such a way as to break the interface,
>> but that is a common enough problem for any of the plugin designs I've met
>> with.  As I mentioned before, one of the first of these plugins could easily
>> be one that exposes a socket based interface for a more abstracted system, a
>> la Morgaine's design.
>>
>> Note that while most users may not explicitly notice a difference between
>> Plugins and Extensions, as they can easily blur use-cases, they are hugely
>> different in the back-end.  Consider Plugins to be ways of writing a "patch"
>> that provides a new feature to the client.  Extensions could do the same,
>> but are out on a distinct abstraction layer provided by a variety of
>> plugins.
>>
>> For Dynamic scripts and UserScripts users will see a distinct boundary,
>> even though there is no such boundary in the back-end.  One is for the
>> server-side coder to do things to my client, while the other is a way for me
>> to easily do things to my client.  Again, these can be provided by various
>> plugins/extensions.
>>
>> And while I put no sandbox restriction upon the Plugins, that shouldn't be
>> considered to mean that the plugin designer couldn't decide to sandbox their
>> own code.  I'd love to see the Shared Media re-factored into a plugin that
>> provides a sandboxed environment for connecting to and displaying the media.
>>
>> One big point there is that with these different layers of capability,
>> there could exist a free market of competing Plugins, competing Extensions,
>> Dynamic scripts providing more engaging interaction while reducing server
>> load, and easy customizability with UserScripts.  Each has its purpose, and
>> each has its userbase.  I know my dad, who is a fairly good scripter, would
>> not be interested in writing a plugin or extension, but would love to be
>> able to write dynamic client scripts.  I'd love to have the opportunity to
>> dig as deep as I'd like in the code, but to be able to start in a much
>> cleaner environment, such as implementing a plugin, or even easier, an
>> extension. They would be much cleaner to build than a patch, and easier
>> to distribute!
>>
>> Ricky
>>
>> On Sun, Mar 7, 2010 at 6:20 AM, Carlo Wood <carlo at alinoe.com> wrote:
>>
>>> On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote:
>>> > Client Plugins
>>>
>>> Ok, although I'd prefer if-- for example-- media plugins run in a
>>> sandbox;
>>> think about the recent mention of the quicktime exploit.
>>>
>>> > Client Extensions - Interpreted code packages placed in a special
>>> folder in the
>>> > client directory by the user/admin of the client's installation.
>>> >   These should run in a broad sandbox: Limited local disk access (max
>>> datastore
>>> > size, etc.) to a special file in the local user folder. Eg:
>>> ~/.secondlife/
>>> > slfirst_lastname/extensions/extensionname.eds  (Extension DataStore)
>>> But can
>>> > still access much the same client hooks as the Plugins.
>>> > Provides fast prototyping, and lower entry difficulty, than Plugins,
>>> but will
>>> > most likely not have the freedom to tap into a lot of system stuff.
>>>  Also will
>>> > not typically run as fast or in as little memory space as the binary
>>> plugins.
>>>
>>> > Dynamic Client Scripts - Interpreted scripts loaded from the server via
>>> the
>>> > server-side permissions system.
>>>
>>> Since this and Client Extensions are both interpreted code, these are
>>> basically the same-- just with different permissions. I don't think we
>>> should at this point make a difference between scripts based on their
>>> source or permissions, but only based on their implementation layer.
>>>
>>> >   May still need a better name...
>>> >   Could be stored in Notecards and a server-side script could petition,
>>> via
>>> > llRequestPermissions, to be able to request that the client download
>>> the
>>> > notecard named via a llLoadClientScript(string name, integer channel)
>>> or
>>> > similar command. The notecard would then be downloaded by the client
>>> and the
>>> > plugins/extensions that had registered as able to interpret scripts
>>> would then
>>> > be queried as to their ability to understand the code, and the one that
>>> > answered with the most certainty could be given the task.  Some sort of
>>> > first-line header in the notecard would help this process along.
>>>
>>> This deals with where the code comes from, not how it runs.
>>>
>>> > Executed within TIGHT sandboxing: Limited, or no access to local disk
>>> > storage, and limited to tasks such as drawing on the HUD layer of the
>>> GUI,
>>> > creating floaters to draw in, communicating back to the world via the
>>> > predefined channel number, etc.  The limits are, of course, up to the
>>> plugin/
>>> > extension maker.  Another potential limit would be the automatic
>>> unloading of
>>> > the script when the host object is out of range, or is no longer
>>> attached.  Of
>>> > course the Plugin maker could decide when, or if, the user should be
>>> asked
>>> > before loading the script, even if the server-side has given its
>>> permission.
>>>
>>> In other words, Client Extensions-- but with more restrictions (less
>>> permissions).
>>>
>>> ...
>>> > UserScripts (Term borrowed from GreaseMonkey) - Interpreted scripts
>>> loaded
>>> > dynamically into the client by the user.
>>> >   Function just like Dynamic Client Scripts, except the source is the
>>> user
>>> > themselves opening a local text file, or opening a console window and
>>> typing
>>> > commands.
>>> >   Provides local quick changes, and even personal
>>> never-touched-the-server HUD
>>> > objects, floaters, etc.  Lowest entry difficulty of the whole set of
>>> ideas.
>>>
>>> The implementation of this is still the same, just even less permissions.
>>> No?
>>>
>>> In terms of layers (one thing build ON TOP of another), we have, imho:
>>>
>>> SNOW-553 (C++ hooks; LLStateMachine)
>>>  |
>>>  V
>>> Inter Process Communication (IPC) support (C++; sockets; serialization)
>>>  |
>>>  V
>>> Plugins
>>>  |
>>>  V
>>> Client Extensions (including Dynamic Client Scripts, User Scripts etc).
>>>
>>> --
>>> Carlo Wood <carlo at alinoe.com>
>>>
>>
>>
>> _______________________________________________
>> 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/20100307/833d4105/attachment.htm