CCIA on Microsoft - what's the real issue?

This is part two in a three-part series detailing my objections to a recent Computer & Communications Industry Association (CCIA) report, titled CyberInsecurity: The Cost of Monopoly. In the last instalment, I explained that cost savings related to a standardised computing infrastructure can outweigh costs associated with software "monoculture" risks.

In this instalment, I outline my objections to various aspects of the report's content. In short, the authors obscure the point of the article through their obsession with the perceived unfairness of Microsoft's market power. Furthermore, though their ability to put a negative spin on Microsoft's every action is impressive, it seems more opportunistic aggression than an attempt at dealing objectively with security flaws in Microsoft operating systems.

What is the REAL point of the article?
If you skipped the table of contents, four pages of biographies, a two-page anti-Microsoft diatribe courtesy of the CCIA, and a two-page executive summary, you might be forgiven for believing that this was yet another attempt by the CCIA to undo the settlement reached between Microsoft and the DOJ. The entire report is threaded with protestations about Microsoft's supposed monopoly power.

Granted, the report attempts to link monopoly power to the presence of a monoculture -- which is presented as a Bad Thing that requires government intervention to remedy. Unfortunately, the authors' obsession with the "fundamental unfairness" of Microsoft's monopoly power causes them to forget the point of the article, which was, at least theoretically, about security.

For instance, the report mentions that "today's locked-in Microsoft users would no longer pay the prices that only a monopoly can extract." Pretending for the moment that Microsoft's prices are truly far above the industry average for proprietary OSes, what on earth does this have to do with the issue of security? Wouldn't higher prices result in FEWER computers, or even better, drive customers to other providers?

Later, they try to turn Microsoft's decision to slip release dates in order to conduct more thorough security reviews into a negative, by claiming such a move "...is also an admission that Microsoft holds monopoly power -- they and they alone no longer need to ship on time". Besides the obvious fact that most software companies slip schedules, this, again, has little to do with the issue of security so much as a complaint over Microsoft's supposed monopoly power as such.

This obsession with antitrust, sure fingerprints of the CCIA, poisons the article's ability to deal honestly with the issue of security in Microsoft software. Consider their treatment of the issue of "trusted computing". Trusted computers are built according to specifications designed by the Trusted Computing Platform Association (Intel, IBM, Microsoft and HP are founding members), and enable levels of Digital Rights Management (DRM) not possible given current hardware architectures. Microsoft's proposed implementation of these specifications is the Next Generation Secure Computing Base (NGSCB), formerly code-named Palladium.

"Given Microsoft's tendencies, however, one can foresee a Trusted Outlook that will refuse to talk to anything but a Trusted Exchange Server, with (Palladium's) strong cryptographic mechanism for enforcement of that limitation. There can be no greater user-level lock-in than that ..."

That's all well and good, and represents something that IS possible on platforms which adhere to TCPA specs. However, again I must ask if this report is about security, or about the CCIA's ability to fire another cream-filled antitrust Zinger at Microsoft? Presumably, if Trusted Exchange can only communicate with Trusted Outlook, then untrusted crackers can't access Exchange AT ALL, thus avoiding potential security issues. In other words, Palladium SOLVES security issues, which is a GOOD thing unless you live in a world where everything that Microsoft does must somehow be cast as a bad thing.

This article is NOT supposed to be about how upset the authors are about Microsoft's market power, but about Microsoft's security issues. Unfortunately, that issue gets entirely lost in the authors' enthusiasm for throwing buckets of red paint towards Redmond. 

Fearmongering
The authors note that "[y]ou should not have to wait until people die to address risks of the scale and scope discussed here." It's certainly hard to argue with this, which was probably the reason the statement was worded in this way. Yet, if the feared event is unlikely to happen in the first place, then reacting as dramatically as the authors later suggest seems a bit paranoid. It should be significant that there isn't a SINGLE instance of terrorists targeting computer infrastructure.

The standard response is to question what might happen if Windows was used in uniquely sensitive infrastructure, such as to control the cooling process of a nuclear power plant. But that's like saying Formula One racers should be concerned that the tyres used on a Volkswagen Jetta might explode on a hard curve. Formula One racers don't use the same tyres as a Volkswagen Jetta.

It's not impossible to use Windows, or even Linux, in sensitive computing environments, provided proper attention is given to risks associated with operating systems with large installed bases (the same risks outlined in the CyberInsecurity report). However, Windows servers are aimed at the mass market, and are intended for use in MOST business situations. Managing nuclear power plants isn't a common usage of commodity operating systems.

