The CCIA report - why the remedies are unfair
This is part three in a three-part series detailing my objections to a recent Computer & Communications Industry Association (CCIA) report, titled CyberInsecurity: The Cost of Monopoly. In part one, I explained that the flip-side to a software monoculture is a market with high economics of scale, generating cost savings that may outweigh the risks. In part two, I listed my objections to various aspects of the content of the report, specifically, an obsession with the CCIA's core mission to overturn the antitrust settlement between the DoJ and Microsoft, as well as a propensity to misrepresent Microsoft's actions and conditions in the market in order to paint Microsoft in a negative light.
In this instalment, I criticise the remedies proposed by the authors of the report, and suggest that these remedies are impractical, if not unfair, given realities of the software market. I note that the primary beneficiary of many of these proposals will be the software companies who count themselves members of the CCIA. Lastly, I close with some parting thoughts.
Software Liability
The authors propose that Microsoft be made liable for all security problems which arise from its software. Furthermore, they make it very clear that this should only apply to Microsoft: "Where that monoculture is maintained and enforced by lock-in, as it is with Windows today, responsibility for failure lies with the entity doing the locking-in" in other words, Microsoft. This shouldn't surprise anyone, as making all software companies liable would run counter to the interests of the software companies who are members of the CCIA. Besides, this is Microsoft, and the technology Lilliputians have the right to tie Gulliver in as many knots as they want (and everyone knows applications written for Oracle databases, as an example, are instantly transferable to SQL Server).
No company WANTS flaws in their code, Microsoft included, but software IS different than hardware. The sheer number of alternative ways to write software means that the number of potential flaws is that much larger. Furthermore, software tends to be more transient given that its flexibility makes it useful as a way to avoid changes to hardware. For instance, software modems are a way to roll out new modems faster, as software is easier to develop than new hardware.
Hardware, therefore, ends up performing the low-level, critical operations required by a system, and software is used to handle everything else. As a result, development schedules are longer, relative to features, for hardware, a reflection of the critical path nature of their operation, and much shorter for software. This means that software will have more potential for error simply because it must do far more than the low level operations required of hardware.
In other words, there's much more room for accidental flaws in software. These flaws, however, only become an issue if some malicious entity tries to do something that exploits it.
A flaw in software isn't comparable to a gas tank that explodes if struck from the rear, as was the case with the Ford Pinto. Someone has to try to break into your system, which is along the same lines as someone trying to break into your house. The fact that you forgot to lock your door doesn't mean that someone has a right to burglarise your home. Likewise, the fact that a software company had an accidental buffer overflow in their code that a hacker exploits doesn't mean that a software company should be held legally responsible.
The best way to deal with software flaws is for consumers to be made aware when a company repeatedly fails to properly secure its code. This is ALWAYS a good thing, as it leads to more informed consumers and more efficient markets. The wrong solution is to find yet another way to feed an already fat legal profession. Given the higher likelihood of flaws in software, litigation charged industry would be a large tax on software companies. It would slow development and product releases dramatically, which some might consider a good thing, but it would also make life much harder, if not impossible, for startups that lack to resources to mount a proper legal defence, much less hire the teams of testers required to reduce the number of flaws to a legally acceptable level.
Freebies for the competition
"...Microsoft should be required to support a long list of applications (Microsoft Office, Internet Explorer, plus their server applications and development tools) on a long list of platforms. Microsoft should either be forbidden to release Office for any one platform, like Windows, until it releases Linux and Mac OS X versions of the same tools that are widely considered to have feature parity, compatibility, and so forth." (Page 18)
First, the practical objection: how does having the SAME application from the SAME vendor help security? Software companies are likely to attempt to build their applications from a common code base. Therefore, a buffer overflow in one application will exist on ALL platforms, thus diminishing the supposed benefits the authors hope to garner from this action. Though the situation would be mildly improved in the case of native development as exploit code would have to be written for each platform (in the case of buffer overflows, at least), there would be no gain if the application was written for Java or .Net, where the execution environment, from the standpoint of an application, is exactly the same on all platforms. This matters, as the future belongs to managed development environments such as Java and .Net that are safer, from a security standpoint, than native development.
Second, I propose that if Microsoft is forced to write many of its applications for a bunch of platforms, then Bruce Schneier should be forced to write children's educational software, hotel management tools and embedded code for rides in amusement parks. That seems fair, since such software is probably as far from his domain of expertise as Unix programming is from Microsoft's developers. Bruce Schneier and the rest seem keen to make OTHER people do a bunch of ridiculous things they probably don't want to do, and all because the CyberInsecurity authors are convinced that the non-Microsoft world can't thrive without Microsoft applications. I think it only fair to expect something similar of him.
In short, ask yourself who is the real beneficiary of this last proposal, consumers, or competitors who get to force the richest company in the world to write applications for their platform?
International standards are insufficient
Besides encouraging national governments to use more non-Microsoft software (good for CCIA members) and capping Microsoft share in various markets (again, good for CCIA members), the CyberInsecurity report claims that compliance to international standards would serve as a replacement for the lack of ubiquitous de facto standards currently found in Windows:
"Other branches of the risk diversification tree can be foliated to a considerable degree, but the trunk of that tree on which they hang is a total prohibition of monoculture coupled to a requirement of standard-based interoperability." (page 19)
International standards, however, fall far short of what is required to create the truly unified software market that exists for users (and programmers) of Windows. First, which standards are organisations supposed to use? There are a number of competing standards for the same technology, and in many cases, no clear winners.
Second, how do we guarantee that implementation of those standards will result in software that operates in a comparable fashion? Compatibility is more than adherence to just an API specification. I've used various Java XML parsers, all of which theoretically implement the same interface "standard." Yet, it isn't safe to replace one parser for another, simply because implementation details are sufficiently different as to alter the runtime characteristics of the code.
Third, standards evolve too slowly to encompass cutting-edge technology in timeframes that matter to businesses. Blame this on the industry consensus process which must occur if a standard is to succeed. De facto standards serve as the necessary glue between technology that has been around for long enough to have an international standard, and new technology which benefits from the flexibility, speed and consumer orientation of individual companies.
Lastly, international standards are rarely broad enough to encompass all the ways a given technology might be used. For instance, dynamic style sheet properties in IE are a great way to make DHTML code simpler, yet are not covered by an international standard. The same applies to the COM reusability API for IE's HTML rendering engine, which is not covered by the base HTML standard.
This should surprise no one, as international standards represent common denominator functionality most implementers require for basic interoperability. De facto standards, in contrast, bridge the gap between this standardised core functionality and real world customer needs. Such de facto standards encapsulate the specific knowledge of customer needs that individual companies have by reason of close association with their clients.
In conclusion, international standards will never be a substitute for the de facto standards, given that there are far too many specific needs than can be covered by a generalised international standard. To attempt to make them do so would be to sacrifice the commoditisation which has provided consumers so many benefits.
Parting Thoughts
To summarise, I distil my objections to three essential points.
First, the report ignores the reasons Microsoft has the position it does in the industry. Microsoft's dominance isn't an accident, or a creation by forces beyond our control. Rather, it's the result of CONSUMER CHOICE, which is based on REAL BENEFITS which accrue to consumers who standardise on a single API standard.
Simply suggesting that the best solution is to blast the current de facto standard into tiny bits doesn't deal with the underlying issues. It's a virtual guarantee that, once people are done paying outrageous prices for software (no economics of scale, no discounted prices), they will standardize on yet another API and recreate the same kind of monoculture discussed in the CyberInsecurity report.
Second, I object to the style of the report. The authors somehow managed to give every action on Microsoft's part a negative spin, from cancelling development of Internet Explorer on the Mac to turning security-related delays into an excuse to beat Microsoft with the antitrust club. Unfortunately, this style has become all too common among Microsoft's critics. When Bruce Perens and Eric Raymond discussed the SCO case on ZDNet, both couldn't seem to stop talking about Microsoft, as if Microsoft had somehow caused Caldera to fail as a Linux distributor and forced Novell to sell them the Unix copyrights.
This would be less of an issue if the paper was to be presented at a Linux Expo, where the target audience is more likely to buy into many of the assumptions made by the authors. This isn't an effective approach, however, if they intend to convince more moderate readers. Given the popularity of Microsoft operating systems among the business community and home users, I would suggest that such readers are in the majority.
Third, I would recommend that the authors run their regulatory proposals by an economist, rather than just the security experts who participated in the report. Economic history isn't a tale of industry experts guiding central planners to more enlightened management of industry. Rather, it is a morality play revealing the dangers of presuming that a group of individuals, however well-trained, can improve over billions of micro-decisions made in free markets, each of which is based on individual knowledge and experience that, in the aggregate, leads to a more efficient allocation of scarce resources.
Quite frankly, consumers are a lot smarter than the technology intelligentsia gives them credit for. My American readers need to remember that it wasn't the strong hand of government which made the United States the richest nation in the world, but free markets.
I welcome those who endeavour to make the costs associated with security flaws in Microsoft products more apparent to consumers through well-researched articles. Such information leads to more informed buyers, which enables those micro-decisions to be that much more efficient. I am strongly opposed, however, to those who suggest that the final decision should be taken from consumers and placed in the hands of government-appointed "experts".
John Carroll is a software engineer now living in Geneva, Switzerland. He specialises in the design and development of distributed systems using Java and .Net. He is also the founder of "="" class="c-regularLink" target="_blank" rel="noopener nofollow">Turtleneck Software.