DrunkenBlog

Yin & Yang

Some users get a bit of sick joy when it comes to bashing Microsoft on security, but like most spewing demagoguery they're generally leaving out the context, and no matter what the subject, context is important. Without context, it's very difficult to learn.

I encountered a user like this the other day, gleefully gloating over a user who found they'd been infected with some spyware like a monkey throwing its poo at the zoo. This really left a bad taste in my mouth, and since it's been awhile since I've had a long, half-baked stream of consciousness on the blog, here we go.

Microsoft gets bashed on security all the time, which isn't really all that surprising and truth be told the slams often have some merit. You often hear the same phrases repeated over and over. A common one might be "Only Microsoft could make x insecure", which this particular user kept saying, but he kept saying something else that stuck in my head: "Inherently insecure".

For now we'll leave out the phrases questioning a product's sexual orientation, the moral purity of the company or the marital status of the mothers of the programming teams during their conception for later, as the anthropomorphization of a corporation while simultaneously dehumanizing those who work within it is beyond fascinating and deserves it's own future post.

I mentioned the term 'Inherently Insecure', which is often bandied about regarding Microsoft, and it's worth noting that if something is able to be classified as 'Inherently Insecure' something else has to be 'Inherently Secure' on the chart. Since there is very little, if anything, out there that can be deemed 'Inherently Secure', using the phrase starts to look a bit silly.

However, if you quantified it as 'Inherently Less Secure', things start to get a bit more interesting. You could certainly classify Windows in many cases as being inherently less secure. While there are tons of breaches and root kits and the like for flavors of *nix, there are few viruses and worms, and just about zero Malware.

The vast majority of Malware, viruses and worms doesn't come about via technical inferiority, or even the other platforms being inherently more secure. As I've gone into in other posts, this is a product of having the biggest back with the target on it on the desktop. But what this doesn't explain is the ease of which much of this crap gets onto Windows boxen, or how often it's the exact same types of attack vectors used over and over in various ways.

Something that can be hard for Mac users to wrap their heads around is that when you get down to it, Windows and OS X are more alike than they are different. Seriously. And where they are not as alike as one would expect, it has generally been a conscious decision on the part of Microsoft, and not some basic functionality they just couldn't be bothered to impliment.

The big thing Mac users crow about with regards to OS X is "It's based on *nix, so it's much more secure." That's fine to say, but what does it mean?

At it's most basic level, what *nix brings to the table is a set-in-stone multi-user permissions system. In terms of how it's built, there's nothing major there. Mac OS X is a combination of C, C++ and Obj-C, none of which are memory managed to avoid things like buffer over/underflows. Windows is a similar combination, although they're working very hard to transition the most at-risk pieces of code to a more secure way of doing it and, if I had to hazard a guess, is one of the main reasons for many of the Longhorn delays.

It all comes back to the multi-user permissions system that is locked in, and just plain expected. That permissions system, in terms of security, sets something a *nix apart from Windows in terms of inherent technology. This is a fairly basic concept, and just means not everything runs with the same privileges. When the OS loads something into memory, it has permissions assigned which tell the OS what that bit of code is allowed to access. A user has certain privileges, an administrator has certain privileges, and there's often a 'root' account (or equivalent) which has access to everything.

The origins of the system go way back to the time-sharing days of mainframes, where you'd literally have a whole group of people working on a computer at the same time. There are some great stories from this era, but the bottom line is they had to share the resources. User x wouldn't necessarily want user y to be able to modify his programming project, and if user z was running a long-term simulation he'd be pretty damn pissed if user x brought down the whole system.

So user x can't just type shutdown and kill the whole system, and they can't access files they don't have the privileges for. In terms of Malware, this doesn't mean user x can't completely destroy his own data by introducing something bad, but unless the Malware is able to exploit another flaw to escalate it's privileges, only that user should be affected.

Which isn't to say this is the end-all-be-all of security... with something like OS X, as it currently stands, the system isn't that fine-grained.

Let's say you have something like Apache running as a web server, serving out lots of virtual websites. 'Virtual Hosts' are what allow you to have ungodly amounts of sites on one server, and as far as the system is concerned are the equivalent of users. This is so that, ideally, person x can't FTP into their site and then have access to person y's files... that sort of thing.

But Apache needs to have access to them all, as well as higher-level files that no other users can get to to do things like write to its log files. In order to be able to do this, Apache has to have escalated privileges, which is about the same as saying Apache is running as the equivalent of 'root'. Apache is just one of many examples you could give, but it poses some real problems. Namely, if you are able to exploit Apache, the system is your playground, because of what Apache is able to access.

Another similar problem is if you have a user whom you want to be able to access something that is privledged, but not everything else. There are lots of hacks around this, but they're pretty much just that, hacks, and why you are seeing projects like SELinux, SEDarwin and others coming about.

Mac OS 10.4 will bring with it things like ACLs (Access Control Lists), which give some of the same capability... namely, finer grained control over what users can access in a more streamlined fashion. Apache doesn't need access to everything in order to do what it needs to do, it only needs to be able to access a few type of directories throughout the system. Using some of this finer-grained control means that if Apache gets hacked, its only able to do bad things in what it's been given access to.

Right about now there are some Windows users going "What the hell DB, Windows does so have permissions", and they'd be right. The problem is that Windows doesn't exactly do a bang of job of imposiing the paradigm on your average user.

This would seem to be a no-brainer, but to really get a handle of what's going on you need to have a handle of where Windows came from.

I mentioned that Windows and Mac OS X are more alike than they aren't, and in all honesty, of all the 'modern' OSs, Windows and OS X are probably the most alike. In fact to a degree, you could make a damn good argument that Windows could be called a *nix, even if it's not actually on the family tree. It all depends on how you are going to choose to define a *nix.

Interestingly enough, what makes something a *nix seems to change as things people didn't like got closer to what the previous definition was... kind of similar to many creationist theories. I.E., "The existence of x proves intelligent design.", but then once that has been explained, the proof becomes the existence of y.

At the kernel level, the differences aren't vast and certainly aren't show-stoppers. WindowsNT even started lift as a micro-kernel OS, only to later start moving things into the kernel area to create something that is more of hybrid of micro and monolithic kernels... just like OSX.

They even went and implimented POSIX APIs, which are essentially a whole bunch of standard APIs and such you have to impliment if you want to be able to say you're a 'Unix' OS. Long and short, Unix APIs were becoming a mess, meaning the APIs (Application Programming Interfaces) you programmed to on one Unix weren't guaranteed to exist on another... so POSIX was devised. Impliment all the POSIX APIs, get certified, and you were considered to be a 'Unix'.

We have to go back yet a little further to really get a handle on what was going on at the time, and remember that the core technology behind the current Windows was developed quite a long time ago. Microsoft was designing winNT back in the very early 90's, I believe it was announced in 1991, & WindowsNT (NT=new technology) was released in beta in 1992 with a full release in 1993.

For comparison, Apple started working on the ideas behind 'Copland' in 1989 and shipped System 7.0 in 1991... although the ideas behind Copland and Gershwin weren't really formed and announced until almost 1995.

