If you want concrete, real-world examples of how badly-designed (or nonexistent) security systems can fail, see Ross Anderson's book, Security Engineering.
The question to ask is not whether its possible/easy for someone to hack your satellite, it's can you afford it if they did? The answer to that would seem to be no. That means you cannot afford to not use the best protection available to you.
A key component of enhancing network security is to maintain (or improve) the pathways in place for vulnerability reporting. CERT, BUGTRAQ, the NYTimes, etc, are frequently responsible for encouraging vendors to respond rapidly to holes in their systems, and are undoubtedly responsible for getting many people to install those patches.
Recently, at least one large unnamed software company which has had a security PR problem apparently has raised again the ugly suggestion that reporting bugs publicly is irresponsible. (Bad software doesn't cause people to break into systems -- it's people saying that the software is bad that causes people to break into systems.) Other people have suggested closed lists so only "appropriate" people hear about vulnerabilities. It is very important that the government not get boondoggled into restricting access to information about security vulnerabilities.
There are those who argue that making available exploit code as part of a description of an attack is a large part of the problem (somehow they think there is some magic involved in turning words into code and almost no one can do it). It's unfortunate that public demonstration of an exploit, not mere description, is frequently needed to actually get a vendor to acknowledge a vulnerability.
Instead of limiting information, why not pressure vendors to write better code in the first place (c'mon, who thought that having your email client execute arbitrary script code in an email was a *good* idea?), and to respond rapidly to problems without having to be splattered over the NY times.
If I believe I have suffered monetary damages because of a faulty (insecure) (software) product, I should have the freedom to sue the person who sold me that product. When physical products go wrong, manufacturers can be forced to recall them (analogous to releasing security patches, though the latter is voluntary).
If someone is injured by a product that has been recalled after the recall, (e.g. they didn't know it had been recalled), do we blame them for not being sufficiently up to date? Software will never be bug-free or completely impervious. But the current blame-the-victim (you didn't patch fast enough) answer to complaints about companies who release glaringly buggy software in the first place is not going to solve the problem either. We need to hold software vendors to the same quality standards for initial release that we would makers of any other product, and the best way to do that may be to enable litigation (I never thought I'd be recommending that as a solution to any problem...).
The most frightening thing I found about the newsforge story was the small amount of money given directly to Sen Hollings by the media industry players (~$100K). Now granted, that's not listing the large soft money contributions given to the party as a whole, etc, but without that, it seems like congresscritters are going cheap.
Question: if the open source community (both individuals and those corporations who benefit from it and aren't scared of the RIAA/MPAA) put some concerted money and effort into setting up a lobbying organization and buying back a few congresscritters, could we tip the scales?
Maybe this is the best approach -- separate out code as used to cause a computer to perform some function, and code used for communication between humans. In that role, using code as a means of expression has some unique benefits -- clarity, brevity, and lack of ambiguity not provided by other forms of speech (except mathematics, which is not usable for all subjects or all audiences).
This might open a loophole where pseudocode is alright, but "real" code is not. Pseudocode is used all over the academic literature to express ideas that can't be expressed effectively any other way. Sometimes the pseudocode is closer to a mathematical formula than to anything you'd really be able to put into a computer. Sometimes, however, only by staying close to what goes into the machine can you communicate what you need to -- e.g. code which is by its nature expressive or amusing (the obfuscated C code contest), or where the code itself demonstrates a novel, elegant, or particularly efficient approach (in a particular language) that impacts the usefulness of the algorithm being discussed. Some concrete examples:
A classic example of code used as a form of expression can be found in any ietf protocol standard, in the language called ASN.1 (I know, many people would call it more an abomination than expression). ASN.1 describes data structures, not computations, but it can be compiled directly into code to create and parse binary messages. And it is one one of the only forms of expression specific enough to really communicate what exactly should go across the wire at this time. So in most RFCs that specify wire protocols, the primary content of interest is in ASN.1. There's supporting content in English to tell you how to interpret some of the fields, but not enough to live without the ASN.1. The document would stand on its own as a communication tool between humans if all the English was stripped out, but not if the ASN.1 was removed and the English left alone. (I think you could make even a stronger statement for XML along these lines, because of its greater expressive freedom.)
Another, possibly less strong example of code as an irreplacable form of expression might be in books whose goal is to explain the workings of a particular body of code, or a particular system using the guts of an implementation as the best way to communicate (e.g. Wright & Steven's TCP/IP Illustrated Vol 2, which tells you how to build a TCP/IP stack using one as an example, or the annotated book version of the Linux Kernel).
I may not have a sufficient grasp of copyright law, and arguing that code is the only way to express certain concepts effectively, might not count as "expressive" in the manner necessary for copyright protection. But I think the argument is that code is to programmers like equations are to mathematicians might be more accessible to a judge than the intrinsic beauty of the obfuscated C code contest (alas;-).
Slashdot Mirror
If you want concrete, real-world examples of how badly-designed (or nonexistent) security systems can fail, see Ross Anderson's book, Security Engineering.
The question to ask is not whether its possible/easy for someone to hack your satellite, it's can you afford it if they did? The answer to that would seem to be no. That means you cannot afford to not use the best protection available to you.
A key component of enhancing network security is to maintain (or improve) the pathways in place for vulnerability reporting. CERT, BUGTRAQ, the NYTimes, etc, are frequently responsible for encouraging vendors to respond rapidly to holes in their systems, and are undoubtedly responsible for getting many people to install those patches.
Recently, at least one large unnamed software company which has had a security PR problem apparently has raised again the ugly suggestion that reporting bugs publicly is irresponsible. (Bad software doesn't cause people to break into systems -- it's people saying that the software is bad that causes people to break into systems.) Other people have suggested closed lists so only "appropriate" people hear about vulnerabilities. It is very important that the government not get boondoggled into restricting access to information about security vulnerabilities.
There are those who argue that making available exploit code as part of a description of an attack is a large part of the problem (somehow they think there is some magic involved in turning words into code and almost no one can do it). It's unfortunate that public demonstration of an exploit, not mere description, is frequently needed to actually get a vendor to acknowledge a vulnerability.
Instead of limiting information, why not pressure vendors to write better code in the first place (c'mon, who thought that having your email client execute arbitrary script code in an email was a *good* idea?), and to respond rapidly to problems without having to be splattered over the NY times.
If I believe I have suffered monetary damages because of a faulty (insecure) (software) product, I should have the freedom to sue the person who sold me that product. When physical products go wrong, manufacturers can be forced to recall them (analogous to releasing security patches, though the latter is voluntary).
If someone is injured by a product that has been recalled after the recall, (e.g. they didn't know it had been recalled), do we blame them for not being sufficiently up to date? Software will never be bug-free or completely impervious. But the current blame-the-victim (you didn't patch fast enough) answer to complaints about companies who release glaringly buggy software in the first place is not going to solve the problem either. We need to hold software vendors to the same quality standards for initial release that we would makers of any other product, and the best way to do that may be to enable litigation (I never thought I'd be recommending that as a solution to any problem...).
The most frightening thing I found about the newsforge story was the small amount of money given directly to Sen Hollings by the media industry players (~$100K). Now granted, that's not listing the large soft money contributions given to the party as a whole, etc, but without that, it seems like congresscritters are going cheap.
Question: if the open source community (both individuals and those corporations who benefit from it and aren't scared of the RIAA/MPAA) put some concerted money and effort into setting up a lobbying organization and buying back a few congresscritters, could we tip the scales?
Maybe this is the best approach -- separate out code as used to cause a computer to perform some function, and code used for communication between humans. In that role, using code as a means of expression has some unique benefits -- clarity, brevity, and lack of ambiguity not provided by other forms of speech (except mathematics, which is not usable for all subjects or all audiences).
This might open a loophole where pseudocode is alright, but "real" code is not. Pseudocode is used all over the academic literature to express ideas that can't be expressed effectively any other way. Sometimes the pseudocode is closer to a mathematical formula than to anything you'd really be able to put into a computer. Sometimes, however, only by staying close to what goes into the machine can you communicate what you need to -- e.g. code which is by its nature expressive or amusing (the obfuscated C code contest), or where the code itself demonstrates a novel, elegant, or particularly efficient approach (in a particular language) that impacts the usefulness of the algorithm being discussed. Some concrete examples:
A classic example of code used as a form of expression can be found in any ietf protocol standard, in the language called ASN.1 (I know, many people would call it more an abomination than expression). ASN.1 describes data structures, not computations, but it can be compiled directly into code to create and parse binary messages. And it is one one of the only forms of expression specific enough to really communicate what exactly should go across the wire at this time. So in most RFCs that specify wire protocols, the primary content of interest is in ASN.1. There's supporting content in English to tell you how to interpret some of the fields, but not enough to live without the ASN.1. The document would stand on its own as a communication tool between humans if all the English was stripped out, but not if the ASN.1 was removed and the English left alone. (I think you could make even a stronger statement for XML along these lines, because of its greater expressive freedom.)
Another, possibly less strong example of code as an irreplacable form of expression might be in books whose goal is to explain the workings of a particular body of code, or a particular system using the guts of an implementation as the best way to communicate (e.g. Wright & Steven's TCP/IP Illustrated Vol 2, which tells you how to build a TCP/IP stack using one as an example, or the annotated book version of the Linux Kernel).
I may not have a sufficient grasp of copyright law, and arguing that code is the only way to express certain concepts effectively, might not count as "expressive" in the manner necessary for copyright protection. But I think the argument is that code is to programmers like equations are to mathematicians might be more accessible to a judge than the intrinsic beauty of the obfuscated C code contest (alas ;-).