In the classic Mac OS (as with DOS), there was no concept of users or security. Users launched applications that could do anything. The system couldn't prevent users from deleting or overwriting critical files, and any application could stuff the System Folder full of Extensions that directly modified the system.

While a clean Mac install was pretty stable, once enough junk was installed, the system would lose stability and frequently crash, losing all unsaved data. It provided unbounded freedom through anarchy, and traded off security and stability for convenience and simplicity.

As computers joined networks, they were exposed to real external threats that demanded more attention to security. Unix, and later Windows NT, took somewhat similar approaches to providing this, by handing authority to a privileged kernel that preemptively scheduled tasks, restricted access to protected memory and other hardware, set ownership and permissions on files, and defined users with restricted privileges.

The capacity for restricted users allows applications and processes to run with the least amount of privilege necessary, so if they are compromised, anything that takes control is restricted in what damage it can cause.

Limited user privileges act like janitors in a high security building; they have enough security clearance to do their work, but are restricted from areas they don't need to enter. If someone were to steal their keys, they would still only have limited access within the building.

"Least privilege" is an important security principle that is poorly implemented in Windows. Part of the problem is sloppy programming by application developers, which demand excessive privileges when installing applications and consequently require users to have administrative privileges simply to run them. In Windows, the janitors have keys to everything. Pick a janitor's pocket, and you have free run of the entire building.

One method for making 'least privilege' feasible in Windows is the secondary sign-on feature. In Windows, a user can right click on an application and choose "Run As..." to execute the program as an administrative user, but this also runs the application in the admin user's environment, so that program can no longer see or access the current user's shares, personal files, or mounted drives. This frequently leaves the application improperly installed for non-admin users.

Running Windows under non-admin accounts is so difficult that one "Windows security expert" suggested that the idea of least privilege is a "red herring," and basically concluded that, since Windows' fragile notion of security is so easy to exploit anyway, why bother?

If Windows apologists demanded better security from Microsoft, instead of making excuses for the Church of Redmond and indoctrinating sheep-like submission into the Windows faithful, perhaps Microsoft would consider security a more important feature.

Another problem with using secondary sign-on, or "Run As...", to achieve least privilege is that the Windows interface confuses the definition of an application. Sometimes a control panel is a folder, sometimes its an actual application, sometimes a shortcut.

Sometimes what appears to be an application is a plugin embedded into the Microsoft Management Console, and sometimes an application is only presented when you click a button in another window. How do you right click on an application to "Run as..." if the application isn't presented in the interface?

It's not like you can browse the computer to find the application; that's off limits in Windows. And good luck doing a search; Windows' search function is a long joke with no punch line. You are only presented with the Program list in the Start menu, which is something akin to the Mac OS X Dock, but more difficult to customize, hidden away in the Start menu, and presented as a series of deeply nestled sub menus with maddening delays.

In Mac OS X, anytime you start an application, it appears in the Dock and changes the menubar; you can right click a Dock icon and ask it to "Show in Finder." Were it only so simple in Windows!

The main point however, is that in Mac OS X, non administrative users can install applications locally in their user context. You can theoretically do this in Windows, but installing an application for a single, non admin user is frequently broken in practice. Trying to run Windows according to least privilege policy is difficult at best, and often simply considered impractical, so nobody does it. This leaves Windows users unnecessarily vulnerable.

Next:

• iPods and Mobile Devices
• Open Source and Development
• Wishlists and Product Concepts
• Product Reviews and Comparisons
• Unraveling Tech Myths
• Deconstructing Tech Analysts and FUD
• All Articles
• Hide Article List