Since the very early days of the Web, two things appeared as clear as facts:
- First, the browser can't just be like a dummy 3270 dumb-and-deaf terminal. It needs be interactive and responsive to some extent.
Stung by the failure of the ActiveX platform, Microsoft put a lot of attention and effort in the development of Silverlight, especially from a security point of view. Since its first appearance 10 years ago, ActiveX wasn't well received for essentially two reasons -- lack of support for platform interoperability and a poor security model.
Today, Silverlight 2.0 revamps the same core idea of ActiveX -- running user-defined and compiled code within the client browser. However, today Silverlight 2.0 does that in a cross-platform way and using an adequate sandbox to protect the user machine. In this article, I examine the new security model of Silverlight 2.0.
Enter Silverlight 2.0
Shipped with a cross-platform (and obviously thinned down) version of the .NET Framework, Silverlight 2.0 lets developers build rich managed applications that run in virtually any client browsers. As a developer, you can write Silverlight applications using a variety of .NET languages, including C#, Visual Basic, Managed JScript, and also dynamic languages such as IronPython and IronRuby. Figure 1 provides an overview of the Silverlight architecture and breaks the supported .NET Framework into pieces.
The Silverlight 2.0 plug-in is made of a core CLR environment and a brand new Dynamic Language Runtime (DLR) environment made to measure to process dynamic languages such as Python. (IronPython is a Microsoft .NET language with a Python-compatible syntax.) Any code that runs within the CoreCLR may target classes in the Silverlight supported subset of the .NET Framework. This subset includes collections, generics, as well as more specific application programming interfaces such as that for XML parsing, isolated storage, LINQ-to-Objects. Each instance of the Silverlight plug-in is bound to a URL that returns XAML with optional code-behind classes written in any supported language. In Silverlight 2.0, the XAML supports a compatible subset of the full WPF platform along with some specific common controls not available (yet) to the desktop platform.
It is essential to note that Silverlight 2.0 does not require any version of the full .NET Framework to be installed on the client machine. The Silverlight setup program downloads everything that is necessary to enable all the features in Figure 1 on a standard Windows, Mac OSX, or Linux machine. For more information about running Silverlight on Linux, see the Moonlight project, the plug-in's code-name for Linux. Currently, Moonlight is under development.
The Silverlight plug-in measures about 4 MB in size and normally won't take more than just a few seconds to install on a machine. You need to install it only once and you can then successfully navigate to any Web page that hosts Silverlight content using your browser of choice.
Silverlight applications can be deployed to any Web server including Apache on Linux, and always require some sort of host page. You can't just serve plain XAML data to the browser. Instead, you need a host page that sets up the plug-in and make it point to the URL for the XAML content. The host page can be a static HTML files or any server-side generated page: ASP.NET, ASP.NET AJAX, PHP, Java, Python, Ruby, and so forth.