WindowsNT was Microsoft's first full 32bit OS, and was originally supposed to be based on IBM's OS2/Warp technology. Whole big bullyhoo about that which I'm not going to go into, but it was a big deal for the company and a big contrast from their previous DOS-based offerings.

I say previous in a forgiving sense, as from the start Microsoft took a two-pronged approach with NT, keeping around the previous OS offerings for consumers and compatibility while NT primarily focused on the workstation and server market... with the goal being that eventually the NT kernel would become the base of all their offerings.

There were some pretty stark contrasts in the computing world, with NT being very much about the kernel and capability, and not, say, eye-candy. Windows 3.1 had been released in 1992, and WindowsNT didn't differ signficantly from it in terms of GUI. Apple in 1993 and 1994 was still working with System 7.

Microsoft deserves a fair shake here. At the time, creating a brand new OS was becoming a tall order. Apple bought NeXT in 1996, but didn't ship MacOS 10.0 until 2001, and it's hard to call that a solid release. Midway through 2002 brought MacOS 10.2, which while you could make the case that major components of OS X were still AWOL, was probably the first release that was approaching something coherently solid.

Personally I'd say 10.3 is where I'd make this cutoff, but many would say 10.2... and some would say 10.4 and I wouldn't really disagree strongly with them for it. Which means depending on how you look at it, it was either 6 to 7 years to almost a decade or more from the time Apple bought their OS from NeXT until they had something solid that the majority of their users could were good to go on.

In contrast, many would say WindowsNT 4.0 was when Microsoft hit that point technologically, with many saying Windows 2000 was where they hit that point in terms of compatibility, with WindowsXP being the endgame. WindowsNT 4.0 shipped in 1996, with 2000 shipping in, well, 2000, and WindowsXP shipping in 2001. Depending on how you look at it, Microsoft either took 8, 3, or 9 years to get to around the same relativistic place.

There are some caveats, though, which are worth noting and level the field a bit into Microsoft's corner. There was a good four year gap between WindowsNT 4.0 and Windows 2000, but at the time WindowsNT existed on something like four different hardware arches: MIPS, PowerPC, Alpha, etc.

I remember this well, as I remember the print shop I worked at chucking their MacOS-based server for an ungodly expensive box running WindowsNT 4.0 with a DEC Alpha chip in it.

It also needs to be quantified that Apple also bought their OS, and then shoehorned new stuff into it, whereas for all intents and purposes, Microsoft built a very technically impressive kernel, in a relatively short amount of time, from scratch. There is speculation that they may have used code from the next-generation of VMS, and probably some truth to it, as we know they used some code from other places... but at the end of the day this was still one hell of a serious effort. An achievement, even.

That print shop I mentioned didn't start yanking all the infrastructure out from under the Mac workstations because Macs were more expensive, it was doing it because while it had its issues, WindowsNT was a serious contender and the Macs simply couldn't handle the workload in a sufficient manner. Their only option at that point was WindowsNT or a Unix variant, and while the Windows boxes weren't cheap, when it came to getting support and even intial cost... Unix was expensive as hell.

There are a lot of things you can bash Windows on, but again, the NT kernel was a solid foundation and a serious effort. You can have specific grievances between how it handles things and how the Mach kernel handles things or how the Linux kernel handles things (I'm going to leave out Solaris as we're primarily talking end-user) but for each one you could find a vice-versa, and they are all things that could well be changed with some work.

You'd be hard-pressed to call the NT kernel an 'inferior' kernel, almost everything you could bash it for has to do with configuration and not capability. Which brings us back to the multi-user permissions stuff, and why it's not enforced as many would prefer.

With such a technically advanced OS, especially for the time, it would seem to be foolish not to push it... and, well it was, just not on the workstation side.

Most of the multi-user stuff is enforced in the ways you'd expect when it comes to people accessing the server over a network, like say, an intranet or anything you can think of. We're primarily talking about this at the workstation/personal user level, for which you have to have an even closer look at the lay of the land when NT was birthed.

A standout reason for NT being 'lax' when it came to enforcing permissions was that, quite frankly, permissions and multi-user paradigms absolutely suck for your average user.

When Microsoft was looking at creating NT, they turned a heavy eye towards Unix and said:

• Protected Memory: "Our users will love this!"
• Pre-emptive multi-tasking: "Our users will love this!"
• Multi-user permissions system "Our users will hate this!"

It has to be said: multi-user permissions systems are a pox upon usability and are an easy way to warp a users head. Chances are if you're reading this, you have at least a mild understanding of them. But your average user is completely lost, don't understand them, and are just getting by.

In terms of usability, most of the history of personal computing has been about abstracting older concepts to better empower the user.

Pick any example, from the false notion of a 'directory' (which is really a file pointing to other files) to the GUI itself... it's all been about absctracting what the computer is dealing with in ways that a human can better deal with it, while rapidly flattening out the learning curve. Multi-user permissions systems, as they currently exist, roll back a big portion of that.

Take the most clueless Mac user, the ones who need the knowledgebase article on how to pick up their iMac G5, multiple their numbers by 1,000, and you start to have an idea of what Microsoft was looking at and what they were afraid of and what they wanted to avoid.

In all fairness to Microsoft, there's evidence to back up their reasoning. With the move of Mac OS X, Apple lost untold amounts of users who looked at OS X, didn't understand it, and decided if they had to pick between two competeting OSes that seemed like voodoo to them, they'd just as soon go with the cheaper of the two.

Relative to OS X, things in the 'Classic' Mac OS were relatively simple... you had one of everything, you could do anything. Want to uninstall a control panel? No problem, you went to the 'control panel' folder under the 'system' folder and removed it. In OS X, assuming you have one user setup, this 'control panel' equivalent can be in one of three places.

Same deal, if not actually worse, for fonts. Want to back up your entire system? Drag and drop. Of course you could actually drag the entire system to the trash, but the OS never really told you 'No'.

While your average Mac user was relatively clueless about what was actually going on underneath all the prettiness, they were empowered by the abstraction. With a few quick troubleshooting routines under their belt, most of which were dead simple if pure drudgery, your average designer or home user was able to troubleshoot their system in a meaningful way.

The contrast to OS X is brought into sharp focus by a very simple function: printing. Printing, once a huge bullet point on the Mac, became a hair-pulling experience with OS X. Some installer here sets some permission wrong there, and suddenly a user can't print correctly and they're told to run repair permissions 100 times, as well as downloading 3rd party utilities which might be able to do it better.

Yes this has improved somewhat, but not the root cause of it... your average Mac user now sees the workings of their computer as a form of voodoo, and just sort of get used to ignoring the stuff they don't understand. Many, many Mac users wanted 'OS9 + preemptive multi-tasking + protected memory', not something that felt like a prettier version of Windows.

Mac users used to joke about Windows needing an 'uninstaller', while they could just drag something to the trash, but this is quickly becoming an untrue concept for a lot of software. Pick any particular program on the Mac, and your average can only make a best guess as to where the hell it's writing out it's data and preferences files.

Everything I know points me towards Microsoft going into this with relatively 'good' intentions: locking the user down with crazy permissions was something that originated on time-shared mainframes, not personal computers, and their goal was to bring the power of the mainframe to the average desktop, without the crap for a single-user OS.

