Sunday, October 17, 2010

Silverlight 4 “trusted” out of browser: The new ActiveX?

Silverlight 4 is a tremendous leap forward in functionality.  
We get webcam support.  Printing support.  Improved DRM if you're into that sort of thing...
Elevated permissions to make slightly more powerful applications (in terms of what the application is allowed to do).
But, in a move that seems pretty unrestrained from the Microsoft Silverlight team, and especially with the introduction of COM automation, the power of an elevated permission nears that of a full blown desktop application.

And like all great powers, this can be used for both good and evil.
 
What do we get out of the browser?
The desktop installed "out of browser" experience for Silverlight comes in two flavors:
Flavor 1: Sandboxed
This is not too different from the experience you get from a Silverlight application in the browser.  There are a couple bells and whistles here to support "offline" applications, as well as some notification "toast" APIs.
Flavor 2: "Trusted"
In this configuration, certain things that caused concern for phishing and spoofing (and thusly removed or requiring user opt-in from the sandbox option) have been removed in Trusted mode.
This includes allowing full access to the keyboard in full screen mode, customizing the "chrome"/window borders, reading and writing to the "My" directories (MyDocuments, MyPictures, etc)
It also allows some Windows specific APIs around allowing for COM automation.  You remember COM? Better known to the web world as ActiveX.  And while it's a very handy capability in a highly controlled environment such as an intranet, it's mostly famous for it's guilty association with malware through drive-by downloads.
Package deal trust vs. ala carte...
This is the popular strategy of passing the responsibility of risk associated with an application's installation onto the user.  Traditionally on the Windows platform, the end user is given a stern warning that they are about to give the application or component they are about to install every right, ability and privilege that he or she has.  This warning is coupled with the disclaimer that the user should only allow applications from reliable and “trusted” publishers to have this ability.
Fast forward a bit to this century, and you will find that this has been improved upon slightly on the mobile platforms in more of an “ala carte” fashion.
In mobile platforms such as Android and Windows Phone 7, the user is warned that the application may want to access certain parts of the API that may compromise their security or privacy.  This list of needed abilities is published along with the application and is listed for the user prior to the user’s consent to install the application.  Any other parts of the API not listed in this manifest of needed abilities are shut off from the application.
Granted some end users are still not going to know what they are being asked to consent to, but this model is a large improvement over the nebulous nature of the big unknown package of abilities that the user normally has to agree to.  And the users that do understand what the list is asking can make a much more informed decision whether to trust the install or not.
Silverlight 4 still uses package trust...
Going back to the roots of the way ActiveX installations warned users of potentially malicious code, Silverlight 4’s trusted applications follow this same pattern.
On the surface of this, this isn’t a bad thing as even the cross-platform specific elevated trust capabilities are still pretty restrained.  However on the Windows platform, lumping restrained abilities with the ultra powerful capability of creating COM objects basically makes trusted Silverlight 4 applications a re-skinned version of ActiveX.

For all intents and purposes, it’s basically like classifying rubber band shooters and rocket launchers as the same type of weapon.  One can sting a bit if it hits you.  The other can kill.  And even if just the rubber band is the only weapon that’s going to be used, the user has to assume that the rocket launcher is in the arsenal as well.  Suddenly office rubber band fights aren’t nearly as fun. 
Rose colored use-cases...
I know there are some out there that feel that the security concerns over COM/ActiveX are over-exaggerated.  And in many cases this is true.  I believe that COM/ActiveX is a great and powerful feature in a very controlled environment (such as a company intranet, or a user base of paying customers that are trusting you with support for the application)
However, there is some valid concern for those that think COM killed their inner child in the 90's.  Particularly to those wanting to distribute applications for general consumption by the general public over the web.
For every rose-colored and friendly usage of this ability, there are one or more equally malicious usages.  What? I can use the FileSystemObject to write files to the C: drive and the Shell Application object in the Windows Scripting Host registry writer method to add my Silverlight application to the start-up group?  That’s great and powerful and possibly even useful.
But it also affords me the ability to copy some malicious program I’ve happened to carry along in my .xap deployment to a PC and force that to start-up on boot, using nearly the exact same code.
“Well I’m not going to do that…”
Of course you’re not. Remember Spiderman? Responsible programmers realize that with great power comes great responsibility.  Responsible programmers have honor.
But even Spiderman has villains.  Those that have equal access to fantastic powers and they do not use this power for good.  They don’t care what are considered “good” practices, nor do they have the end user’s best interests at heart.
Why are vials of liquid not allowed on airplanes anymore? Because ONE person exploited security to use it as a vehicle for bringing dangerous chemicals onto the plane. And while that is an extreme analogy, the mind set behind the how trust is developed around the experience is not far off.
The heart of the issue here isn’t one of paranoia more than one of psychology.  It will take only one or two very public abuses of this capability to ruin it for the rest of us.  And the general opinion of Silverlight will be the same as ActiveX.  Ultimately it will be viewed that Microsoft has merely given the Trojans a new way to build their horse.  Notice I said “Silverlight” here and not “Trusted Silverlight 4 OOB Applications”.  Your average consumer isn’t going to bother with the differentiation.

As it is now, if you’re writing a game or something that needs full access to the keyboard in full screen mode, to gain that ability also requires you to gain the ability to create COM objects.  Or write to the “My” folder group for that matter.  It would be nice if I could absolutely guarantee to a user with absolute certainty that I am only using a subset of the powers I’m being granted.
Complaints without solution ideas are like rocking chairs…
Both give you something to do, but you never get anywhere.
So what do we do?
Honestly, I think the answer has already been implemented.  There is no reason why the same pattern utilized on the mobile platforms couldn’t also be utilized for the Desktop experience.
Furthermore, this could be added as a security patch to the existing Silverlight 4 runtime.

Consider how the team at Microsoft has addressed this for Windows Phone 7:
PhoneCaps

Something like this could be added to the manifest for desktop applications (indicating desktop specific capabilities instead of the phone ones, of course).  For backward compatibility, if capabilities are not specified, the assumption could be made that EVERY capability is needed.  Then the developer could choose to re-deploy their application with a smaller list of needed capabilities.

It would be nice as well if the “capability” in this list for COM included a group of ProgID’s the program will need and Silverlight prevents the creation of the rest.  But a way of shutting COM off/on entirely would be enough.
Both the desktop and phone implementations could benefit from a way for the developer to provide some notes at install time indicating why the various capabilities are needed.  Although the developer could provide this today on the hosting webpage itself, having it in the app provides the ability to always contain it if the application is presented to the user from some other source than the author’s website.
Final Thought: Believe it or not, “I can’t do that” is ALSO a feature
In conclusion, I want to add that the ability to say your applications “can’t do something” or “isn’t allowed to do something” is sometimes a great feature.  Particularly from an end-user support point of view.
Whether you are an ISV supporting your own product, or handing off support to some internal team inside your company’s infrastructure, the restraint of capability is a great tool for troubleshooting.  An end user can easily place blame on your application for any number of bizarre behaviors that he or she is experiencing on his or her desktop. “I think your Silverlight app is writing random files to my hard drive” is easily argued against if your application is simply not allowed the capability in the first place.
In closing, I’d like to draw attention to an item I submitted to Microsoft’s official wish-list to implement the above.  If you feel as strongly about this as I do, please consider voting it up and drawing attention to it.  Here’s the link.

No comments:

Post a Comment