But, if you got near the end of his 9000-word piece, he wrote this about Windows security and I thought it was so important that I'm reprinting it here in total.

Chris Brumme says: "I havenít blogged in about a month. Thatís because I spent over 2 weeks (including weekends) on loan from the CLR team to the DCOM team. If youíve watched the tech news at all during the last month, you can guess why. Itís security.

From outside the company, itís easy to see all these public mistakes and take a very frustrated attitude. ďWhen will Microsoft take security seriously and clean up their act?Ē I certainly understand that frustration. And none of you want to hear me whine about how itís unfair.

The company performed a much publicized and hugely expensive security push. Tons of bugs were filed and fixed. More importantly, the attitude of developers, PMs, testers and management was fundamentally changed. Nobody on our team discusses new features without considering security issues, like building threat models. Security penetration testing is a fundamental part of a test plan.

Microsoft has made some pretty strong claims about the improved security of our products as a result of these changes. And then the DCOM issues come to light.

Unfortunately, itís still going to be a long time before all our code is as clean as it needs to be.

Some of the code we reviewed in the DCOM stack had comments about DGROUP consolidation (remember that precious 64KB segment prior to 32-bit flat mode?) and OS/2 2.0 changes. Some of these source files contain comments from the Ď80s. I thought that Win95 was ancient!

Iíve only been at Microsoft for 6 years. But Iíve been watching this company closely for a lot longer, first as a customer at Xerox and then for over a decade as a competitor at Borland and Oracle. For the greatest part of Microsoftís history, the development teams have been focused on enabling as many scenarios as possible for their customers. Itís only been for the last few years that weíve all realized that many scenarios should never be enabled. And many of the remainder should be disabled by default and require an explicit action to opt in.

One way you can see this change in the companyís attitude is how we ship products. The default installation is increasingly impoverished. It takes an explicit act to enable fundamental goodies, like IIS.

Another hard piece of evidence that shows the companyís change is the level of resource that it is throwing at the problem. Microsoft has been aggressively hiring security experts. Many are in a new Security Business Unit, and the rest are sprinkled through the product groups. Not surprisingly, the CLR has its own security development, PM, test and penetration teams.

I certainly wasnít the only senior resource sucked away from his normal duties because of the DCOM alerts. Various folks from the Developer Division and Windows were handed over for an extended period. One of the other CLR architects was called back from vacation for this purpose.

We all know that Microsoft will remain a prime target for hacking. Thereís a reason that everyone attacks Microsoft rather than Apple or Novell. This just means that we have to do a lot better.

Unfortunately, this stuff is still way too difficult. Itís a simple fact that only a small percentage of developers can write thread-safe free-threaded code. And they can only do it part of the time. The state of the art for writing 100% secure code requires that same sort of super-human attention to detail. And a hacker only needs to find a single exploitable vulnerability.

I do think that managed code can avoid many of the security pitfalls waiting in unmanaged code. Buffer overruns are far less likely. Our strong-name binding can guarantee that you call who you think you are calling. Verifiable type safety and automatic lifetime management eliminate a large number of vulnerabilities that can often be used to mount security attacks. Consideration of the entire managed stack makes simple luring attacks less likely. Automatic flow of stack evidence prevents simple asynchronous luring attacks from succeeding. And so on.

But itís still way too hard. Looking forwards, a couple of points are clear:

1) We need to focus harder on the goal that managed applications are secure, right out of the box. This means aggressively chasing the weaknesses of our present system, like the fact that locally installed assemblies by default run with FullTrust throughout their execution. It also means static and dynamic tools to check for security holes.

2) No matter what we do, hackers will find weak spots and attack them. The very best we can hope for is that we can make those attacks rarer and less effective.

Paul Thurrott has what he says are some sneak peaks at Longhorn's new user interface (code-named "Aero"). I don't even have access to the Aero stuff (these look like early demonstration screens, and not how Longhorn will eventually look -- the builds I'm using don't have the Aero interface, Microsoft really wants to make sure screen captures don't leak out.) The real "Aero" is one of Longhorn's biggest secrets -- I've seen it, but can't load it on my own machine and am locked out of the server where it's kept. I am not even sure they'll show it off at the PDC.

I know some of my co-workers will get mad because I'm linking to leaked stuff, but it's on the mainstream Microsoft news sites, so it's fair game. My weblog will link to all Longhorn news and try to explain it. That said, my managers haven't released me from NDA yet so I can't say more until management shows it off publicly.

Robert Scoble works at Microsoft. Everything here, though, is his personal opinion and is not read or approved before it is posted. No warranties or other guarantees will be offered as to the quality of the opinions or anything else offered here.