Microsoft has published substantial development documentation around Windows XP's security architecture over the past several months. Reading it carefully provides early signal about whether Trustworthy Computing is producing real change.
A short writeup of what the documentation reveals.
What the documentation describes
Three substantive architectural choices:
Reduced default services. XP ships with notably fewer services running by default than Windows 2000. Specifically, the indexing service that produced the IIS Unicode bug is not enabled by default; the messenger service that has been a worm vector is reduced; several other less-used services are disabled.
The documentation explicitly cites "reducing the attack surface" as a design principle. The principle is the secure-by-default one I have been advocating; seeing it cited explicitly in Microsoft's own documentation is a meaningful shift.
Built-in firewall. XP includes the Internet Connection Firewall, a basic packet filter that is enabled by default for dial-up and PPPoE connections. This is the first time a default Windows installation has shipped with active perimeter filtering.
The firewall is rough — limited rule expressiveness, no logging by default, modest performance — but the defaults are right. A new XP installation is not exposing all its services to the internet by default the way previous versions did.
Authenticated software updates. The Windows Update mechanism in XP is more aggressively pushed; security updates can be set to install automatically. Operators do not have to manually pull each patch.
This is the patching-cadence improvement that the year's worms have made urgent. Most home users will never deliberately patch their machines; automatic patching is the only defence.
What is not in the documentation
A few things conspicuously missing:
Limitation of administrative privileges by default. XP still defaults to giving the user administrative privileges. The least-privilege design — where users run as non-administrators by default and elevate explicitly when needed — is mentioned in the documentation as a future direction but is not the XP default.
Restricted scripting. The documentation discusses the scripting concerns I have written about but does not commit to default-restrictive scripting. Outlook 2002's attachment blocking is the visible improvement; broader changes to the scripting trust model are not in XP.
File-system integrity verification. The documentation discusses code signing and verification but does not implement comprehensive integrity verification of system files. This is mentioned as a future direction.
How to read this overall
My assessment after reading the documentation:
The architectural principles are right. Microsoft has internalised the structural arguments — reduce attack surface, secure defaults, automatic updates. The principles match what the security community has been advocating for years.
The implementation is partial. XP is meaningfully better than Windows 2000 in terms of default security posture. It is not as secure as it could be. The improvements are incremental rather than transformative.
The trajectory is correct. Each of the future directions the documentation mentions — least privilege, integrity verification, broader scripting restrictions — would be substantial improvements. If they ship in Windows Server 2003 or beyond, the cumulative trajectory is meaningfully positive.
My probability that Trustworthy Computing produces visible improvement remains around 80-85%. The XP documentation is consistent with that estimate; it is not changing my prior either direction.
What this implies for operators
For anyone deploying XP:
Use the new defaults. The improvements only matter if they are not turned off. Specifically, leave the firewall enabled, enable automatic updates, do not enable services that the default installation has disabled.
Recognise the limits. XP is better than 2000 but is not ideal. Defence-in-depth disciplines continue to be necessary.
Plan for the future improvements. Some of the most valuable architectural changes — least privilege, restricted scripting — are still in development. Operators planning multi-year deployments should account for these landing in subsequent products.
A closing reflection
The shift visible in XP's documentation is the strongest evidence yet that Trustworthy Computing is producing real change. Not all of what should be done is being done; a meaningful fraction is.
The pace will frustrate some readers. Structural change in large engineering organisations is slow. The trajectory is what matters more than the specific milestone.
More as the year develops.