Security in Silverlight


Following the announcement at Mix a few weeks back, one of the questions on many people's lips is (as with any cool technology) what are the implications, who better to explain about this than the .NET security team?

One of the interesting email newsletters that hits my inbox is MSDN Flash which is created by developers for developers.  This edition, they highlight some cool posts on the .NET security blog about security in Silverlight and all the implications this new platform.  There are a series of posts on this particular subject but the overall message seems to be:


  • All applications written for Silverlight are security transparent.  This means that they cannot: [details]
    • Contain unverifiable code
    • Call native code directly
  • Silverlight applications can access public methods exposed by platform assemblies which are either: [details]
    • Security transparent (neither the defining type nor the method has any security attributes)
    • Security safe critical (the method has a SecuritySafeCriticalAttribute)
  • Silverlight applications may contain types which derive from: [details]
    • Other types defined in the application
    • Unsealed, public, security transparent types and interfaces defined by the platform
  • Silverlight applications may contain types which override virtual methods and implements interface methods which are: [details]
    • Defined in the application itself
    • Defined by the platform and are transparent or safe critical

For more info on each bullet explore the details link.

Technorati tags: ,
Comments (0)

Skip to main content