Silverlight, Security, and Sandboxing

I'm taking ownership of an application that uses Silverlight for a front end. I had never programmed in Silverlight before and only really knew of it from Netflix's Instant Streaming. I've come to really appreciate Silverlight, since it provides a rich user interface while leveraging the resources of powerful platform like .Net.

It's easiest to think of Silverlight as an alternative to Adobe Flash, which does not easily integrate with other code. The recent Internet-based UI revolution has taken two paths: Flash-like applications (called Rich Internet Applications (RIA)) and AJAX-powered pages like GMail. It's hard to remember the days when you had to refresh an entire page to gain new content, since AJAX and Flash provide such a seamless experience.

Developing in Silverlight is just like developing Web Forms, Sharepoint controls, or User Controls. It just uses XAML instead of ASPX. See the snippet below:

<stackpanel name="LayoutRoot" background="White">
<textblock text="Hello, World!" horizontalalignment="Center">
<ellipse name="FirstEllipse" height="100" width="200" fill="SlateBlue">
<button name="FirstButton" width="100" content="Click" click="FirstButton_Click">

private void FirstButton_Click(object sender, RoutedEventArgs e)
{
FirstButton.Content = "Click Again!";
}

(taken from this example)

As a long-time ASP.NET Web Forms developer, I was surprised that I couldn't just make a DataGrid object and connect it to a DataSource object. To connect to any data, you have to create a Windows Communication Foundation (WCF) web service. This entails learning yet another technology (more on that in a later post), and all the difficulties entailed in creating, deploying, and debugging web services.

I had a hard time finding anything explaining why all this was necessary, until I found this article by Josh Twist. Since a user downloads a Silverlight application that runs in their browser, it cannot be trusted by a server. You need a boundary of abstraction and authentication in order to ensure that the integrity of your data (and your servers) is maintained.


When you have a standard Web Forms application, all of the code is executed on the server. Even though Silverlight code looks like server-side code, it's really executing on the client's machine. For this reason, it faces all of the same limitations as client-side code you might be more familiar with, such as JavaScript and Java applets. A Silverlight application can't be trusted, since its code is non-deterministic and might become corrupted at any time. For this reason, it is sandboxed by your browser. It can't take up all your memory. It can't access the file system. And it certainly can't access your database.

This secure sandbox model is going to become more and more prevalent. The 2000's saw a resurgence of the client-server model in which thin clients (like web pages) did little processing but produced a lot of network traffic with servers. But with the rise of mobile phones, tablets, and other cheap devices, there is no reason to continue to put such a strain on servers and networks. RIA's also provide a great user experience--so great that Windows 8 is going to make it a major part of its architecture. The Windows Metro platform is meant to emulate the touch-driven interface of mobile apps while maintaining the tools many developers have continued to use.

If you want to port an application to desktop, tablet, and mobile devices, you'll have to make this architecture your friend.

Links:
-MSDN article on Silverlight sandboxing
-Windows Metro preview at Engadget