You wrote:
> Well, what would you have them do - trust nobody and get no useful work
> done?

I'd prefer a security model based on revokable capabilities, enforced via proof-carrying code. Some of this *is* rocket science, but Microsoft Research employs a substantial fraction of the world's population of type-theorists so it should definitely be within MS's ability to implement. Furthermore, the programmer UI doesn't require any rocket science: all the math lives in the compiler and the program loader.

> Wasn't that the original Java applet model? Wasn't it eventually
> extended to support authentication via trusted applets? Any idea why?

No, Java had a sandbox which can control how much access even a trusted program can get. .NET basically copies this, except that it adds a mechanism -- "unverified assemblies" -- which permit programmers to sidestep the security mechanism. This is a [i]tremendously[/i] bad idea. You want to minimize the amount of trusted code in the system and the runtime, because making sure it works is really hard. Java had a pretty simple security system, and people have been fixing holes in it for years.

The lesson is clear -- /minimize the trusted codebase/. (Dan Wang at Princeton has even invented a PCC mechanism that lets you take the garbage collector out of the trusted base. Tres cool.)

> I'm surprised to learn that ActiveX is such an unsuccessful technology.
> After all, right here on my machine are RealPlayer, Acrobat Reader, Flash,
> Shockwave, and several other popular ActiveX components, and those are just
> the ones I downloaded. The total list of ActiveX components on this system
> easily numbers in the hundreds, and includes such abysmal failures as Media
> Player and Internet Explorer.

This is why the ActiveX security system is a failure, actually. ActiveX is an all-or-nothing security scheme, which means that a single buffer overflow in a single trusted app compromises the entire system. The more code you have to trust the more likely you have a compromise which renders your security useless. It's just simple statistics.

The existence of unverified assemblies, which permits programmers to easily add to the trusted codebase, means that it becomes impossible to verify that the .NET runtime can actually enforce the security guarantees it promises. And given their past behavior we can be sure that MS will use a lot of unverified assemblies in IE and Office and whatever app-of-the-week is at the head of their strategy. If I sound cynical it's because I am. :)