Free Software Foundation Europe e.V.
Essen, 21 January 2002
1. The Free Software Foundation Europe e.V. ("FSF Europe") is a charitable association (e.V. in Germany) dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs in Europe. The FSF Europe promotes the development and use of free (as in freedom) software - particularly the GNU operating system - and free (as in freedom) documentation. The FSF Europe also helps to spread awareness of the ethical and political issues of freedom in the use of software.
2. The FSF Europe is an acknowledged sister organisation of the Free Software Foundation (FSF) in Boston, USA, dedicated to the same goals.
3. The FSF (including the FSF Europe) has always observed and commented on attempts to lock up the software market and exclude new entrants. This includes many actions by Microsoft Corporation ("Microsoft") that are against free competition, sometimes directly against the Free Software Movement, but not limited to that. The FSF Europe's expertise includes analysing the economic and technological effects of such actions on the software market from an insider's point of view.
4. When the FSF Europe became aware of Case No. COMP/C-3/37.792 of the European Commission against Microsoft, it applied for status as an interested third party. This status was granted on 12 December 2001. On 27 December 2001, the FSF Europe received the non-confidential versions of the Commission's Statements of Objections and Microsoft answers. In the present paper, we are commenting on Microsoft's response (of 16 November 2001) of the second Statement of Objections (of 29 August 2001).
5. Free software, and in particular the GNU/Linux operating system (the GNU system with the Linux kernel added), now holds a substantial and increasing share of the operating system market. Microsoft cited this system as its principal competitor and is using various methods to attack the Free Software Movement. These attacks are usually performed using monopolistic practices similar to those used in the conventional software market. We believe that some of Microsoft's methods of attack are abusive and should be brought to an end..
6. In ¶¶ 139-143 of its Response to the Second Statement of Objections, Microsoft argues against the European Commission's definition of the relevant markets..
7. In contrast, the FSF Europe agrees with the analysis of the relevant product markets by the European Commission as stated in the Second Statement of Objections, ¶¶ 94-119..
8. We think that Europe needs to insist that Microsoft allow compatible competition for all aspects of their newly introduced software products world-wide, not just in Europe, in order to get permission to sell them in Europe..
9. The reason is that the software market is world-wide: If Microsoft is the only alternative that people in the USA (say) are allowed to use, that can make other alternatives commercially unviable everywhere..
10. One of the main objections of the EU Commission is Microsoft's refusal to disclose information about the network protocols (interfaces) necessary to achieve full inter-operability with (a) Microsoft's Active Directory Services, (b) Microsoft's version of the Kerberos protocol, (c) Microsoft's Encrypted File System, (d) Microsoft's Group Policies, and (e) Microsoft's Common Internet File System. (See the Second Statement of Objections, ¶¶ 37-61.).
11. The Halloween Documents (see Appendix B) give evidence that Microsoft employees tend to suggest to extend existing protocols and to develop new, complex protocols with the intention to prevent competing free software from entering into the market..
12. Analyses by the developers of the free software Samba and Samba-TNG (see Appendix C) indicate that Microsoft's protocols are designed in a highly interdependent way: Each (proprietary) protocol depends on the correct implementation of another (proprietary) protocol to work properly. Full functionality and inter-operability can only be achieved when all protocols are known..
13. There are exceptions where Microsoft did disclose some of its protocols (see Appendix C.3). Some of these cases occurred where a lack of inter-operability would have resulted in a loss for Microsoft. In some other cases, Microsoft needed third-party help in order to fix a serious security hole in one of its products..
14. If, in some rare cases, disclosure of information was offered at all, it was offered under very restrictive licensing conditions including non-disclosure agreements which made it impossible to use that information in free software..
15. Appendix D cites an article describing a speculative, but possible scenario how Microsoft can extend its current dominance from the desktop and workgroup server market to the whole Internet - i.e. all server markets - using the same methods as those described in the Second Statement of Objections, ¶¶ 37-61.
16. We believe the scenario in the article is a possible one. Microsoft has already spoken of plans to attack GNU/Linux using secret or patented protocols, and it has already implemented a secret modified version of the Kerberos protocol.
17. Of course, the article is speculation. Microsoft may not use this particular scheme. It may have been planning to do this but be deterred by the publication of this article. In any case, there are many other possible variations that could lead to similar results.
18. The European Union is in position to prevent this scheme, and other such schemes, through its regulatory mechanisms, if it requires that any new Microsoft protocol be published in such a way that everyone can implement it without restriction.
19. Microsoft will no doubt propose to license use of the new protocol under some "nondiscriminatory license terms". Such a proposal would be a trap, since these "nondiscriminatory" license terms can easily be set up to prohibit free software. They would be "nondiscriminatory" in the sense that they would offer the same license terms to everyone, but these terms would not allow anyone to develop free software.
20. In ¶¶ 10-18, 39, 51-53, 62-70, and 94-97 of its Response to the Second Statement of Objections, Microsoft states that third-parties did succeed in achieving inter-operability with Microsoft's server products, that the work needed to achieve this degree of inter-operability was inevitable.
21. As the developers of Samba can confirm (see Appendix Samba), the documentation provided by Microsoft was by no means sufficient to achieve this degree of inter-operability. Most of the information was obtained by reverse-engineering. As a rough estimate, about 100 man-years of work could have been saved if the protocols had been sufficiently documented.
22. Furthermore, as even Microsoft admits in ¶¶ 10-17 of its Response to the Second Statement of Objections, existing products of competitors (including Samba) do not inter-operate seamlessly with Microsoft's server products.
23. According to Microsoft, this reduced ("loose") degree of inter-operability is inevitable between the products of different vendors due to differences in design.
24. There is a prominent example which demonstrates that full ("tight") inter-operability is possible even between totally different systems of independent vendors: the Internet. The existence of the open RfC standards allows, for instance, email clients and servers of different vendors to inter-operate seamlessly. The same holds for the World Wide Web and a large variety of IP-based services.
25. In ¶¶ 16-19 of its Response to the Second Statement of Objections, Microsoft states that the complainants' true interest was to profit from Microsoft's innovations.
26. As programmers who know both Microsoft and its alternatives will confirm, Microsoft's software is not particularly technically advanced. Other people can write software that is just as good, and already do. The only benefit the complainants would get from knowing Microsoft's interface specifications is inter-operability.
27. Once in a while, Microsoft innovates. But Microsoft benefits from the innovations of its competitors, including the Free Software Movement, all the time. It is only fair that we should be able to use their occasional innovations too. That's called "progress".
28. In ¶¶ 82-89 of the Second Statement of Objections, the EU Commission describes Microsoft's licensing policy which builds momentum for customers to move to Microsoft Windows servers. Microsoft's bundling of its Client Access Licences with several server products is an abuse, as it restricts the users' freedom to run their software (Microsoft Windows 2000 Professional in this case) as they deem fit (as a platform for third-party server software in this case).
29. In ¶¶ 26 and 125-131, Microsoft claims that bundling of the Windows Media Player with the operating system is justified because multimedia software is a logical feature of an operating system.
30. If this were the case, the software would have appeared as a new part - an "improvement" - of the operating system from the very beginning. However, Microsoft's bundling started after Microsoft became aware of the fact that a competitor was selling the software in question as a separate product.
31. We observe that Microsoft has redefined the "logical features" of an operating system several times: In the 1980s, most companies considered, for instance, development and remote administration tools logical features of an operating system. Microsoft decided to un-bundle these components and to distribute them as separate products. This was only possible in a narrowed market where no competing operating system already contained these important components.
32. In ¶ 150 of its Response to the Second Statement of Objections, Microsoft states that according to their Settlement with the Department of Justice in the USA, Microsoft is obligated to license the client/server protocols to third parties, on reasonable and non-discriminatory terms.
33. According to an analysis by the FSF, our sister organisation in the USA, Microsoft's "reasonable and non-discriminatory terms" are in fact discriminatory against free software, as they require a licensing scheme which is incompatible with that of free software (see Appendix E). Thus, Microsoft's settlement in the USA still excludes free software from access to the interfaces needed to achieve inter-operability.
34. In order to bring the infringements to an end, Microsoft should be required to publish their current and future interface specifications, without any restrictions or royalty requirements that would make it impossible for free software to support them.
By Vinod Valloppillil, 11 August 1998,
annotated version by
Eric S. Raymond, 1 November 1998.
This is mirrored from:
http://www.opensource.org/halloween/halloween1.html
This document by a Microsoft employee gives an analysis how free software (called "open-source software" or "OSS" by the author) poses a threat to Microsoft. In particular it contains the suggestion to compete with free software by destroying inter-operability:
"By extending [...] protocols and developing new protocols, we can deny OSS projects entry into the market."
One instance of the method suggested here is Microsoft's refusal to disclose the information necessary to achieve client/server and server/server inter-operability as described in the Second Statement of Objections, ¶¶ 37-61.
Click here for a local copy of the Halloween I document.
By Vinod Valloppillil and Josh Cohen, 11 August 1998,
annotated version by Eric S. Raymond, 4 November 1998.
This is mirrored from:
http://www.opensource.org/halloween/halloween2.html
This second document specialises from free software (called "open-source software" by the author) to the GNU/Linux operating system (called "Linux" by the author).
It adds software patents and copyright to the suggested weapons to combat GNU/Linux.
Click here for a local copy of the Halloween II document.
By Aurelia van den Berg, 5 November 1998,
annotated version by Eric S. Raymond, 5 November 1998.
This is mirrored from:
http://www.opensource.org/halloween/halloween3.html
This third document is Microsoft's answer to the publication of the Halloween documents I and II. It says that both documents do not describe Microsoft's official position on GNU/Linux and free software but are designed to encourage discussion inside Microsoft.
If this is really the case, it shows that it is common among Microsoft's employees to discuss the possible application of abusive methods of competition.
Click here for a local copy of the Halloween III document.
The statements below have been contributed by the developers of the server software products Samba (see http://www.samba.org) and Samba-TNG (see http://www.samba-tng.org).
By Jeremy Allison, Samba development team, 6 January 2002.
Samba is an Open Source/Free Software (for details, see: http://www.opensource.org and http://www.fsf.org) project that provides basic file and print services from non-Microsoft based server computers to Microsoft Windows based desktop computers. It is created by a worldwide group of engineers known collectively as the Samba Team. Recently we have expanded Samba into providing authentication services to Windows desktops. The Samba project Web home page is at http://www.samba.org.
Samba is a successful Open Source/Free Software project, shipped in products by companies such as IBM, HP, Sun, SGI, Veritas and many other smaller vendors. Samba is probably the most widely used non-Microsoft file and print server for Windows clients.
Samba code has been communicating with Microsoft Windows operating system based computers over computer networks for nearly ten years now. During this time we have had some interactions with Microsoft management and engineers to attempt to obtain the information we need to successfully create an inter-operable product with Microsoft Windows operating systems.
Writing software code to inter-operate successfully with Windows computers is a very difficult task. Note this is very different from writing software code that runs on Windows computers. In public relations exercises Microsoft likes to claim that all the API's (Application Programming Interfaces, the way third party software code running on a platform talks to the platform, such as Windows) are documented and available to the public. This may or may not be true. However, it is irrelevant to code like Samba that does not run on Microsoft Windows based systems, but needs to communicate with them over a computer network.
In order for Samba to be successful in working with Microsoft Windows computers over a network, we do not need documented API's, we need documented protocols. Protocols are the key to successful computer networking. Just as a common Internet was not possible before an open and fully documented communication system (the TCP/IP protocol) was adopted by all computers, communication with Microsoft Windows computers is only possible if open and documented protocols are used. Microsoft understands this, and proudly claims that Windows supports many open and published protocol communication standards, such as TCP/IP and HTTP (the protocol used on the Web). In recent Microsoft Windows releases such as Windows 2000 and Windows XP they have claimed they are replacing older proprietary protocols such as their authentication system with more open versions of the same thing such as the MIT Kerberos (http://web.mit.edu/kerberos/www/) protocol, implementations of which are also developed in Europe as the Heimdal project (http://www.pdc.kth.se/heimdal/).
These claims do not tell the full story however.
In order to communicate on a network with Microsoft Windows computers, Microsoft Windows mix open and proprietary protocols together in an interdependent web which makes it impossible to use purely the open and documented protocols to create products that have the same features and functionality as the Microsoft ones, giving a competitive advantage to Microsoft products and allowing them to attempt to leverage their desktop monopoly into a server monopoly.
A good analogy would be with the old USA telephone system, a monopoly run by the Bell company. Imagine the Bell company had documented the method of sending voice signals over their telephone lines, but not the dialing and switching protocols used to initiate and route telephone calls. Groups attempting to make inter-operable telephones would then either be forced to spend significant time and effort reverse engineering these Bell proprietary protocols, or to license them from the Bell company. Like Microsoft, Bell would claim that "their networking protocols are open", which on the surface appears true.
The Samba Team have worked out many of these protocols in order to create Samba, but there are still many more protocols needed in order to enable Samba and other products to seamlessly work with Microsoft Windows computers. Until these protocols are published, it will always be easier to use Microsoft Windows desktops solely with Microsoft Windows servers, thus enabling Microsoft to leverage its monopoly from the desktop client space into the server space.
In addition, Microsoft does not stand still in extending and adding to these proprietary protocols in order to make the inter-operability task more difficult as time goes on.
Microsoft file and print services were created for a product called Microsoft LanManager, which competed with the then-dominant Novell Netware networking product. Microsoft's initial efforts in this space were not well received, and Microsoft published a specification for their basic file and print protocols as an X/Open specification, http://www.opengroup.org/products/publications/catalog/c209.htm.
This was the initial specification that Samba was based upon. However, even this documentation was incomplete (no coverage of authentication) and did not cover the "browsing" protocols needed to create the Microsoft "Network Neighborhood" concept. Also, there was no coverage of the (at that time) Microsoft OS/2 extensions to provide support for filenames longer than the 12 character limitation in MS-DOS (the familiar 8.3 names), or coverage of the printing mechanisms used (an obsolete variant was documented instead).
This protocol, called SMB (for Server Message Block) is the basis for all Microsoft file and print services. However, this original document was enough to get programmers started on writing a Microsoft file and print server although it did not cover many of the necessary details. The protocol has since been renamed as CIFS (Common Internet File System) by Microsoft, the rest of this document will refer to it by this name.
Since then, this document has been taken over by the CIFS working group of the Storage Networking Industry Association (SNIA, http://www.snia.org) and has been extended to include many of the needed details to create a working Microsoft compatible basic file and print server. Microsoft's participation in this (although a SNIA member) has not been one as an equal, but rather as the "owner" of the specification. Most importantly, they reserve the right to make changes at any time and without notice, as indeed they have done in the past. This makes the CIFS protocol specification very different and far less useful than the protocols standardised by the Internet Engineering Task Force (IETF, http://www.ietf.org which are true industry collaborations.
The big change in proprietary protocols came with the release of Microsoft Windows NT. Windows NT added much new functionality on top of the basic file and print mechanisms, such as:
Many new remote administration protocols for controlling services, logins, current file and print activity - anything remotely controllable on a Windows NT machine was made available via these proprietary protocols.
Leveraging the work of open protocols, the underlying basis of all these new proprietary protocols was an open and documented protocol known as DCE/RPC (Distributed Computing Architecture / Remote Procedure Call). Microsoft added proprietary extensions to this for their Lanman authentication mechanism, and to provide encrypted transport mechanisms. Note that the DCE/RPC protocols already had methods to provide authentication and encryption, based on public standards (the DES encryption algorithm). Microsoft chose to ignore this work and use a proprietary method instead, thus making inter-operability much more difficult without large amounts of protocol examination and on-the-wire determination.
With the release of Windows NT, the bar was raised to create a product that has the same functionality as an equivalent all-Microsoft solution. New requirements were to discover these new protocols to provide such things as single sign-on, probably the most compelling feature - the ability to enter a password once to authenticate yourself anywhere on the network. Microsoft clients require servers supporting these new protocols in order to offer the features they are advertised as providing.
For many years, until the engineering work was done to discover these protocols, the only servers capable of providing these protocols were Microsoft ones. Samba has now improved (by much work) to the point where we can support some of these features (the new print mechanism, the encrypted authentication mechanism, the naming mechanism, the access control mechanism) but not all of them (many of the critical remote administration features are still missing).
Of course, over these years Microsoft has not stood still in adding new features to Windows NT/2000/XP, and we now have to deal with extensions to provide encrypted file system access, quota support (limits on users disk space) and the authentication mechanism has been replaced with the more open Kerberos system, but with Microsoft proprietary extensions.
Knowing that all these new protocols are based on a standard, DCE/RPC doesn't help at all unless you know how the new feature requests (the "calls" in RPC parlance) are sent over the standard. DCE/RPC is merely a transport mechanism for sending requests to a remote machine and receiving replies from the target. In order to specify what these requests mean, DCE/RPC uses a method called "Interface Definition Language" (known as IDL) to specify the requests (themselves a new protocol) that are sent between clients and servers.
Each service provided by Microsoft servers has an associated description, in the IDL language, that completely describes how to send and receive these requests over the network, on top of the DCE/RPC protocol.
These IDL descriptions are key for providing inter-operability with Microsoft clients. If these IDL descriptions were published, open and equal inter-operability with Microsoft products would be greatly enhanced (although still not perfect).
Knowing this, the Samba Team requested these IDL definitions from Microsoft at the CIFS industry conference in Santa Cruz in October of 1998. The Microsoft representative present, Paul Leech, responded that this was considered a Microsoft proprietary advantage, and the IDL definitions would not be released.
Undeterred, we have requested the IDL definitions from the Microsoft representative at every CIFS industry conference (held annually) since 1998, most recently from the Microsoft VP of Windows Base OS, Rob Short at the 2001 CIFS conference in Redmond, Washington. The response we received was the same we have always received, that is "we'll get back to you on this". No follow-ups have ever been received to these requests.
Other than these refusals, Microsoft has been ambivalent towards the creation of Samba. Contact with Microsoft engineering staff is generally cordial and helpful, although they are not allowed by management to tell us the protocol details we really need to know in order to fully inter-operate. The reports we receive from companies using Samba who are exposed to Microsoft marketing is that of extreme hostility, to the extent of threatening retaliation if use of Samba is discussed publicly in press releases. These reports are similar to those already exposed publicly in the DoJ investigation of Microsoft's business practices.
The original proprietary Lanman and Windows NT authentication system has had several security problems. Microsoft solved this with Windows 2000 as previously discussed by moving to the standard Kerberos authentication system, developed at MIT.
However, the implementation of Kerberos delivered with Windows 2000 was extended to tie it to Windows 2000 clients, and to make public implementations of the Kerberos protocols, such as the sample server published as Open Source/Free Software by MIT, not able to serve Microsoft Windows 2000 or Windows XP clients in the same way a Microsoft Windows Kerberos server can.
What they did was to embed extra, Microsoft specific proprietary information into the protocol packet used by Kerberos (known as a "ticket"). Windows 2000 clients were made dependent upon the existence of this extra data within the ticket in order to implement "single sign-on", that is the ability to have one network user identification across multiple machines.
MIT Kerberos servers, which do not provide this information, can provide authentication to Windows 2000 and XP client machines, but the user authenticated by the non-Microsoft Kerberos server must also exist within an account database held on a Microsoft machine. This causes the user account information to be held in more than one place, the very problem that single sign-on is designed to avoid.
Groups wishing to deploy the more secure authentication service are forced to implement their account databases on Microsoft servers, of face the consequences of not having single sign on available.
As Samba does not generate Kerberos tickets, but is a consumer of them, this extension of the standard protocol doesn't cause us problems integrating into a Microsoft network (we just ignore the extra data), but it is aimed directly at the MIT and Heimdal developers.
I (Jeremy Allison) publicly requested Microsoft to publish these changes to the Kerberos protocol by speaking to Microsoft's Kerberos project manager, Peter Brundrett at a Microsoft Professional Developers Conference in 1997. Once again, the answer was "we'll get back to you on this". The changes were published in a Microsoft Word document that had been modified to include a click-through license which required the reader acknowledge that these changes were a proprietary Microsoft trade secret and to agree not to implement the changes in any code form. Clearly this is a direct attempt to prevent the public MIT Kerberos/Heimdal developers from creating a server fully compatible with Microsoft kerberos single sign-on clients.
In order to create a successful Network Attached Storage server product with Microsoft clients, many more protocols than Microsoft documents or will discuss publicly are needed to create a competitive offering. The only way to get this needed information is to license it from Microsoft (Network Appliance http://www.netapp.com has taken this route), ship only Microsoft software on your hardware, the decision taken by Compaq and other vendors who ship Microsoft's "Server Appliance Kit" (http://www.microsoft.com/windows/powered/nas/default.asp) or to attempt to determine the protocols needed yourself (the route the Samba Team have taken). The vendors that ship Samba depend on us discovering these protocols and shipping timely implementations of Microsoft technology within Samba.
It remains to be seen if Microsoft's entry into this space with their server appliance kit will give them the same dominance they have achieved in the desktop and groupware server (Microsoft Exchange) space. If they are allowed to continue to tie client and server products together with proprietary undocumented protocols then customers requiring the advertised functionality from Microsoft clients will be forced to purchase Microsoft server products, and monopoly will have been successfully extended into another product space.
By Luke Kenneth Casson Leighton, Samba-TNG development team, 20 October 2001.
This letter - also available online at http://advogato.org/article/354.html - was written, in combination with other requests at other times, to cover the "all means available" clause of EC directive 250/90. The author received no reply.
we're looking at your technology in Windows NT and, as you probably know, i am so impressed by it that i would like to interoperate with it. i was wondering, therefore, if you could send me all IDL files and other technical information sufficient to implement programs such as exchange server and the MAPI API, SQL, NT domains version 4 and 5, Active Directory. everything, really. i have asked this question before, and i did get a response back of "no". however, that _was_ over a year ago, and i was wondering if you'd changed your mind at all. also, i do have to apologise in advance because, i have to make this message publicly. the reason for that is that if you still say no, then under European Law, Council Directive 91/250/EEC, i would be allowed to do a considerable amount of work - far more than is sensible - to perform "interoperability" analysis. what would _you_ get out of this? well, ask the team at secure@microsoft.com. whilst i was working on samba, from 1996 to 1999, you received numerous really rather important and obscure security reports. one of these resulted in the deployment of the Netlogon "Schannel" (don't know its real name) in NT Service Pack 4. this was a critical first step to ensuring that the entire SAM database would not be decoded by a hostile party who had access to BDC - PDC SAM Sync, for example! so you would get a full, comprehensive analysis and independent testing of all your core-level products. and that's utterly priceless. and price-tag-free, too. now, _why_ should you give us access to technical specifications? well, reasons i can think of off the top of my head are: - it would generate an incredibly large amount of good-will - some of this technology is old enough (DCE/RPC) such that it's been in use in Microsoft for so long that the people who implemented it originally are retiring, and the "new crowd" don't understand it, don't get it, and are implementing ".net" instead. therefore, it really shouldn't matter: it's nearing the end of its life-cycle. SOAP is All The Rage. dot net is All The Rage. passport dot com is All The Rage. - you've _had_ ten years head-start on this, surely that's more than enough to ensure market leadership, can we join in, now? pleeease? - releasing some of this info may help reduce market share to below a level where the U.S. Dept of Justice will not bother you again. anyway, i hope to hear from you soon, but if i don't, that's okay too. many thanks, luke
By Dr. Peter Gerwinski, FSF Europe.
In January 2002, I asked the developers of Samba and Samba-TNG about their co-operation with Microsoft concerning inter-operability of their respective products. This article is a summary of their answers.
Dr. Andrew Tridgell and Andrew Bartlett have been working in the Samba development team on adding Active Directory support to Samba 3.0.
Luke Kenneth Casson Leighton was the person in the Samba team who has been responsible for the NamedPipes, DCE/RPC support, DCE/RPC services, NTLMSSP etc. that are essential to providing Windows NT 4.0 Domains and furthermore are still essential as support to Windows 2000 Domains. He is the author of the book "DCE/RPC over SMB: Samba and Windows NT Domain Internals", ISBN 1578701503 by MTP (New Riders Group) which documents about 6-7 years of his work on Samba. Today he works on a new project, "Samba-TNG", which aims to be a successor of Samba.
By Robert X. Cringely.
2 August 2001, http://www.pbs.org/cringely/pulpit/pulpit20010802.html
As events of the last several weeks have shown, Microsoft Windows, e-mail and the Internet create the perfect breeding ground for virus attacks. They don't even have to exploit Windows flaws to be effective. Any Visual BASIC programmer with a good understanding of how Windows works can write a virus. All that is needed is a cleverly titled file attachment payload, and almost anyone can be induced to open it, spreading the contagion. It is too darned easy to create these programs that can do billions in damage. The only sure way to fix the problem is to re-stripe the playing field, to change the game to one with all new rules. Some might argue that such a rule change calls for the elimination of Microsoft software, but that simply isn't likely to happen. It's true that [GNU/]Linux and Apache are generally safer than Windows 2000 and IIS, but Microsoft products aren't going to go away. I promised you an answer to how to secure the Internet, and I mean to come through. First, we'll start with the way I would do it, then follow with a rumor I have heard about one way Microsoft might want to do it.
The wonder of all these Internet security problems is that they are continually labeled as "e-mail viruses" or "Internet worms," rather than the more correct designation of "Windows viruses" or "Microsoft Outlook viruses." It is to the credit of the Microsoft public relations team that Redmond has somehow escaped blame, because nearly all the data security problems of recent years have been Windows-specific, taking advantage of the glaring security loopholes that exist in these Microsoft products. If it were not for Microsoft's carefully worded user license agreement, which holds the company blameless for absolutely anything, they would probably have been awash in class action lawsuits by now.
Of course, it is not as though Microsoft intended things to be this way. No company deliberately designs bad products. But you must understand that Microsoft limits its investments to things that will enhance a product's market share. Every feature in Windows had to pass the litmus test, "Does it increase market share?" Putting security safeguards in their products evidently failed the litmus test, and therefore weren't added. While it is true that virus authors will target platforms that give them the most bang for their programming buck, the Windows platform has virtually no security to even slow them down. I believe the lack of security in Microsoft software was a deliberate business decision.
Alas, things are only likely to get worse in the near term. So far, we've been lucky in that most virus authors have been impatient and want to see the immediate effects of their work. It is far more effective to be patient and let the virus spread quietly for months. If the virus does nothing, the defense against it will be slow and/or too late. If the virus does very little on one's PC (for awhile), it won't be discovered easily. It is also possible to make a stealth virus. I won't go into specifics for obvious reasons, but if you think about how virus detection software works, it isn't hard to trip it up.
Even if 98 percent of the world's computers had current anti-virus software (which they don't), the remaining two percent would still be millions of devices capable of bringing down the entire Internet if infected.
And now, we have the impending release of Windows XP, and its problem of raw TCP/IP socket exposure. As I detailed two weeks ago, XP is the first home version of Windows to allow complete access to TCP/IP sockets, which can be exploited by viruses to do all sorts of damage. Windows XP uses essentially the same TCP/IP software as Windows 2000, except that XP lacks 2000's higher-level security features. In order to be backward compatible with applications written for Windows 95, 98, and ME, Windows XP allows any application full access to raw sockets.
This is dangerous.
Not only is it dangerous, it is unnecessary. What is wrong with telling application developers, "Your application can't have access to raw sockets," or, "When XP ships you need to have a non-raw socket version ready for your customers," or, "If your application needs to access raw sockets, these are the security rules and interfaces you will have to use"? The bottom line is that Microsoft's choice to provide access to raw sockets was based on the market share litmus test, period.
Unless this feature is changed before XP is released, it will mean that millions of new computers will be manufactured as perfect little virus machines. Virus authors who are anticipating these new PCs will be able to pre-position their digital vermin to take advantage of the socket flaw as the new machines appear. The result is that, in all likelihood, there will be massive data security problems, as well as massive damage to files and property, all as a result of Windows XP. But as consumers, guess what - we won't even get a choice. Microsoft will require the PC makers to install XP in the factory. It will come on your PC, and you won't have the choice or option to pick something different. When Microsoft issues a new OS, it is forced into the market.
Here is my preferred solution for Internet security. We could implement a secure user identity system precisely like telephone Caller ID. It would be essentially an Internet ID. All Internet transactions could be based on it. Anyone who sends me e-mail can be identified. Anything I send can be traced to me. People wouldn't be forced to participate, but if they remain anonymous, I might choose to block them. I certainly wouldn't accept file attachments from them. I know you hate this idea, but I think the Internet needs a fingerprint. It does not have to have personal information, but if you break the law it can be traced to you. You can choose not to have a fingerprint, but then your ability to communicate with others may be limited - a price many people may choose to pay.
I am not opposed to people being anonymous - just to anonymous people receiving public assistance. Send all the anonymous love or hate mail you like, but don't expect to attach a file.
And what's with those file attachments, anyway? Replace mail clients and APIs with secure models. The new model will not run attachments as they do today. E-mail attachments should not have access to the e-mail client, APIs, etc. Attachments should not have access to the operating system by default. The user should approve the use of some APIs, like having to give permission before device drivers are updated.
Any application that wants to send bits onto the Internet must first be permitted to do so. Applications would be registered to send outgoing traffic. The applications would be limited by function and port. You would register your e-mail program as the only application that could talk SMTP, POP3, etc. If Microsoft Word wanted to send an e-mail, your e-mail program would pop up, ask you to authenticate yourself and explicitly send the message. At that point, you would be in complete control of what was happening on your PC. For mail-enabled applications, there would be an application user account registered on the post office. The account would be unique, and registered to a unique application.
If kids want to install an Internet game, the game's IP port would be registered and permitted to operate, hopefully by the parent. If kids wanted to install an Internet chat program, too bad - it wouldn't work if Dad didn't want it to work.
By default, under this scenario, your PC becomes a TCP/IP read-only device. By running applications like Gibson's Zone Alarm you can - right now - severely limit the use of TCP/IP by applications on your PC. And what happens when you do so? Everything works just fine. So rather than ripping the protocol stack wide open, let's do the exact opposite. Restrict access to it.
The only e-mail activity on my PC should be initiated by me, personally. Nothing else should access my address book or send out messages without my express permission. Microsoft will of course reject the idea, mostly because it will fail the "increase market share litmus test." My answer is, "Microsoft, if you do not take responsibility for locking down your APIs, it will become obvious to the public and become a detriment to your market share."
Now to the other approach, the one some people attribute to Microsoft. I am not making this up. The story came to me from people I have come to trust, and I have looked into it closely enough to think it might have some validity. But for the sake of keeping lawyers off my back, let's just call it a rumor, and only use it as a basis for discussion. To be perfectly clear, I am not claiming that the following is true - just that I have heard it from more than one source, and think it accurately characterises some past behaviors of Microsoft. Perhaps by bringing it into the light, we can ensure that Redmond takes a more thoughtful course. I certainly hope it is wrong.
Programmers who ought to be familiar with Microsoft's plans have suggested that the real motive for raw socket support is for Microsoft to use Windows XP to exploit a bad situation, to deliberately make things worse.
According to these programmers, Microsoft wants to replace TCP/IP with a proprietary protocol - a protocol owned by Microsoft - that it will tout as being more secure. Actually, the new protocol would likely be TCP/IP with some of the reserved fields used as pointers to proprietary extensions, quite similar to Vines IP, if you remember that product from Banyan Systems. I'll call it TCP/MS.
How do you push for the acceptance of a new protocol? First, make the old one unworkable by placing millions of exploitable TCP/IP stacks out on the Net, ready-to-use by any teenage sociopath. When the Net slows or crashes, the blame would not be assigned to Microsoft. Then ship the new protocol with every new copy of Windows, and install it with every Windows Update over the Internet. Zero to 100 million copies could happen in less than a year, and that year could be prior to the new protocol even being announced. It could be shipping right now.
Suppose you are a typical firm that also has some non-Microsoft servers. You will want to use this new protocol between your Microsoft and non-Microsoft servers. Microsoft could charge Sun millions to put TCP/MS on their systems. Microsoft can promise open support, but make it financially impractical. Then use it in a marketing attack against competitors. Zero-Footprint network drivers, ODBC, and MAPI are examples of Microsoft "open" standards that took years for non-Microsoft firms to use. Almost anyone who would have wanted to use these open standards has been driven out of business. Second part of the push for the new protocol will be from AOL/Time-Warner, normally Microsoft's top competitor - but not on this issue. AOL isn't really part of the grand vision of the new protocol. It's just that if they get more of what they want (paid accounts, music and video royalties), they won't object to Microsoft pushing for secure authenticated connections.
Third and most powerful part of the push for Microsoft's new protocol will be action by Congress. They'll cite concerns of business, and hold up the standard scare tactics of terrorists and child pornographers. They want all connections, all packets to be traceable. Say goodbye to TCP/IP and to anonymous connections of any kind. Hello to Hailstorm, tracking everything down to the last mile, and a more business-friendly Internet with prioritised packet-handling. If this seems like too much infrastructure to change, it isn't. Not if the old protocol has been rendered useless and the new one can be implemented by an upgrade to your router. Vines IP - in many ways the basis for TCP/MS - was sufficiently close to regular TCP/IP that most routers only had to have a flash upgrade (to IOS, in the case of Cisco) in order to route Vines IP. This will be an inconvenience, sure, but marketing types will see it more like another Y2K bug - an opportunity to sell, sell, sell.
But won't the Internet Engineering Task Force (IETF) stop it from happening? No. The entire basis for setting standards on the Internet is to first put the new code in service, and then seek standardisation. There are no IETF rules that say 100 million plus computers can't run TCP/MS, and there is no deadline for standardisation. Once the right 100 million plus computers are running the new protocol, Microsoft won't have any reason to seek standardisation. Why not? It is Possible, for awhile, to run more than one protocol at a time. Take as examples of the coexistence of IPX and IP in Netware systems, or AppleTalk and IP in MacOS systems. Business will push for the new protocol, and the result will be that TCP/MS will become a de facto standard, and Microsoft will own the Net.
And all you have to do to kick it off is implement raw socket support in the next shipping version of Windows, with the possible bonus of blaming any problems on UNIX code later.
If business feels a need for the ability to have prioritised packet Delivery, and government (plus the Recording Industry Association of America) is uncomfortable with the notion of untraceable packets and connections, of course Microsoft is going to try to fill that niche. Haven't you noticed how their ads have been trying to convince people that Microsoft software is amazingly stable and secure, and doesn't need minding? That's the image they're trying to build - solid as a bank.
MS/TCP will ostensibly be a solution to the problems businesses are having with the Internet. It will assign priorities to packets. It will insure that all connections and packets can be traced, authenticated, and monitored. And since all these connections to the Internet have to be authenticated to someone, it will likely be hooked into a credit card or some sort of account, from which Microsoft can extract its price as the gatekeeper for the authentication via Hailstorm, Passport and .NET.
But how will this stop the "I just e-mailed you a virus" problem? How does this stop my personal information being sucked out of my PC via cookies? It won't. Solving those particular problems is not the protocol's real purpose, which is to increase Microsoft's market share. It is a marketing concept that will be sold as the solution to a problem. It won't really work.
The Microsoft Proposed Judgment has been designed by Microsoft to make its provisions useless or worse for free software. The following are the specific provisions of the Judgment to which the Foundation will be formally objecting in its filing under the Tunney Act, which will be made on or before January 28, 2002, and will be available at http://www.fsf.org and http://moglen.law.columbia.edu.
Section III(D) of the Judgment provides that:
Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of inter-operating with a Windows Operating System Product, via the Microsoft Developer Network ("MSDN") or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to inter-operate with a Windows Operating System Product.
The "sole purpose" requirement means that Microsoft does not have to make any such API information available to developers of software like WINE whose purpose it is to make a non-Microsoft OS inter-operable with applications written for Windows. This therefore excludes all measures to assist GNU/Linux to inter-operate with applications written for Windows, which would provide maximum competition in the OS market, which should be the objective of a competition-law remedy.
Section III(E) of the Judgment provides that:
Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of inter-operating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (i) implemented in a Windows Operating System Product installed on a client computer, and (ii) used to inter-operate natively (i.e., without the addition of software code to the client or server operating system products) with Windows 2000 Server or products marketed as its successors installed on a server computer.
This provision too means that GNU/Linux software developers are not going to have access to information about protocols implemented in Windows.
Under III(I), the Judgment requires that
Microsoft shall offer to license to ISVs, IHVs, IAPs, ICPs, and OEMs any intellectual property rights owned or licensable by Microsoft that are required to exercise any of the options or alternatives expressly provided to them under this Final Judgment
GNU/Linux developers have no rights under III(D) or (E) and thus are not entitled to license any rights from Microsoft. Even if they were, however, III(I) only gives those rights provided that:
1. all terms, including royalties or other payment of monetary consideration, are reasonable and non-discriminatory;
2. the scope of any such license (and the intellectual property rights licensed thereunder) need be no broader than is necessary to ensure that an ISV, IHV, IAP, ICP or OEM is able to exercise the options or alternatives expressly provided under this Final Judgment (e.g., an ISV's, IHV's, IAP's, ICP's and OEM's option to promote Non-Microsoft Middleware Products shall not confer any rights to any Microsoft intellectual property rights infringed by that Non-Microsoft Middleware Product);
3. an ISV's, IHV's, IAP's, ICP's, or OEM's rights may be conditioned on its not assigning, transferring or sub-licensing its rights under any license granted under this provision;
4. the terms of any license granted under this section are in all respects consistent with the express terms of this Final Judgment; and
5. an ISV, IHV, IAP, ICP, or OEM may be required to grant to Microsoft on reasonable and nondiscriminatory terms a license to any intellectual property rights it may have relating to the exercise of their options or alternatives provided by this Final Judgment; the scope of such license shall be no broader than is necessary to insure that Microsoft can provide such options or alternatives.
Beyond the express terms of any license granted by Microsoft pursuant to this section, this Final Judgment does not, directly or by implication, estoppel or otherwise, confer any rights, licenses, covenants or immunities with regard to any Microsoft intellectual property to anyone.
Here subsection (1), which establishes so-called "reasonable and nondiscriminatory" licensing, means only certain wealthy developers would be entitled to Microsoft API information. Sub (2) repeats that no license will be given to any information for purposes except inter-operability with Microsoft OSs. Sub (3) means that Microsoft can use licenses which prohibit implementing any of their APIs in GPL'd software, because they can refuse to permit any relicensing to downstream users, which GPL requires. The final paragraph is intended to prevent us from ever arguing in future that the "nondiscriminatory" clause or any other part of this Judgment establishes an equitable right in free software developers to have access to Microsoft API information.
Section III(J) of the Judgment says:
J. No provision of this Final Judgment shall:
1. Require Microsoft to document, disclose or license to third parties: (a) portions of APIs or Documentation or portions or layers of Communications Protocols the disclosure of which would compromise the security of anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems, including without limitation, keys, authorisation tokens or enforcement criteria; or (b) any API, interface or other information related to any Microsoft product if lawfully directed not to do so by a governmental agency of competent jurisdiction.
2. Prevent Microsoft from conditioning any license of any API, Documentation or Communications Protocol related to anti-piracy systems, anti-virus technologies, license enforcement mechanisms, authentication/authorisation security, or third party intellectual property protection mechanisms of any Microsoft product to any person or entity on the requirement that the licensee: (a) has no history of software counterfeiting or piracy or willful violation of intellectual property rights, (b) has a reasonable business need for the API, Documentation or Communications Protocol for a planned or shipping product, (c) meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business, (d) agrees to submit, at its own expense, any computer program using such APIs, Documentation or Communication Protocols to third-party verification, approved by Microsoft, to test for and ensure verification and compliance with Microsoft specifications for use of the API or interface, which specifications shall be related to proper operation and integrity of the systems and mechanisms identified in this paragraph.
Because the phrase "authentication/authorisation security" is so broad, Microsoft can refuse to give any developer of "Middleware" meant to secure inter-operation of free software with .NET any information whatever, or condition the grant on its own decision about the "commercial viability" of the firm. The GNOME Foundation, FSF, dotGNU, and all other non-profits would of course be entirely excluded. And Microsoft can claim a government-blessed monopoly over all DRM technology it dreams up with the content oligarchs, thus excluding all free software OSs from the world of multimedia altogether, which would make both Microsoft and Hollywood very happy.
In short, the Proposed Judgment is a strategic attack on all the most crucial points, a critical part of Microsoft's campaign against free software. It doesn't just fail the Government's own objective of increasing competition in the line of commerce where the Government proved Microsoft was an illegal monopoly, it increases the monopolist's hold by giving blessing to all of Microsoft's measures to eliminate its one remaining, unique competitor.