At the time, they were taking out ads in newspapers about NT claiming "A better Unix than Unix". While some of this was due to just how far behind *nix of the time were in terms of GUIs, a lot of it stemmed from the crap they weren't making you go through to get the benefits of 'Unix' while not having to deal with the other crap.

From a support and usability POV, Microsoft didn't want you to have to deal with having to run permissions are a religious ritual. They didn't want the user to have to install their password 50 times or have to click 50 dialog boxes whenever something changed.

And they weren't really alone in wanting to make everything user-centric... if you look back at the same time frame, where Apple was going with their 'Copland' OS and Microsoft was going with their OS were very, very similar in terms of features and focus. Oddly enough, when you give very smart people with similar backgrounds a similar problem with similar constraints, they have a habit of coming up with very similar answers.

We all laugh at the 'DLL Hell' that Windows users have been forced to contend with, but Copland had a very similar shared-library feature it planned, simply because at the time it seemed like a worthwhile trade-off for the hardware everyone was having to contend with.

Copland's was probably even more complicated, mainly due to some backwards compatibility insanity. This stuff crops up across the board, and similarly Copland wasn't being designed to stand up to modern threats. This was just the mindset of the time: bringing 'mainframe' features to a consumer OS.

So here we have the first design tradeoff we're going to talk about that has arguably come around to bite Microsoft in the ass. It was arguably the wrong call, but was it a bad call?

We have to remember that there were two main segments the 'NT environment' was focused at, and while allowing for overlaps and subcategories, it basically boiled down to 'workstation' and 'server', while Windows98 and WindowsSE took care of the consumer. Eventually WindowsNT turned into Windows2000, which in turn turned into WindowsXP, finally becoming bringing most consumers onto the NT kernel.

Again, the WindowsNT 'experience' was primarily designed for a single-user sitting at their computer and using it. It wasn't really designed to be a multi-user OS, nor a network maven... and again, this is separating out server offerings from what someone is playing Doom 3 with.

Which isn't to say their server offerings were particularly locked down, but rather the expected environments that have caused problems for both the consumer and server offerings have something in common: who was expected to be knocking on doors.

WindowsNT+ was entirely designed to be able to handle networking, however we have to remember what most networks were back then.

Around 1993, when NT was first introduced, the web browser Mosaic was first released, which brought with it the capability of actually viewing images and other content on the web on a variety of platforms, but remember the web itself was only created in 1991. The US White House wasn't even online until 1993, the same year Internic was formed. If you want a real trip, feel free to take a look at where the Mac was regarding TCP/IP in 1993... In 1994 Apple launched the ill-fated eWorld, shutting it down in 1996: less than a decade ago. At the same time, AOL hit 6 million members.

Around this point, the web was growing like a monster, seeing something like 340,000% growth annually, with even the Gopher protocol seeing annual growth of ~1,000%. Netscape went public in 1995, and Microsoft licensed the core of what would be Internet Explorer 1.0, already reaching v3.0 in 1996, v4.0 in 1997 and v5.0 in 1999. These were heady days for the internet, but they were also heady days for MacPPP, ISDN lines, etc.

In those days, something like the incredibly popular SupraFax 14400, which for around $300 in 1991 ran at 14,400 bits per second and let you fax. But the majority of users were still at 2400 baud or, if they were lucky, 9600. It wasn't until the late 1990s that the 56K *cough* standard was set upon the world, and it isn't as though everyone upgraded to 56K overnight.

Viruses were a problem for users at the time, but they were primarily the stuff of boot-sector viruses infecting systems via promiscuous floppy discs. On the Mac, you had things like CDEF viruses. You got your shareware from friends, by having it included with a magazine, or possibly a BBS. Your OS updates consisted of "Disk 14 complete, please insert Disk 15".

Your computer might well be on a network, but 'high-speed' internet connections were an misnomer for preponderance of the population. In 1999, 60% of Internet users were on 28.8/33.6K modems or less, with the rest being 56K and around 5% having any form of a high-speed connection, which at the time was anything about 56k.

As late as 2003, something like 90% of those in the EU were on dial-up speeds. And as I mentioned, in 1994 AOL had six million subscribers: by 2002 they had 28 million, all primiarly modem-based... and have been dropping subscribers since. Some of AOL's subscriber loss is due to increased competition as consumers have become more aware, but a good chunk of it has been due to users gravitating towards high-speed connections which were exploding with the advent of cable modems, DSL and satellite.

In approximately 3 years (2003), high-speed connections went from 5% of the market to a bit over 30%. As of November of 2004, broadband penetration had reached 50% of the market. The rapid growth of high-speed connections, much of it occurring in just the last few years, has done more than put the crank on AOL's subscriber base... it's exacerbated every single problem on the security front, in a relatively short amount of time.

Everything changes when broadband (and I use the term loosely) is involved. It's hard to get around that it's a huge catalyst for both good things and bad. The first thing that might come to mind is the speed of the pipe the machine you've just 0wned is sitting on, but there are other aspects.

A big one is the likelihood of the machine having a static IP versus one that changes every time you log in, as well as the fact that many, many home machines are simply always connected.

'Always-On' comes with a trade-off: the user is always connected and gets that convenience, but, well, the machine is always connected and taking knocks on the door. Broadband has both drastically lowered the barrier to entry to accessing a machine while dramatically increasing the reward after you've done so.

And, in an ironic sort of way, the big multi-user permissions gap doesn't really play that great of a role.

The dirty little secret about multi-user paradigms is that, as they currently exist, for most users they're of little to no value when it comes to the problems they're facing.

As mentioned, MU paradigms are designed to the keep the system safe, and to minimze the damage one user can do. The 'system' is of very, very little value to most users. All of their value is locked up in their 'user' files: their music, their term papers, their emails, their IM histories, their images and their movies.

Many boxes out there have multiple users accessing and using them, and an easy example is a home computer with a parent using one account and the teenager using another. However, there is no getting around the fact that the vast majority of 'user' machines are the equivalent of single-user machines, even the ones with more than one person accessing them.

In the majority of cases, especially for those who are the most 'at risk', there's really no mental distinction made between the 'system' and their files, and whatever mental distinction you try to impose on the situation is doomed to failure. It's all well and good to have firewalls in a building to slow the spread of the fire between all of the rooms, but it makes little difference when all you have is one damn room.

Sure, you can lock the 'user' out from the equivalent of a program like 'sendmail', but that's the wrong mindset for the environment you're dealing with when it comes to users clicking.

Malware might not be able to get into other accounts without extra work, but chances are those accounts don't even really exist. You need to worry about malware pimping spam out through Outlook and scraping its address book. Outlook got itself hammered down, and various malware got around that straight quick by simply including their own email engines of d00m.

Again, as far as the user is concerned, their environment is the system, and once something nasty is in their environment, their entire world is now its bitch. Yes, it might not have access to rest of the system, but that's irrelevant to them. The 'system' is background; everything they actually care about has just been raped.

