Insane security

Raymond Chen posted about some questions better left unanswered because the answer is unreliable. This quote cracked me up:

"You cannot reliably reason about the security of a system from within the system itself. It's like trying to prove to yourself that you aren't insane."

Although the quote is funny, he makes several points about security that developers should heed. Commenters have taken the post a bit out of context - but the side point he makes is valid. Since most of my audience is setup/installation developers, I'll direct my comments towards that community.

The next time you are given a design document for installing a service, please make sure to ask about the security level required for the service. Make sure to raise objections to installing a service with access to the desktop without good reason (read comments to this post for more information related to the shatter attack) . Ask if LocalSystem access for the service can be reduced to a more restrictive account (HINT: There is a sample for creating user accounts within an MSI in the Platform SDK). Most of all, insist that scoping of installation/deployment design is best when it is done with the scoping of the feature or application - not after. This way, the application developer can develop in an environment closest to that which will ultimately be deployed to customers in the installation with no surprises looming at the end of a development cycle.

In case you haven't noticed, Windows XP SP2 and Windows Server 2003 have tightened up security in these areas. Instead of blindly loosening up the default restrictions this brings, take the application to the next level by understanding why the restriction is now the default in the first place, and learn how to program taking into account this more secure environment. As a setup developer, your customer is the end user. Make sure you are on the side of the customer when it comes to security.

.NET Threading

Although my blog states I'd be covering some C# stuff, I haven't posted anything related to it. Time for that to change:)

I've been fighting with threading in a C# .NET application. Perhaps my frustration was related to the poor coverage of threading in pretty much any .NET book. Perhaps it was because MSDN doesn't really have a decent overview or "related links" in any of the threading-related topics. Another guess is that .NET is dissimilar to Java in its threading mechanism. Most likely, I have been spoiled by Win32's richness and capability when it came to threading.

I uncovered an excellent link to "Multi-threading in .NET" It is currently in 2nd place on a Google search for that term. I am using my limited "Google karma" to help pump that resource to #1 - the article is that good. Newbies to the .NET framework will not be overwhelmed, and moderately experienced .Net'ers will not be bored by it. It simply takes everything about threading and puts it into one place with some great examples. There is a slight C# bent to it. The article contains some .NET 2.0 items, and appears to be regularly updated. One thing I would change - it would be nice to have a "what's new" section for repeat visitors. Jon has plenty of other .NET related articles from his C# page. I haven't read anything else by him yet, but I'm assuming the quality bar is nearly the same.

Some favorite quotes: "...writing thread-safe code is all about taking luck out of the equation." Relating to changing Form or Control elements from a different thread than what they were created on: "You may get away with it in some cases, but only by blind luck."