Plugin architecture

Survey Of Client Plugins As Potential Models

• Old Netscape Plugin

Wiki Link [1]

• New Mozilla Extensions

XUL Framework, challenging to build. Wiki Link [2]

• Browser Helper Object in IE

Wiki Link [3]

• Eclipse Plug In Model

Java callbacks and contracts. [4]

Required Changes

Some changes in the code will be required to support plugins.

• Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
• Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
• Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
• Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.

Plugin <--> LSL Communication Channels

Many compelling applications would benefit from a pipe between the plugin process and server side LSL scripts. Anything which wants to communicate status or information which can only be gathered reliably via LSL rather than typical protocol messages the client receives would benefit from such a pipe.

A brief discussion on the alternatives for communication follows:

• Ideally, this pipe could be written differently from the current chat channels afforded by llSay or Instant Message, to avoid performance and size limitations. However, an early implementation using available technologies would be preferable to one which may take significantly longer.

• A chat channel implementation would require the ability for an avatar to have his client register a listener with the servers on channels other than channel 0. The client would not display messages on channels other than 0, but would send them to any plugins which have been registered to listen on those channels.

• Another implementation, using instant messages, would be useful for the added privacy, however time lag between messages are significant and it would be desirable not to have these messages show up on the client itself so a flag would need to be added for plugin-only instant messages.

• Other ideas, such as HTTP requests or Emails, for external plugin communication should be discarded quickly for the very reason that most systems now have significant firewalls and NAT'd connections which will deny such communication channels immediately.

Security Model

An oft heard complaint about the Internet is the lack of security. The ease with which hackers can install Trojan horses and develop sophisticated bot nets to do their willing is becoming a modern nightmare in technology today.

One approach to fixing this problem, or at least, reverse it in its tracks is "Trusted Computing" ([5]). While Second Life isn't pure Trusted Computing because you are installing software on your PC, it is a weak form in that scripts are executed on a central server rather than the local client. This differentiates SL in very compelling ways for those who wish to surf safely.

Some parts of SL do break this model, however they can be switched off with little degradation to your experience. Buffer flow overruns occur in the code, but one would hope they could be stamped out over time more easily than arbitrary execution of code that can occur in modern Web Browsers, Operating Systems, and unfortunately, plugins in the Second Life client.

However, all is not lost. Plugins do not have to be the end of security in Second Life. There are many approaches to solving this problem, but three main ones come to mind: code signing, open source code, applet sandboxing. Note that the first two assume simply linking against the current open sourced code base (IE: using the ll* apis), while the third would likely require a new language and API. Code signing is my (Iron Perth) preferred method, so feel free to edit this and correct my bias.

• Code Signing. Code Signing via SSL certificates or even Extended Validation SSL Certificates ([6]) would require a third party to issue a certificate which would indicate that the plug in has been verified as trusted. This could go through several layers of verification, up to and including a code audit.

However, given the micropayment and hyper innovation cycle that SL has successfully followed, a certificate which simply identifies the originator of the code (real life name, contact info, etc) would probably be most appropriate.

• Open Source. This approach would require all code to be clear text so that any exploits could be found by examining the code base. It's unclear to me that this would work as the number of plugins became overwhelming in nature as people would simply stop examining the code of every plugin that they were given. Rather, they'd go to a trusted source for plugins, which is what code signing basically is.

Also, this could reduce the incentive to innovate because of the lack of IP protection. Note that some may argue that open source is the only approach because the client is released under GPL. As the holders of the SL copyrights, hopefully Linden Lab will create an exception in the license so that we may link plugins against the code without having to GPL our own code base.

• Applet Sandboxing. This is the JavaScript / Flash / Java Applet model where code is executed inside a VM inside the client. In someways, this is a very compelling approach as it is usually not that challenging to secure the virtual machine. It also allows for dynamic execution of code more easily.

However, it is also a significant engineering feat to build such a thing, it usually has limited capabilities, and often suffers from time and space constraints during execution.

Dynamic Updating Of Plugins

Dynamic Loading of Plugins

Cross Platform Issues

PlugIns effecting Client Stability