Should Silverlight 3's Out of Browser be Full-Trust?

When the Silverlight 3 “Out of the Browser” support (dubbed OOB by someone other than me) I was approached by more than a few attendees wondering whether I thought that OOB meant the death of WPF. While I still contend that this is not the case, I have been forced into thinking about the OOB support in a deeper way earlier.

On Twitter, no other than Jon Galloway, Caleb Jenkins, Tim Heuer, Jusin Angel, John Papa and Brian Henderson (et al.) have had this on-going discussion about OOB and how it differs from Adobe’s AIR and from in the browser Silverlight. There are a range of opinions but I thought it helpful to explain in more than 140 characters my opinion. But first some background.

For the uninitiated, the OOB support in Silverlight 3 simply allows you to install a Silverlight application to look and act like a desktop application. OOB support can install icons and check for updates on the server when launched. While this feature look and feels somewhat like ClickOnce, its very different. In OOB, your application is still running in a browser (a window hosting IE on windows and Safari on Mac).  It still lives in the same security sandbox as browser applications.

So how could this cool feature cause so much discussion? The problem is that the competition, Adobe AIR, does things very differently. Air is an interesting platform because it essentially is just a webkit with operating system-like chrome around it. Flash/Flex is one of the hosts can live in it (though you can host PDF’s and AJAX HTML apps too). To run Air applications you have to download and install a second runtime.

But Air also lives in two different worlds.  You can have Air applications that act/look like their web versions and live in that same sandbox.  But for most people who have experienced Air (mostly in the form of Twitter clients), they are used to using Air applications running as desktop applications. In that state, the applications run in Full-Trust (though some of the API’s to get at desktop resources seem to be treating the desktop in a non-OS specific way). (CAVEAT: I know just enough about Air and Flash to get me in trouble so if I have something wrong, please comment about it so we can get the story right.)

This is contrasted with the Silverlight OOB experience which is specifically always acting like a browser app and that pesky security sandbox. This is where the consternation comes in. There are several camps:

• Happy with the more secure browser-like sandbox.
• Want some changes, specifically Cross-Domain Access should be allowed.
• Want a desktop solution that is cross-platform.  Let me access local resources too.

I happen to fall into the first camp. After living through the ActiveX world, I tend to believe that the more security the Silverlight model is, the happier I am. Because at the end of the day, most people will press “Yes” to any question if there is some reward (a casual game, a naked picture of a celebrity, free software, etc.) I want Silverlight to protect those people from themselves because when they get bitten and someone downloads their Quicken file and does dasterly things with it, Silverlight and Microsoft will be blamed.  That hurts those of us with the technology.

The other problem with the power of full-trust is that means that one day i’ll have to write this code:

switch (Platform)
{
  case Platform.Windows: 
    // ...
    break;
  case Platform.Mac:
    // ...
    break;
}

Once I write this code, the game is over. Isolation from the operating system is one of the benefits here. Sure it does mean “Write One…Debug Everywhere” but at least we won’t be developing with the platform in mind.

Finally: “With much power is much responsibility.”  But I think we’ve learned that no one can be trusted with that power. That’s why iPhone and XBox Live have certification of applications. Developers and script kiddies are the bad guys and if the platform is to be trusted, it has to be circumspect.

But what about the people who want some power that doesn’t sound to dangerous (mostly cross-domain access)? I’d argue that this is a problem with the services mostly.  If Microsoft decided to remove this limitation, I wouldn’t be terribly upset (as this causes problems consuming Azure services for Silverlight too), but I still don’t think its the right fix. I may be generalizing but it seems that the only people really upset about this are writing Twitter clients (since Twitter specifically forbids web clients from accessing the API).

Caleb Jenkins’ argumet that the whole cross-domain policy is a hacked protection that Flash came up with and that Microsoft is perpetuating is a compelling argument. I hear from people from time to time that the security isn’t useful as its too easy to avoid by proxying through the server.  Why yes, you can do it by proxying to the server but that’s the point.

I explain it to my students this way: The reason for the cross domain security is to prevent untraceable code from executing their API. Why is it untraceable?  Because when you write client code (JavaScript in a page, Silverlight, Flash, Java Applets, etc.) that runs in a browser (which means that the code didn’t originate with the user’s machine), the API owner can’t trace the code.  My mother loves any casual game anyone promises her…she had nine IE toolbars to prove it. So when someone write a Silverlight application that promises a game, and my mother presses “Yes” and then they pound a server looking for holes, they can trace it back to my mother and that’s about it. When you get around the limitation by proxying it to your server, then they can trace it to you…the code running on your server. That’s why I believe cross domain security works.

So, yes I like the sandbox even if that means that Air continues to flourish.

But what about WPF?  Let’s look into the future and imagine a WPF 4/Silverlight 4 world where they are pretty close to each other.  Then a development of an Air competitor to allow you to run your WPF apps cross operating system with full-trust makes sense.  But it would require an install to make sure that the user knows that’s what is happening. I’d be ok with that.  But trying to shoe-horn it into OOB I think is a misake.

Now…what do you think?  (And don’t be gentle.)