I am fairly new with silverlight and I really find it cool. I have a question about how it runs the code client-side tho..
Say for example, I have a site that calculates a certain amount based on user inputted amounts. This of course I would love to do client-side. The catch though, is that the formula used for the calculation is proprietary and a trade secret. If I put this formula client-side using SL, will it be safe? Or can it be reflected?
If you want to keep algorithms secret, don't push it to the client side. No form of obfuscation or protection is ever perfect.
Also, when you have calculations on the client side, you should always check the results on the server, rather than just assuming they're correct. Assume that the client is compromised.
Silverlight pushes the XAP file to the client. The XAP file is simply a zip file containing your .NET assemblies, which can then be unzipped and reflected against. The company I work for (PreEmptive Solutions) markets Dotfuscator, which can obfuscate Silverlight assemblies. Right now you have to unzip the xap, obfuscate and zip them back in, but we're working on improving the workflow.
Just a note to Dotfuscator users: If you create a Dotfuscator project, you must use the "User Defined Assembly Load Path" property in the "Settings" tab to browse to the Silverlight libs. The paths you need are:
\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies
\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client
or on 64 bit operating systems:
\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies
\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Libraries\Client
Don't fall into a trap of think hiding the algorithm will protect it. Once you put it on the web somebody will figure it out no matter what you do. With enough sample data anybody with some math skills should be able to figure out your algorithm.
All you can do is make it harder. If this algorithm is is something proprietary that you have bought then it will need to be server side. Putting the algorithm on the client side is essentially publishing it and you could be liable.
IntelliLock and .NET Reactor (my preferred tool) obfuscates my assemblies nicely.
While obfuscation is not a fool-proof method, it makes it that much more difficult for somebody to see your code. One has to really jump though convoluted hoops to get to your final code if the layers of obfuscation are good. Crypto Obfuscator is one obfuscator which supports obfuscation of Silverlight assemblies.
Another cool tool is CodeFort. It has free edition. See it in action at http://www.codefort.org
CodeFort .NET & Silverlight Obfuscator
CodeFort is an advanced obfuscator and protection tool for Microsoft .NET and Silverlight applications.
BAML and XAML obfuscator - obfuscate 100% of your code
CodeFort is the first tool ever to be able to obfuscate identifiers inside the XAML and BAML code which is used in Silverlight and WPF applications. This makes it for the first time possible to obfuscate 100% of your code.
Powerful protection against attackers
Coupling the XAML/BAML obfuscation with powerful protection features such as Reference Scrambling and Anti-Tampering CodeFort is a state-of-the-art obfuscating tool.
I must COMPLETELY agree with Marcus. Even obstruficated .NET assembly is still easy to read for a good programmer.
My solution would be WCF service for the calculation. Just push all the data there and give an answer. If your formula is top secret and not obvious (like ax+by+c*z) then even is somebody would get access to service, then it would be hard for him to get it.
There are many companies that support obfuscating Silverlight 2.0 applications. DeepSea Obfuscator has a nicely integrated experience, Dotfuscator also work and soon, the free Eazfuscator will also support it.
Related
Is it possible to only use a managed dynamic language such as javascript in a Silverlight application, with no server side compilation before deploying to the client? I'm looking for 0 server side compilation of any code here - would like the entire application to be 100% compiled/interpreted in the browser. I skimmed through the DLR specs but I didn't notice such an option.
Technically the answer is yes. Silverlight is a pure client side technology that runs a cut down, secure CLR in a plug in. The Silverlight API is accessible scripting languages including Javascript, F#, IronPython and IronRuby.
However, it is questionable whether you should progress because there doesn't seem to be any community or support around this. Furthermore, Silverlight is in support mode and you have to consider whether it is worthwhile investing your energy in such a dimly lit corner.
There are a few technology demonstrations by Jimmy Schementi here. Also check out the references in DLR Wikipedia entry. The old silverlight forums used to have an entire subforum dedicated to Javascript and Silverlight. This is now gone. Consider that as a warning if you decide to progress in this direction.
A few years back, there was an SDK that included a working IronPython and IronRuby with Silverlight, some demos and build scripts. Look for Chiron, which packages scripts and xaml into a single .xap (zip) file. This is in the DLR. There were some cool examples which demonstrated a python and ruby interpreter running in the client side in a Silverlight plugin.
Alternatively, you can develop most of your application in a typed language and then expose parts of it to javascript via a Javascript bridge. The MSDN has some short write up on how to do this.
My application is being developed in silverlight. Plan to launch it later this year. I am worried against my xaps getting reverse-engineered. I do have a fare amount of intelligence in my wcf service but you cant put everything in the service. Now winrt is anothe option. Fact that both silverlight and winrt use xaml, it seems possible to move my client code to winrt but only if that code is protected against reverse engineering. Opinions?
No.
http://JustinAngel.net/ReverseEngineerWin8Apps
There is little that can protect your code against reverse engineering. Running on server hides the code making it most secure, obfuscation still protects it quite well, but not completely and it has some other risks. WinRT allows you to write native code, which is a bit harder to reverse engineer than .NET code, but only marginally. On the other hand - if your application is written in non-minified javascript - you are basically shipping your source code and you don't even have a xap file to decompress - just look in C:\Program Files\WindowsApps and there is a folder for your app where all the files you see in Visual Studio are stored.
You can look at these options then and decide what would work best for you. Ultimately though - the choice between WinRT and Silverlight is a choice of platform - WinRT applications will only run on Windows 8 and (we can speculate) possibly on the next version of Windows Phone, which at least initially - limits your target audience. I have not heard of the option to sell Silverlight apps through Windows Store, unless you are targeting Windows Phone, where that is the only option (that and XNA - both being .NET based).
If your client-side code is indeed a unique intellectual property - you are better off protecting it with patents and copyright law than with obfuscation and compilation.
I'm interested in using F# for numerical work, but my platforms are not windows based. Mono still has a significant performance penalty for programs that generate a significant amount of short-lived objects (as would be typical for functional languages).
Silverlight is available on OSX. I had seen some reference indicating that assemblies compiled in the usual way could not be referenced, but not clear on the details. I'm not interested in UIs, but wondering whether could use the VM bundled with silverlight effectively for execution?
I would want to be able to reference a large library of numerical models I already have in java (cross-compiled via IKVM to .NET assemblies) and a new codebase written in F#. My hope would be that the silverlight VM on OSX has good performance and can reference external assemblies and native libraries.
Is this doable?
Technically speaking, Silverlight assemblies are similar as normal CLR assemblies, with the exception that they reference different version of runtime (and different version of system libraries such as mscorlib). Silverlight can run only Silverlight assemblies, so if you're compiling F# code you need to instruct the F# compiler to reference Silverlight (here are Visual Studio templates from Luke Hoban and here is a recent sample Silverlight app in F# by Brian McNamara).
Now, regarding the non-F# assemblies, I'm afraid this may be a problem. In principle you don't need to recompile them - there are tools to change the version (to turn CLR assembly into Silverlight assembly). See for example this article. In practice, Silverlight has many limitations (lots of methods missing, you are not allowed to do some Reflection tricks for security reasons etc.). So, I'm afraid that if you simply convert the assembly to Silverlight, it won't really work, but you may still try that... (but be careful - if a referenced method is missing, you won't find this out until Silverlight tries to call it at runtime).
Finally, there is also a problem with communicating with the application running in Silverlight as Silverlight apps have pretty limited capabilities. However, Silverlight 4 RC should allow you to read/write local files when running in the Out-of-browser mode (which may be good enough).
In summary I think that there are a lot of issues that may make it impossible to use Silverlight for this. I would maybe consider doing some more testing on Mono and sending feedback to them (if you find some case where the performance is clearly poor) - From my experience, they can be quite effective in responding to the feedback from users and I have the feeling that F# may be quite interesting thing for Mono team.
It seems like these two technologies, already similar, are on a path to merge into a single technology. There are a lot more WPF-like controls in the Silverlight toolbox, and WPF now has Silverlight's VisaulStateManager. At this point, it's probably fair to say that Silverlight has even surpassed WPF in terms of the number of themes available.
How long until these two technologies become one? How long until the difference between a rich client app and a rich browser app is a simple compile-time setting?
EDIT
Let me clarify my question. I realize that any browser application needs to run in a "sandbox" for security reasons, and I also understand the desire to keep the browser plugin as small as possible, but there are several minor differences between the two technologies that could probably be massaged out without compromising either of these goals. For example, there could be a lot more overlap between UI controls and themes. Today, you can't just use a Silverlight theme in a WPF app, but how much of a leap would it be for Microsoft to make this possible?
I don't think they'll ever merge into one product. Microsoft has intentionally left a lot out of Silverlight to keep its footprint small. And then there's a plethora of security issues Silverlight must abide by when running in a browser. And of course they've designed it so it'll run on a PC or a Mac (unfortunately the same can't be said for the .NET Framework).
I am happy to see resources shared between WPF and Silverlight though. They were supposed to be similar from the beginning. As a result, it's relatively easy to port a Silverlight project into WPF. On the flip side, it's not quite as easy going from WPF to Silverlight simply because WPF has always had more features, but that's just the nature of the beast.
UPDATE:
So your revised question is interesting. It would be cool if Microsoft could make it possible for you to basically flip a switch to change the behavior of your app between Silverlight-like functionality and WPF. They would be facing a great deal of challenges though, not only with security but with the fundamental behaviors of some of the lightweight Silverlight controls vs the feature-rich WPF controls. These differences could potentially complicate things for the developer even further.
For example, in WPF there's a built-in multiple undo & redo system in the textboxes. In Silverlight there is no such thing so I actually had to write my own. In order for the developer to account for things like that they'd have to do build a lot of feature-checks into the application.
With all that said, I suppose a compile-time switch as you described might be feasible. But I still think it's unlikely Microsoft will create this kind of capability any time soon.
XAML and databinding may become closer between the two
but the rest of the framework will probably never be the same.
For once, you can not automate an Office application using Silverlight.
And that may never happen, unless MS decides to open a bridge of some sort
between the plug-in and the .NET Framework.
Security, consistence, and great UI are main driving forces in Silverlight.
If you can do something in Windows that you cannot do in Mac than
consistence is lost.
Silverlight installations has its own libraries built for specific operating systems. We as developers use what microsoft gives us that can run on those systems. WPF is full trust to the windows operating system which uses specific windows api calls.. So i'd say never will they merge.
Yes we will see that WPF and Silverlight becomes more and more alike, if the acutely will be merge? maybe It's not impossible but what we will see is just that what you stated that they will be more alike. So in the future you will not implement WPF OR Silverlight you will just implement XMAL.
Silverlight Out of Browser technology and WPF ClickOnce on the surface have similarities. Easy and simple deployment, the ability to specify the level of trust access to the underlying host, etc.
What are the key issues I need to consider when choosing one over the other?
To put a finer point on it, I'll be deploying LOB apps on a corporate network running only windows computers.
The big one is cross platform compatibility. If you need you app to run on a mac as well as windows (not sure if Silverlight is supported in Linux yet) then use Silverligt. If you want to make an assumption that all your users will be in a windows machine then go WPF.
Obviously WPF has a much richer toolkit than silverlight so it may well be that silverlight just isn't an option. If I was just building for windows though I know my job would be easier in WPF.
Given that you are targetting a private infrastructure running Windows, two points worth thinking about
Wpf has a richer control tree, whereas Silverlight is a reduced set for compact size
Wpf requires .Net framework installed locally, whereas Silverlight has its own platform independent browser-based runtime
While your target platform will likely have the latest .Net framework installed, rendering this last point moot, keep in mind any updates to the framework [ie .Net4.0 and any future updates] may require a restart of the machine - which is a major pain point for businesses that demand constant-on stateful desktops [ie anything in finance, like banks and trading].
As with all problems, your requirements, not the technology, should inform your solution. :)
You mentioned trust access to the host which I think rules out Silverlight unless you want to run SL4 (beta).
We recently went through a lot of discussion about file system access. Silverlight 3 runs in a partial trust sandbox more or less. You can't maintain a pointer to files in the files system outside of your application's isolated storage. This was an issue for us as we wanted the user to be able to use the application to reference odds and ends on your file system. That said you can allow the users to load and save files from anywhere on the system but you just get/or push the file stream and (to the best of my knowledge) don't have access to the folder or file path information.
Silverlight 4 (in beta) has support for your application running in full trust mode. I haven't played with this yet however and can't speak to how well it works.
In talking with a lot of people who work with both Silverlight and WPF, even those who are excited about Silverlight and push for it strongly, I hear a lot of the say fairly emphatically that if you are going to be developing exclusively for a full-trust Windows environment, WPF is hands-down the obvious choice.
That's not to say that Silverlight is an inferior product or that there aren't times will Silverlight will be the clear winner. But when you say "I'll be deploying LOB apps on a corporate network running only windows computers," it sounds like WPF is the clear winnder.
You could decide to go down the Silverlight route in anticipation of all of the great new OOB feature os SL4. I've even heard rumors that SL and WPF will eventually merge, so it may not even really matter, right? Well, I think what you'll find if you go with Silverlight is that some of the advanced features that you thought were there weren't there in the way you expected. For example, SL4 will be able to run in "Elevated Trust" (not full trust) and you might find this limiting at a frustrating point in the project where a lot of your code base is already in Silverlight.
Certainly keep your eyes on Silverlight, but for your current business case, WPF will likely be the best fit.