3 Comments

  • it's the same for WWF too. i've been calling this 'the sandbox gap'. they give us a limited set of permissions for smart clients to play in, but then the new APIs don't allow us to play in that space so we have to revert back to System.NET and custom workflow implementations.

  • The issue here is not "we don't want to do it". The problem is that partial trust is incredibly hard (and very time consuming) to test for a communication platform that is supposed to have rock solid wire-level security and shall perform well. It's just as hard to provide meaningful exceptions ( and -messages) in case we'd stumble into a CAS exception. You wouldn't want us to just bubble up some security exception, but tell you want's causing the problem. There are about 20 base permissions in the framework, most of them allow parameterization, and the system is extensible with custom permissions as well. You can do the math for where that takes you in terms of required combinations for achieving satisfying test coverage.<br />I wonder how many apps take that complexity into account in their test strategy ;)<br />That said, I will clarify that this doesn't mean "we will never do that". It's just not possible to fit this into our V1 schedule. That's all.

  • Thanks Clemens for your comments, and I understand the difficulty of the task. I also appreciate you are not saying "we will never do that". That is reassuring.



    I know as well as others security is not easy, and it is especially not easy to test. You don't test security, typically, in an application by seeing how it succeeds, but how it fails, and if it fails "securely" without opening potential security holes and vulnerabilities. That testing takes time and effort and certainly special skill and determination.



    However, there was a decision somewhere in the timeline to drop partial trust as a feature in WCF/WWF for v1. Why? Was it the sheer complexity? Was it the lack of developers to testers ratio (I absolutely admire and applaud Microsoft for doing this in the past when deciding to drop features because there were not enouth testers on hand)? Was this decision impacted by a well-followed SDL (Security Development Lifecycle) plan? This is a curiousity point to me more than anything else.

Comments have been disabled for this content.