Which isn't to say that historically it hasn't been a little too easy for certain things to happen on Windows. Having a website automatically modify your registry to make itself your homepage is a good example, which is something we'll get to.

Still, while we can say that the MU-paradigm is way, way overrated when it comes to keeping your average user environment safe from all that ails it, it's obvious it's getting in and in what is arguably a disproportionate manner.

It's often argued that Windows has 'disproportionate share' of security issues. I'm not saying it doesn't, but I will say it's not as clear-cut as it's often made out to be.

As the argument goes, if Microsoft has 90% share of the market, and 500 vulnerability bulletins/viruses/malware/what-have-you over the course of a year, then something with 5% of the market should have 25.

If that something with 5% of the market has 5, or 1, or even none, then logic would dictate that Windows has a disproportionate share of badness... and hence there's something wrong with it. Sometimes there's real truth to that paper napkin formula, but often times things are much more complicated.

The complications arise from variables that one platform might experience that another doesn't, such as the proportions of types of users making up the base of the platform.

I.E., script kiddies don't gravitate towards eMacs, and it's one thing be a Windows user exploiting some PHP authentication code on a Linux box, yet quite another to write a piece of malware for a platform which you have no ability to actually test on. Just like novels, authors generally write what they know.

But perhaps the most crucial, yet elusive variable that is missing is the idea 'critical mass'. This is somewhat entertwined with the above, but is also a distinct issue. At it's simplest, the idea is that you need a certain amount of something in order to see real movement.

In nuclear terms, the idea is again basic: you need a sufficiently large amount to get a sustained reaction, and once you've breached that barrier you can be in danger of the reaction growing exponentially... but without that critical mass nothing really goes boom. This doesn't mean things aren't dangerous, it just means the proximity of the two dangers aren't within the same time zones.

Once you approach that critical mass of eyeballs looking for problems, and users waiting to have their machines violated, things get very, very messy. Much of it has to do with bang-for-buck, much of it has to do with market share, and the basic concepts are something I've covered before.

Put some econ, comp-sci and sociology guys in a room and I'm sure you could come out with a tidy formula, but the idea is very sound and seen throughout the computer arena in general, and there's no reason why this should be any different.

Even so, putting arguments about disproportionally aside, it's hard to argue that a lot of stuff is getting through... which we'll get to shortly.

Here's an simple idea: for something bad to get in, it has to have a door, although often times it find the equivalent of a crack and brings its own crowbar.

Either way, for a machine to be violated, something on the machine has to be accepting data, and anything accepting data is at risk. In the good old days, most machines were accepting data on a type of physical medium... diskettes, CD-ROMs, etc. Today on a typical computer, this basically boils down to two main areas:

• Things that are listening
  'Modern' Operating Systems often have processes that are running in the background acting as services for other processes. You might automatically think of Apache or a File Sharing protocol like AppleTalk, but it's often broader than that. There are often services that run that normally are accessed locally, but can be accessed via a network.
• Things that are requesting
  This is basically anything that is actively asking for data and then doing something with it. For a normal user, this is often going to be in the area of email, web browsing, RSS, IM, etc.

Things that are listening generally need to be closed off so that they can't hear, and subsequently be tricked, by the outside world... generally through a firewall. It would seem to make absolute sense to automatically have a firewall up and running, but the problem with this is that it gives convenience a bitch slap in a big way.

As a quick review, there is the equivalent of a traffic-cop built into every computer, one that directs traffic to the service it's supposed to get to. I.E., you have one internet connection coming in, yet multiple streams of data. This is handled with a virtual 'ports' system, which are basically doors that different services bind to and actively listen on.

I.E., web traffic generally comes in over port 80. If you have Apache running serving out web pages, and a tickle comes into your IP with port 80 specified, Apache takes a look and does what it's supposed to. If port 80 is blocked via a firewall, Apache sees nothing from the outside world.

With a firewall like the Mac OS X default, you can block port 80 and still browse the web, as it really only blocks inbound connections, not outbound. So you can send a request out through the firewall, and then receive the reply... but anyone trying to initiate something on port 80 is stopped cold. There are cases where you'd want both inbound and outbound blocked, but the OS X firewall just isn't that configurable.

Other firewalls will default to blocking both inbound and outbound, which is generally more secure, but generally less convenient. All different types of services go in and out over various ports, including things like instant messaging.

All of the various chat clients uses their own standard set of ports to communicate to their various servers, and if they find them to blocked both inbound and outbound will usually try to drop back to port 80 and go out over http. This isn't ideal, but it often isn't blocked.

This wouldn't seem to be a big deal if you aren't blocking outbound, but it still causes problems. I.E., your chat client might have no problems getting an outbound connection to the server on the port it wants, and then receiving data back. However, when you start trying to transfer things between yourself and another client, they often try to connect directly to each other to avoid going through the server, but find they can't do so because incoming connections over that port are blocked by the firewall.

At around this point, the user is confused and close to crying while trying to follow relatively arcane instructions on opening up ports in their firewall the some app's support website.

The above is literally one example out of thousands, perhaps tens of thousands. In this age, most users are going to want to use their computer for accessing some type of a network, and due to the way most of the services over a network work, this means they're going to end up fiddling with a firewall.

Pick the most clueless person you know, then imagine them trying to grok fiddling with a firewall. It isn't a great mental leap to imagine the increased burden this adds in terms of support and troubleshooting.

If you've gotten to this point, the idea that convenience comes at the cost of security should slip deftly into place in your head. Chances are it may have been a concept you've heard before, lord knows it's not something I made up.

It's a simple tradeoff; the more secure you make something, the less convenient it will be. And, like most of tradeoffs, there are very few exceptions to the rule.

To give an example, an eight-character password is much more secure than a four-character password, yet much harder to remember. If your computer required you to enter two separate passwords before you did anything, it would again be much more secure, but again more of a hassle.

If your computer required you to enter two passwords, plugin a dongle, then required your thumbprint, then a retina scan while a second person turned a key in exact time with your own from ten feet away, it'd be even more secure. But that would be a hell of a lot to go through to get your email.

These types of tradeoffs are things every group (hopefully) deals with when they are creating a product.

In Mac OS X, it defaults to logging in the first user created automatically. Even if you specifically tell Mac OS X to make you login specifically, it defaults to showing you the available user names on the system. It's not as secure as requiring the user to enter a username and password, or even just a password, but it's a lot more convenient for your average user. Examples of the Yin & Yang of security are pervasive through just about any modern OS.