NASA engineers use chips 10-15 years old for the simple reason that they are well tested and understood, and that's just for stuff that gets blasted into outer space. Utilities tend to be VERY conservative about the software and hardware they buy. I would suggest that they would be as reluctant to put their trust in commodity Linux servers as they are to put their trust in commodity Windows servers.

People don't bypass the cost savings of consumer-grade video cameras because movie studios don't use them to make movies. In the same vein, you don't bypass the cost savings of a general purpose OS like Windows and Linux simply because it isn't likely to be used in a nuclear power plant. You figure out what your risk costs are, and if they are higher than the cost savings associated with commodity operating systems, you turn to something more specialised. Furthermore, I would suggest those best qualified to make the required risk calculations are those closest to the situation, not CEOs and consultants at security companies.

Correcting various errors
As noted in my introduction, the authors appeared to go to unusual lengths to cast Microsoft in a bad light. Along the way, they make a number of misrepresentations, and fail to explain themselves on a number of logical points.

For instance, on page 13, they claim that Microsoft is dropping support for IE on the Mac because of "their recent decision to embed the IE browser...far into their operating system". Yet, remember that Opera, maker of a competitor to Internet Explorer, has questioned whether they would release a new Mac version. The reason, of course, is that Apple is putting a lot of energy into its Safari browser, and Opera doesn't see much of a market competing with an Apple-sanctioned browser. Why would Microsoft make any different a calculation?

The authors make clear the need for a diverse computing architecture as a barrier to cascade failure, yet note on page 7 that "[t]he growth in risk is chiefly amongst unsophisticated users." In other words, the greatest risk is not among companies who pay specialists to secure their network, but among home users without the technical sophistication to protect themselves. No suggestion is proposed as to how this situation is to be remedied. Are non-technical users supposed to buy multiple systems for the home? Are governments to require stores to sell computers on a round-robin basis, forcing home consumers to buy computers that they may have no idea how to use? Are non-technical users more likely to understand how to use, much less update, a particular system in a world with a diverse operating environment, given that for many, it's hard enough to learn ONE operating system?

On page 12, the authors state that "Microsoft has a high level of user-level lock-in; there are strong disincentives to switching operating systems." Yet, where is it NOT the case that customer's are "locked-in" to a particular platform? Can a user's collection of Linux applications be migrated to the Mac if they choose? Can Mac applications be run on Solaris, or for that matter, Windows? Can applications written against an Oracle database be ported automatically to SQL Server?

Likewise, how does the presence of an integrated IE constitute user-level lock-in? Is it a grievous sin for Microsoft to offer developers the OPTION of reusing an integrated HTML renderer? Microsoft's "crime" in this case was that they were sufficiently forward-thinking as to offer their HTML rendering engine as a set of reusable components years before its competitors got around to it. It should surprise no one that developers found IE appealing. Similarly, it is only a problem for Microsoft to make IE available to end users as a default option if you buy into the notion that government must bully consumers into usage modes it considers more favourable.

Along those lines, consider the basis upon which they conclude Microsoft is guilty of "tight integration" of components: "The "tight integration" is this: inter-module interfaces so complex, undocumented , and inaccessible as to (1) permit Microsoft to change them at will, and thus to (2) preclude others from using them such as to compete" (page 13).

I'm only left to conclude that the authors have NEVER programmed for a Microsoft operating system. Microsoft is and always has been very developer-friendly, and goes to great lengths to provide its developers with loads of easy to use documentation. This is a fact noted by developers who have made the transition to Windows from other platforms.

Furthermore, where are the examples of Microsoft changing APIs at will in order to befuddle the competition? That would be surprising, given that Microsoft often tends to create its applications as a set of reusable components so that its own developers might reuse them. In other words, changing an API would harm Microsoft's own developers as much as it harms external developers.

Besides these facts, few companies go to the same lengths as Microsoft to maintain backwards compatibility with old interfaces. Windows 9x code was only recently replaced with Windows XP, and even then, most applications written for Windows 9x operating systems run on Windows XP. Compare this to Apple, who has drastically changed its APIs several times over the past decade. This fact should be an "in" to insightful competitors, given that there is nothing stopping them from cloning the IE automation interfaces (as an example), thus making their browser interchangeable with use of IE.

Lastly, on what basis do they conclude that Microsoft makes its interfaces "complex...and inaccessible?" Microsoft for years has used COM as its standard reusability API, a binary interface standard on Windows which enables multiple languages to reuse the same block of code (now superseded by .NET). COM was well understood, at least if you were a Windows developer, and hardly the "inaccessible API" that the CyberInsecurity authors imply is the norm on Windows.

This is the second of three parts. Read Part I CCIA Microsoft report -- the core issues. Part III will appear on Friday.