If you're a Windows programmer today, depending on your age most likely you got your start programming one of Microsoft's early platforms: DOS, 16-bit Windows, or Windows 9X. Some of today's Windows programmers came from UNIX, but I'd say the vast majority grew up in the ghetto (as I did). None of these early platforms had any support for security. There wasn't much need for security back then as DOS and Windows weren’t multiuser networked platforms. Programmers quickly learned that Windows was a single-user system, and security wasn't part of the picture.

When Windows NT arrived, things changed. The platform suddenly sprouted a new feature called user security and supported things like multiple logons, user profiles, and access control. However, most Windows programmers paid little attention to these new features and kept hacking up single-user programs. You really can't blame them, as Windows NT didn't encourage anyone to create normal user accounts and experience this new feature called security. Running with admin privileges gave people the illusion that they were running on a single-user, isolated system as before.

Eventually corporations started using the networking and security features of Windows NT and began implementing security policies that forced their users to run under nonprivileged accounts. However, developers didn’t follow suit for one of two reasons. Most developers simply didn't have the time or the inclination to learn how to navigate the barriers in a nonprivileged world. Others who tried to run as non-admins failed miserably because their tools broke when run under nonprivileged accounts (take the classic Visual Basic 6 as an example, which updates protected parts of the registry each time you compile). Developers took this as a sign that they were meant to always run as administrators on Windows, which was the beginning of the vicious cycle that we're stuck in today.

Today we have hundreds of thousands of Windows developers who know little about security, building programs that often must be run on secured computers. Because the typical Windows programmer still runs as an admin, she tends to build code that breaks in a nonprivileged environment. I've heard arguments from people I respect that the solution is to test in a nonprivileged environment. Yet these same people fail to produce software that can run correctly in a nonprivileged environment. It would be funny if it weren't so sad a state of affairs.

Security Is a Process, Not a Product

Security is not something you can buy or even build. It's much more than that—it's a process, and in many ways, a state of mind. Developers running as admins continue to produce software that breaks for non admins. When asked to stop running as admin, the developer complains that stuff breaks when he does that. This is the quagmire we're in today. Figure 8.1 shows an example of a popular music jukebox (which shall go unnamed) that forces its users to run as administrators. At least this application warns the user that it's got a problem. Most broken applications simply fail at random places, leaving the user utterly mystified.

Figure 8.1 This is pathetic.

Crawling Out

It's obvious that Windows programmers need to learn how security works on their platform. I believe that a great way to start is to run from day to day as a normal, nonprivileged user. Why? Because I did it myself. I stopped running as an administrator, and I immediately began to spot problems in my own code and in other products that I used to use on a daily basis. I was shocked to see how many programs failed miserably when run nonprivileged, but at the same time I was learning how to avoid these failures in my own code. I felt like I'd taken the red pill (apologies to The Matrix) and was seeing the real world for the first time.

I truly believe that the security revolution on this platform must be organized at the grass-roots level with programmers like you and me. For example, if you're building developer tools (compilers, profilers, source control tools, UML tools, etc.), you have a special responsibility to the community to make sure these tools can be run by nonprivileged users. We all need to work toward a development environment that supports nonprivileged users so that we can change the culture for new programmers on this platform.

The best way to build software that can be run by nonprivileged users is to run as a nonprivileged user while you write and test the code. This is known as eating your own dogfood, a technique that has been used for years by good coders.

I have a dream. In this dream I can run as a normal user and all the software I install runs flawlessly. I can develop code easily as a non-admin, and I'm not constantly distracted by security barriers. I believe we can get there, but we need to work together to make it happen. HowToDevelopCodeAsANonAdmin will show you how easy it is to join the growing revolution yourself.

PortedBy KerryJenkins