Dino Esposito has an article in the March Dr. Dobb’s Journal taking a look at the Silverlight platform from a security perspective: The Silverlight 2.0 Security Model. The second half in particular boils down some of the details of the transparency model used for security enforcement in Silverlight. This article is quite good – I definitely recommend a read.
In his article, Dino talks about the SecuritySafeCritical attribute as compared to the SecurityTreatAsSafe attribute, and points out that on the desktop framework any public critical method is implicitly TreatAsSafe. He mentions that one of the reasons we didn’t bring TreatAsSafe over to the Silverlight BCL is that this is not true on Silverlight.
To add to this, there’s one other thing that made The other thing that made us decide that SafeCritical would be better than TreatAsSafe was that the only time TreatAsSafe really makes sense is when you’re combining it with SecurityCritical. A TreatAsSafe transparent method, for instance, doesn’t buy you anything. Since 95% of the cases where the TreatAsSafe attribute was being used also used the SecurityCritical attribute, we decided to merge the two into a single attribute – SecuritySafeCritical.