Question

Does anyone else think Silverlight 4 security is a bit screwball?

Look at the following scenario:

1. Silverlight when set to trusted app, and run out of browser mode allows you to browse for a file using the file open dialog.
2. You require the name of the path of the file to open it up from any COM automation. For example (excel/word) but this could be anything.
3. It is impossible to get the full path of the file from the dialog because of security restrictions
4. You can however using COM FileSystemObject – do what ever you want to the users file system, including create folders, move and delete files.

So in other words, why all the fuss about security in Silverlight, which actually hinders real business use cases, when its possible to access any file anyways using COM?

To say it another way, if a user runs a malicious silverlight app, its unlikely they’ll say – oh well it was COM at fault. The COM was afterall being called by a Silverlight app.

Here is what I mean….

• User browses for file – c:\myFile.xls
• Silverlight prevents you from getting the path (for security reasons)
• Silverlight only lets you work with my documents
• Using COM you can do what ever you want to the file system in the background anyways. Including copying that file now to my documents, if only you knew the name! But besides that you can wipe any file potentially if its not in use.

In my opinion Silverlight security model is flawed, either they should have given developers full trust and allow us to run apps as if they were running locally

or

Not allowed Silverlight to access COM.

Is it just me, or can anyone else see that its a bad implementation?

This triggers security alerts:

OpenFileDialog flDialog = new OpenFileDialog();
FileInfo fs = flDialog.File;
string fileName = fs.FullName;

This doesn’t

dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject");
fileSystem.CopyFile(anyFileName,anyDestination); 

Answer 1

I don’t agree with your point of view. The fact that you can do pretty much anything that an installed COM object will allow you to do is not a reason to modify a whole bunch of existing Silverlight code to allow you to do those same things.

Why? Because in the process of opening up that code there is also an increase chance that in some unintended way that same code could get run when the Silverlight component is not running in trusted mode. If that were to happen even once the media would all over it in a shot and Silverlight’s reputation would, probably unfairly, be in tatters.

Personally I’m quite happy with the very cautious approach to security that MS are taking with Silverlight.