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.din...@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 <kf6...@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 <ca...@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 <ca...@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 >> > >
_______________________________________________ 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
