Thoughts: Silverlight security is nothing more than nothing?

The guys from Silverlight team have applied so many restrictions to reflection in Silverlight to make it "more secure". Frankly speaking, I hate this - first of all, because they're quite unreasonable in many cases. I like to build various "auto" stuff like our AssociateProvider based on it (obviously, everything is cached and is blazingly fast on subsequent calls), and such limitations seriously annoy me. "Security!" - they'd say.

Recently I thought about security in Silverlight/.NET, and a signle fundamental weakness has immediately came into my mind:

- They support multithreading, but I suspect at least some of secure classes they ship (i.e. the ones making, and, more dangerously, internally caching results of some security checks) aren't designed to be used in multithreaded environment. This means thier behavior is unpredictable while they're used concurrently.

- Multithreading normally implies much more complex scenarios related to read\write ordering, second-level CPU caches sync and so on. Taking these ones into account, everything becomes even more complex. E.g. there is a chance that object that doesn't support multithreaded access (but being intentionally modified concurrently) will "see" a completely impossible state of it (or of some object graph) just because CPU cache in the current thread isn't in sync with the modifier's thread right now. Obviously, the chances of getting this are rather small, even if I intentionally write everything to make it high enough. But they increase with time such an exploit runs.

Actually, getting both security and true multithreading in such frameworks are always complex. Obviously, .NET must have the same problems. And, frankly speaking, I don't know if there is any general solution. It's nearly like to expect full serializability while working on read committed isolation level. People used to think this way. I suspect we should seriously change the way we design software (i.e. use completely different programming paradigms and languages) to get them solved.

Few links about memory models:

- "Understand the Impact of Low-Lock Techniques in Multithreaded Apps" by Vance Morrison

- "Explring memory models" by Joe Duffy (look at #4 there).