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

[Morgaine]

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/789fac2c/attachment.htm