Security rules for subclassing transparent type with safe-critical constructor in Silverlight

In the Silverlight (v4.0) security model, Shawn Farkas says of deriving from types:

[...] we see that application types may only derive from other application types or transparent platform types. (*)

The * part of this is:

(*) This true in 99.9% case. There is another rule about the visibility of the default constructor of a class (which we'll get into next week when we dig deeper into the security model), which also requires that the base class' default constructor (if it has one), must be transparent as well. Practically speaking, you're not generally going to find interesting transparent types in the platform which do not also have transparent default constructors, so this rule doesn't normally come into play.

There is, however, one such interesting transparent type which does not have a transparent default constructor - the WebClient class. There's also a good reason to want to subclass it - to override GetWebRequest to provide support for cookies.

As a test, I've tried the following both with and without the constructor attribute...

public class MyWebClient : WebClient
{
    [SecuritySafeCritical] // matches the attribute on the base class ctor
    public MyWebClient() { }
}

...but get the following error either way:

Inheritance security rules violated while overriding member: 'MyWebClient..ctor()'. Security accessibility of the overriding method must开发者_StackOverflow match the security accessibility of the method being overriden.

It looks to me like this is the 0.1% case that he mentions. Unfortunately, as far as I can tell, the next posts never did expand on what the rule would be here. Thus I have two questions:

1. Does anybody know what this 0.1% rule is?
2. Given 1, is it possible to derive from WebClient in Silverlight 4?

---

My answer to this question covers part 1 of yours.

The answer to 2 is simply no, but in the case of WebClient, you can create your own if you have some reason to do so.