Apple could default to turning all of the above on in OS X, while also enabling the Open Firmware password stuff (it's possible to set OF to make your machine ask for a password before any OS boots) but it has to be weighed with how many users are going to log in and turn it all off.

This is somewhat at odds with the idea of 'sane defaults', because unfortunately, just like in real life, sanity has a habit of being relative.

Someone creating a product has to look at the blurry line between convenient and secure and decide where their product is going to drop, with the caveat that they are in a competitive environment. If your competitors product is much easier to use than yours, albiet less secure, you'd be surprised at how often convenience wins out in the users' head, and it shouldn't surprise you that those creating a product in trade for cash often err on the side of caution when deciding where to drop their app.

Earlier we went through some of the protection a MU-paradigm paradigm provides, and we need to explore just how WindowsNT operates to get an idea of where some of the fundamental problems are.

I mentioned several times that NT+ has the same sort of permissions style systems that the various *nixes have, but that they aren't really imposed. This is already long enough, so by necessity it isn't going to have the kitchen sink, but it should give you the idea. Part of the problem is that the terminology between the systems doesn't quite match up.

In a system like Mac OS X, and some of the newer Linux distros, the default user is called an 'administrator'. Some of the capabilities get blurred between what a 'historical' administrator might be able to do, but suffice to say they're able to act globally through the command line interface via the use of a sudo command after they've given their password.

If they are doing something via the GUI they don't quite have the permissions for, they are presented with a box to enter their password. They have problems doing things like accessing other users files, however without logging in as that user, either via active user switching or logging out their current user.

There are other oddities with the paradigm... an administrator password will work to login any of the other users, which makes a sort of sense if they're an administrator, but that administrator can't by default just mess around in a different users files... but I digress.

Windows is a little different. An administrator can, for all intents and purposes, do just about anything. This is the default type of account created. There is also what's called a 'limited' account, which is, well, limited in what it can do system-wide in terms of settings and files. However, there isn't really a 'sudo' functionality built in via the GUI, where if the user does want to mess with things globally they can by entering their password. They have to log in as an admin user to do what they want, then go back to the other user.

All the protections we expect to be there for an MU-paradigm are there, but while a lot of people do take the time to setup their system this way, the vast majority don't. It's not only expecting someone to go above and beyond what a normal user is capable of, it's honestly damn inconvenient. This is a real problem, and something that needs to be improved, but it isn't nearly the end of the world.

No, the checkmate for running as a limited user is, more often than not, limited by third party developers. An application following Microsoft's guidelines should work just perfectly as via a limited user account as well as being run by an 'administrator'.

There are a ton of reasons why you'd want your app to be kosher in this sense, not the least being using it remotely and forward-compatibility. There are some times where an app just needs to be installed and run as the equivalent of an 'administrator' in Windows, but not nearly as often as it is required.

Mac users are no stranger to apps that inexplicably seem to require more than they should need to get the job done in terms of privileges and other things. When you speak to the developer of the app in question, there are usually a whole slew of reasons as to why they are doing what they do... and they're often not because it's absolutely necessary. Mac OS X as a platform also isn't a stranger to installers that have been known to mess up permissions that other apps expect to be a certain way.

"Why the hell does this require a reboot?" is an often-heard phrase in the Mac world, and chances are whatever you are installing doesn't really require a reboot to use it... but there might be some little bit that does, or they may have just found they save support costs if they require the user to reboot.

This is an area where Windows can seriously learn from the way other OS's do things, but at the same time it's not just a Microsoft problem, but also a third party problem. It might seem to be easy to say screw the third parties, but while Microsoft is King, Windows is generally a background thing to most users.

The breadth of software catalog is a huge deal on Windows, as is backwards compatibility. Lots of older apps will simply have problems running in a limited environment, and users first and foremost want their apps to work.

And before you get ready to string Microsoft up for bowing to backwards compatibility over security, it's worth noting Mac user's own brush with a similar issue recently that encompasses many of the issues we've gone through as well as a few we'll hit shortly.

Backwards compatibility is a big deal on any platform with a sizeable number of users. Bowing to backwards compatibility and third parties is almost entirely responsible for the entire set of 'Carbon' frameworks in Mac OS X, but for the purposes of this point we're going to single out LaunchServices.

There's a framework built into OS X that allows you to register your application with the System for various purposes. The system stores this info in a database that lets it know which apps can open a .JPG file, among other things. This usually happens when:

• The system is booted
• A user logs in
• When the application registers itself via the finder, like when it's mounted from a disk image

The system also has certain routines for how it handles URL protocols, like so: http://, disk://, telnet://, ssh://, help:// and others.

Long story short, the combination of these two bits of functionality caused a huge hole in Mac OS X. The user could be viewing a webpage while a disk image was mounted and it's payload registered with the system, and then was called by nastiness embedded in the browser. If this was Windows, machines would still be being violated by this.

This was a serious thing, and took a lot of Mac users by surprise... it's just not the type of thing they're used to dealing with. Various third parties started stepping in with home-brewed solutions to the problems involved.

Apple took awhile to get their fix out their door, and it's not surprising as they were faced with conundrum and none of the solutions were honestly ideal.

One option would have been to pull the functionality altogether, after all, sometimes just because you can do something doesn't mean you should. But backwards compatibility issues with this would have been huge. Huge. Like I said, this was pervasive - way too much stuff depended on how this service worked, but this service didn't expect to be attacked from this direction in this new hyper-online world.

Their solution was lackluster at best; now, whenever an application tries to register itself, you get a dialog box saying "Blah blah blah will be opened with blah blah blah, are you sure this is what you want?" You then have to click 'OK'. This stuff is cached, so it's supposed to only happen once per app, but still convenience takes a big hit.

I'm probably on the most annoying end of the scale, as I'm often blowing away caches and cloning data between machines, so I have a nice little festival of clicking every time I do so whenever I try to open files for a few hours.

The functionality built-into the system just wasn't ready for the Internet onslaught. Their fix was not ideal, and it was downright hacky.

I find the situation to be highly unamusing and inconvenient, but Apple's options were fairly limited. Removing the security problem would have removed a ton of functionality that not only makes other things more convenient, but that a lot of apps depend on.

That, unfortunately, is the real world... there aren't ideals, but rather compromises we're forced to live with based on decisions that were made on a different set of conditions than what we're currently faced with.

As a quick aside, because we just touched on it and it's worth concreting in one's brain: The more features you add to something, or the more complex you make it, the greater the likelihood that you're introducing security problems.

This isn't just because of the extra code, although that's a factor, but also the unintended consequences of how what you've introduced can interact with what's there and what may be there in the future.

You can sit down and audit code, trying to find obvious things that are going to cause flaws, like buffer under and overflows. Unfortunately it's extremely difficult to sit down and try to figure out how hundreds or thousands of different things are going to interact and what problems they might birth.

Chances are you're going to be hearing a lot more about this concept as we move to more managed-code environments (Java, C#, etc.) for high-risk services. Intrinsic flaws in code will still exist, but a lot of the really obvious ones will disappear... but as we all know software doesn't have a habit of adding fewer features, and all of these features are interacting more and more.

The more things that something interacts with, the more 'at-risk' it becomes, and the more 'at-risk' everything that it encounters becomes.

It's hard to get more at-risk than the Internet Explorer engine. Internet Explorer doesn't have a lot of love outside of the Windows domain, although to be fair to it a lot of the hate is fueled by just how powerful it is in the market and the inconveniences caused by not having it available. However, it's hard to argue that Explorer has been the cause of way more than it's share of trouble.

Earlier we mentioned that in order for a machine to be violated it has to be accepting data in some form or another, and Explorer in one form or another is at the heart of that. Not just via browsing the web, but because it is embedded in the system, lots of other apps depend on it for tons of functionality.

If there is a problem with the Explorer engine, then there is a problem with a ton of apps because they depend on it for functionality. And there have been a lot of problems, and every time there is a problem it's exacerbated by the pervasiveness of IE.

Internet Explorer is at the proverbial vanguard of security for Windows, yet when it comes to security, it's historically been one of the weakest parts... why?

Here's a secret: developers hate putting out a bad product, and Microsoft has some of the best developers in the world. Get over it. Apple and others don't have a monopology on geniuses, hell half the people from the days Mac users like to muse about the most now work at Microsoft in one form or another... and no, they aren't all working for the Mac BU.

As we went over earlier, there was a time when the web started to explode. Microsoft, for it's own reasons, wasn't a big fan of this at first. While the writing was on the wall to some, Microsoft made what are in hindsight some bad decisions about how big the Web was going to be. Once the internet ran out of wall, it started writing itself on Microsoft and they woke up very, very quickly and reoriented the whole company around all things web.

This involved buying the basics of what would become the Internet Explorer engine, and building it up and out as fast as they could. Their main competition at the time was Netscape, who was rocking the world hard through their IPO... the race was on. Oh how people laughed at those first few versions of Internet Explorer, but this wasn't a sprint so much as an endurance run.

There honestly was a time when Internet Explorer was considered to be the underdog in the whole thing... how could they possibly catch up?

People often credit Microsoft's embedding of the Internet Explorer engine into Windows as Netscape's downfall, but the dirty truth is Netscape made bad business decision after bad business decision and, perhaps more importantly, Internet Explorer simply became a better product.

Which isn't to say it was a great product, as the bar was relative primarily to Netscape... this was a period in time when shiny features and adoption were more important than stability and security.

I have much love for the web engines eventually birthed from the Netscape company, but it can be easy to forget just what a sack of crap Netscape 4.x was turning into. It was unstable and bloated, Explorer just started cleaning its clock.

However, as I mentioned, this was all relative, and this had been a brutal competition. Programmers don't like releasing code that isn't where it needs to be, but there are often other aspects they're forced to deal with: milestones, marketing, etc. Netscape and Explorer were battling it out in the ring of shiny features and market adoption, and it wasn't pretty.

Internet Explorer won, but not without coming out of the ring with much internal bleeding... just in time to get smacked hardcore by the onslaught of bandwidth, and every flaw was exacerbated exponentially by its pervasiveness in the system.

The codebase just wasn't really in the shape it needed to be to handle the challenges thrown at it, and users (and the reputation of Windows) bled heavily because of it.

However, the situation wouldn't have been different if Netscape had been licensed and thrown in, and while it's fair to call Microsoft out on the situation, it's irresponsible and insincere to not then turn your Drunken Eye towards the other software makers guilty of this behavior... namely, just about all of them.

Lord knows the OS I'm using to type this on has shipped more than one feature that wasn't ready for prime time, just so they could have another bullet point on the box to help the upgrade numbers.

It's nigh impossible to talk about the situation with Internet Explorer without talking about the situation with ActiveX, primarily because the severity of the bleeding wouldn't have been nearly as bad if it never existed. This is harder than it sounds, mostly because there really isn't a comparative technology on the Mac to draw analogies to.

Much of the technologies behind ActiveX are rooted in the same days that started birthed shared libraries and services, but that's doing it a disservice.

When you are working in a Word document, and want to include an Excel graph, you can simply drop the graph in, or you can drop a reference to the actual graph into it. Just storing a reference in the documents allows one to update the Excel graph independently and have it become updated wherever it's referenced.

This concept of linking in between various bits is an important concept, is again pervasive throughout most of computing, and is what ActiveX grew out of.

At the time, if you want to be harsh, you could say both Microsoft and Netscape were involved in the 'embrace, extend, extinguish' game. If you wanted to be harsh, you could say that the pace of development didn't allow the luxury of dealing with the pace of the various standards bodies. The truth is generally somewhere in between, with elements of both playing big roles.

When it came to the web browser, there were a bunch of different technologies available to developers. On the client side you had things like HTML, DHTML, Java, Javascript, Microsoft's Jscript, and a whole slew of rich-media plugins... everything from Flash to Quicktime to WMV. On the server side you had a whole slew of technologies that would do their work and then hand it back to the browser.

An ActiveX control is essentially the equivalent of a stripped down bit of Windows program that can be run within the browser, or seperately, that interact to form something larger than the sum of its parts. This was taking the same technologies used to program Windows apps to the Web.

ActiveX is often used as a glue between all of the various technologies, and this is one of the reasons why Mac users get confused when a site that requires Java won't work correctly with their Mac... when hey, their Mac has Java. Chances are the developer is using ActiveX to 'bridge' a whole slew of different technologies for a richer experience.

While this undoubtably benefits Microsoft as a platform, and it's obvious part of what they had in mind was tying the Web to Windows, users have to get over the fact that developers like ActiveX. It makes their life a hell of a lot easier when trying to do some of the things they've been hired to do, and there aren't exactly a lot of compelling alternatives.

JavaBeans comes to mind, and was meant to fill much of the same role... but chances are JavaBeans only sounds familiar to you because it has 'Java' in its name. A major difference is that JavaBeans 'beans' are constrained with the same constraints that a the Java VM has within the browser, whereas an ActiveX control has a remarkable amount of freedom.

This is a big point, as it's both ActiveX's killer feature as well as it's downfall. Notwithstanding things like actual support and capabilities, something like JavaBeans is fairly constrained and sandboxed. Both are designed to allow different objects on a page and elsewhere to communicate, but ActiveX broke through a lot of these 'constraints' and blurred the lines between everything.

Basically, anything a Windows program can do, an ActiveX control can do. You weren't so much viewing a webpage as running a Windows app that just happened to be in a browser.

There were reasons for this, not the least of which was Microsoft's blurring of the lines between what constitutes 'the Desktop' and what constitutes 'the Web'. This was a technology aimed squarely at developers, and developers loved it.

And I mean squarely aimed at developers in more ways than one; the amount of responsibility and power it put into the hands of developers was impressive. Users had a set of security levels they could set, but a lot of the specific options on what ActiveX controls could do were left up to developers...

Let's face it, most people aren't going to change their security settings from the default, and those that did would often encounter problems accessing sites that had functionality they actually wanted... everything from Yahoo time-killers to corporate intranets.

The security problems with ActiveX were obvious, it was way too easy to, say, go to a web page and have your computer shut off... or worse. Different things were tried to make ActiveX more secure from a user POV, like digital signatures, but the damage was always waiting... primarily because of the interaction between components that ActiveX allowed.

ActiveX by it's nature was about integration and communication, and as we've covered earlier, anything in that role becomes inherently dangerous. It only took the smallest and most obscure flaw in some weird bit of functionality for things to go south very, very quickly and because of it's pervasiveness and ability to interconnect with parts of the system, when they bottomed out.

However, while it sounds as though I'm bashing ActiveX, I'm not. ActiveX was an enabler, and people have to remember that probably the worst thing you can say about ActiveX was that it was too capable.

There was a real desire for ActiveX, and people got real use out of it... while not to say there wasn't ulterior motives behind some of ActiveX on Microsoft's part, it provided real functionality web developers clamored for and got. Unfortunately with that, users got a lot of other unwanted things.

The above isn't meant to absolve Microsoft of responsibility, you could (and many do) make a very solid case that they glossed over a lot of warning signs before they recognized the severity of the problem.

'Severity', unfortunately, can often be a relative thing. In the case of a corporation, it generally depends on:

• Manageability
  While it's not a very P.C. term to bandy about, there's a concept called 'acceptable losses', otherwise known as 'the cost of doing business'. Someone somewhere has a spreadsheet showing how much it is costing the company to keep using X versus the benefits of keeping X around. Sometimes the cure is more expensive than just treating the illness.
• How's the bottom line?
  It really sucks when Joe Public has their credit card sucked out and up for sale for on some Russian site, but the severity of the problem, as far as someone like Microsoft is concerned, is defined by whether or not Joe Public is still going to buy their product. Again, this isn't limited to Microsoft, this is a corporate thing.

Don't even start with me on the evil corporation bit, I could easily start listing off examples where your favorite company of choice is obviously working off the same equations. It is, perhaps unfortunately, how public companies work.

Either way, Microsoft has been crunching it's own spreadsheets, and decided that the equation has gotten way out of whack, and they needed to change how things are handled in a big way. While the negative PR from the security problems hasn't exactly been welcome, and they're certainly starting to see some hurt in terms of sales, the manageability aspect is also, if not equally, important.

I have a confession here: Microsoft has been on a streak of surprising the hell of me lately, both with their solutions to some security issues as well as the direction they went with Service Pack 2 for WindowsXP.

As an example, there was a phishing vulnerability announced awhile ago with allowing usernames and passwords in URLs, although it wasn't really limited to IE. This functionality had been in web browsers for ages, but if someone was being malicious it could trick one into thinking they were somewhere other than where they really were... ripe for phishing attacks.

Now there are a whole host of different hacky solutions Microsoft could have implimented to foil this problem. But no, they completely ripped out the functionality altogether. Now this wasn't some little-used niche feature, as I mentioned this had been around forever and ripping this out affected a hell of a lot of people... I was honestly surprised they went that route.

First of all, they were choosing security over convenience. Second of all, they were giving backwards-compatibility the finger, and they were doing it with a commonly-used feature.

Both are notable, but it was the choice to break with backwards-compatibility in such a big way that really made me take note. At this point, I don't think most users have a real appreciation of just how big Microsoft is, let alone Mac users. From the safety of their insular bubble, the 3.x% marketshare number has pretty much just become an abstract number, much like the numbers dealt with in federal budget.

Around 177 million computers were expected to be sold worldwide in 2004 alone. A million users here, a million users there, and pretty soon you're talking about real numbers.

The sheer scale and size at which Microsoft is having to deal with software is, quite honestly, astounding. Changing the simplest default setting can have consequences for millions of users, let alone ripping out a piece of functionality people have used for years.

But they went way beyond that with Service Pack 2, which among other things:

• Turned the Windows firewall on by default
  This may seem to be somewhat trivial, and lots of people derided the quality of it. But after all we've talked about, you should have the idea that this is a big deal, and why. They've gotten a ton of flack from this, most notably from System Administrators and third party programs.
• ActiveX has been neutered
  While I was going through the support docs on this one, I remember seeing "Users could be impacted.", and it's nice to Microsoft going for understated humor. Long and short, Explorer is headed towards becoming very, very cautious about anything fed to it, and downright paranoid if ActiveX is found anywhere in the page.

Now these are two features out of a service pack that was several hundred megabytes in size, but the repercussions were large. The amount of testing having to take place to even get SP2 installed in a lot of environments would, if you added up all of the money spent, probably let you buy Canada.

What fascinated me while going through much of what SP2 included was how often I was going, "Wow, that's going to piss people off." Again, companies generally have a modus operandi, a way of proceeding when put in similar situations, and example after example in SP2 breaks with how Microsoft traditionally would have gone.

Microsoft doesn't often completely change it's M.O., but when you expect them to zig and they zag, it's worth taking notice. When they do it repeatedly, chances are you're seeing the company take on a new focus.

This has happened more than once with Microsoft, and it's something to be ignored only at your peril, but it's part of the M.O. of the echo chamber that we've been down this road more than once.

I obviously don't work at Microsoft, but I, like many others, know people who do. I count one or two of them as friends, and try to check in on what they're working on when they're allowed to talk about it, but what I've found more interesting of late is how they're working.

Microsoft has turned it's eye towards security in a big way. 'Big' doesn't even really begin to catch the scope of it: it's becoming pervasive, and before long will be an intrinsic part of its culture on both the client side and server side.

I want you to think back to the wayback machine episode of the web and Microsoft, and remember when they got religion. Oh how you laughed at the first versions of Internet Explorer and their feeble attempts at a browser. It's very, very important that you remember.

• Remember how you thought they didn't get it, how all their attempts would fail because this was a whole new world. How they would try to apply their past models to the new world and would get their ass handed to them.
• Remember that while you were mocking their feeble efforts, Microsoft was reorienting their company around the web, and slowly building momentum behind their focus.
• Remember how one day you woke up, and suddenly the competitors weren't in such a clear-cut position of untimitigated triumph anymore.
• Remember how Microsoft not only got religion about the web, they started to systematically and pervasively incorporate it everywhere.
• I want you to remember just how long it took for you to really wrap your head around the momentum built behind IE, and just how long it took to get to Firefox from Netscape 4.7, and the years of trying to catch up in between.

You're going to see more balancing between security versus convenience, and security versus backwards compatibility, but the big thing to watch is managed code.

We touched on this a bit earlier, but it's worth talking a bit about .NET. Unfortunately, .NET was an absolute marketing fiasco, so that .NET means a hell of things to a hell of a lot of people, so we're just going to talk about the aspect of managed code.

Most Operating Systems are written in C, C++, etc... or some combination. What they have in common is that they're fairly speedy languages, but 'unmanaged'.

This means the programmer has to keep track of a whole variety of things, like allocating and deallocating memory, checking buffers, etc. If they screw up, you can end up with a buffer underflow or overflow, which leads to ending up with a flaw, which leads to ending up with an exploit, which leads to being hacked. As we've gone through above, this isn't everything, but it's a big deal.

Managed code means the programmer is freed from dealing with those trivial things, which leads to a vastly fewer amount of those types of bugs.

Java does this, and for the sake of this example, think of the .NET frameworks as a 'native' Java for Windows, but with a whole slew of languages to choose from. C# is the de-jour at the moment, but you're free to use a wide variety of languages. Microsoft has been laying the groundwork for this for awhile, and there is going to be a large amount of refactoring of code that is most 'at-risk'.

We've started seeing inklings of this for Explorer, but watch the other common entry points for data too. Slowly but surely, everything will be migrated over when and where it seems appropriate on a bang-for-buck basis, but everything new down the pipe is going out will be managed.

You might think this is easy to dismiss. However it needs to be recognized that by a thousand cuts, some of them great bloody wounds, Windows is tightening up.

Right now people are scoffing at Longhorn, and mocking what it doesn't have more than realizing what it does have. Some of the things we've gone over that Microsoft is implementing are large-scale efforts, and I don't think the size of the effort should be underestimated.

It's coming, and a too few have a real idea of how the scene is going to change with an OS with a base of Window's size pervasively building in managed code. And we haven't even mentioned DRM yet.

There's a reason why we went so thoroughly into the mindset of the times earlier; there is a ton to learn from there. Remember, we all talked about broadband for awhile, and it slowly, slowly built share for a good while. And then in the span of just a few years things changed dramatically.

Linux will reach a critical mass, and then share will start to grow drastically, and it'll be competing with Windows on similar levels of threats on the Desktop. Right now, it's primarily competing on the lack of threats.

I truly believe Linux is going to hit the desktop in a big way, for more reasons than are worth going into at the moment. We're probably going to see this overseas first, perhaps out of fiscal necessity, but the writing is on the wall. Even saying that, chances are we'll all be surprised at just how quickly it starts building once it hits a critical mass.

This could be two years from now, five years, or somewhere in between, but the timeframe is only important insomuch as it makes the deadline for waking up to Microsoft's reorientation around security all the more immediate. The Desktop is a different security environment than the traditional one, and the threats a Desktop OS faces once it reaches critical mass are different than a server.

As things are going, once Linux explodes, Microsoft will be selling itself as a much more secure solution. They're probably already trying to do that now, the difference is they'll probably be actually delivering on that promise.

Meanwhile the OSS world, and the corporations selling OSS solutions, are going to be going through the exact same motions Microsoft has gone through unless they learn from them.

It's important to clarify that while I don't think most have a realistic clue of the S-bomb Longhorn is going to drop on them, security problems aren't going to disappear from Windows.

A major problem is that there is now money to be had in scales that just weren't really there before. Everything from identify theft to stolen credit card numbers to simply using a hacked box to pump out spam to using legions of hacked boxes to threaten a company with a massive DDOS attack unless they pay up.

Whack-a-mole is an appropriate analogy, but is usually used in the context of banging down one problem which causes another problem to crop up because you're treating the symptom and not the underlying cause.

This is a different sort of whack-a-mole, where you shore up one door to the point where it's not really cost effective anymore, and they follow the path of least resistence to the next door.

Basically, there are finite resources, and when you make one area more secure, you're displacing risk onto another area unless you can change the underlying problem. Managed code helps this, but doesn't eliminate the increased complexity we're going to see, and MU-paradigms, as they currently exist, aren't a panacea.

In a bit of irony, even once you hammer down all the holes and cover them with cement, you still have to deal with the user. It shouldn't really surprise people that a lot of malware gets onto computers unintentionally via the user themselves, nor that some of the worst viral outbreaks depended only on automated social engineering tactics and email.

A user is a user is a user, and the only role the specific platform played was that the viral payload delivered didn't actually affect minority platforms.

DRM (digital rights management) is really difficult to talk about in a sane manner, simply because it freaks people out. It freaks me out. The problem is that most technologies that can be powerful forces of change for good or ill have that affect.

There is a difference between the DRM used in say, the iTunes Store as it currently exists and what people like Microsoft, HP, Intel, IBM, etc. have proposed... but in most ways the difference is about scale. Microsft calls it Palladium, and it's otherwise known as TCPA (trusted computing platform architecture).

With Apple's system, iTunes is the ruler of all things DRM, and holds the keys to the kingdom. You can't play encrypted AAC files from the iTunes Store in anything else, and through some jiggery-pokery you have to authorize specific machines to be able to play them... those files are theoretically tied to you, and essentially signed with your key.

This doesn't mean you have full control over the files, and can do what you want with them, but you, and only you (because you have that key) can do what Apple allows you to do with them.

To get an idea of the difference, imagine the OS, and not iTunes, controlling the DRM and what gets to do what. Some examples might be saving a copy of a word file, or really just a plain text file as read-only and sending it to people. If they are also on a 'trusted' platform, they can view it, but aren't allowed to modify it. Alternately, I could specify that only someone else with a specific key could view it all.

There are public/private key crypto systems that allow a semblance of this functionality, but it's not pervasive and because of the network effect and the barrier to entry, it's usefulness to your average consumer is fairly limited.

Obviously, the implications for copyright holders and consumers are massive, and the dangers are very real, especially for concepts like fair use and other rights we've been granted.

Unfortunately, the technologies that allow things like DRM to really work (palladium, tcpa) have broad benefits in other areas, like security. The idea is that using software alone, it's nigh impossible to keep things walled off as we want them to be. But with a combination of hardware and software, things get a lot tighter.

In order for DRM systems at this level to work, everything moving into and inside of the computer is signed to the user. The CPU, the chipsets, all input devices, and all output devices are affected, as is all communication between them. Applications are tied to data, which are tied to the CPU, and everything is encrypted and tied to the user.

This can go a long way towards eradicating things like malware, trojans, viruses and other such things as if I haven't specifically signed them as OK, they can't touch my stuff.

Another danger, of course, is that the only applications that'll be able to touch 'my stuff' at all are the ones 'certified' by the OS vendor as 'safe', which opens up a pretty frightening can of worms. This, to an extent, increases security as there's no chance of me accidently authorizing something malicious, but at the same time gives those who hold the keys to signing things way, way more power than I'm comfortable with them having.

And this where my head starts to hurt: we've been here before, where we've had a really innovative technology that due to fear, in some cases warranted but in others irrational, was shelved. This time the technology isn't radioactive, but I just can't quite bring myself to wholly demonize DRM just yet.

The dangers need to be discussed, and there needs to be a real debate about the issue so that we aren't thrown a weaker form of DRM which slowly erodes our computer into an appliance. At the same time, fearmongering about DRM has probably gotten a little bit out of hand, when there are technologies in it that could be beneficial.

I'm not for DRM, if I was forced to choose between the good with the bad, I'd err on the side of neither. However, if you are dead-set against any form of what 'trusted' computing might entail, the demonization at this point isn't helping. DRM is coming in some forms, it's a done deal as consumers, through things like the iTunes Store, have shown their willingness to accept some forms of it.

Being part of the debate isn't shrieking propoganda like a harpy, and if you remove yourself from the debate you've already lost.

The above is an Arthur C. Clarke quote, from his three laws, and goes back to an earlier point: we passed the point of technology feeling like magic to most people a long time ago.

The majority of people have been disenfranchised by their computer for a long time now. While they've gained capabilities and features, they've come at the cost of the computer becoming even more obtuse rather than more transparent.

They're using a magic box for which they've learned some patterns and tricks for making it go, but most of the paradigms they're being asked to grok when it comes to security make things easier on the computer and not the user.

Innovation isn't just letting you do more things via a GUI versus a command-line interface. That was innovated in the 1980s, and I refuse to accept that we reached the pinnacle two decades ago and all that's left now is to add more eye candy.

Money shots don't really happen in real life, and it'd be disingenious to try to wrap up a subject this messy with a neat little bow.

Security isn't really something you can hold in your hand, but rather a process. And whether you agree with where I've gone with the above ramblings or not, so is this post.