Talk:Lecture 15
Why aren't computers more stable?
David Dorwin The issue of computers being very unstable compared to the phone system came up in the lecture tonight. I'll open up the discussion and look forward to others' comments.
One reason is that consumers are not willing to pay for it. You can't have a $500 laptop with all the features you demand and still pay for the development and validation of really stable applications. The same is true for the $40 scanner with drivers that sometimes crash. Corporations make business decisions about how much they can afford to put into development and resolving such issues. I have a feeling that they often decide that the issues aren't upsetting enough customers or to enough extent to justify spending time and money on the problem. As competition continues to drive prices down, there is even less money to spend on validation and fixing bugs. In some ways, the issue is analogous to the outsourcing debate – Americans complain that jobs are going overseas then go Wal-Mart and leave with bags full of stuff from China.
Another factor when comparing PCs to most other products is the number of companies involved. I’m guessing that the telephone network is comprised of components and software from tens of companies. The same logic goes for your car. The maker specs each of the components that go into your car and verified that they work well together. Even if you buy third-party (non-maker brand) parts, there is a limited number of companies making each part and they have (hopefully) verified that they work in the cars they are designed for. In most cases, parts interact with only a few other parts, so this would seem to reduce the potential for problems. As an example, your oil filter doesn’t interact with or share resources with your shocks, tires, or stereo. The number of companies or individuals that are writing software and drivers for Windows XP is nearly countless. All of them must work well together, and if there is a bug (memory leak, runaway process, bug check, etc.) in any one of them, it can make the entire computer appear unstable.
Red/Green/Blue - are color schemes/perimeter defenses still viable?
It was interesting to note the analogies drawn with conventionl warfare/castles etc. However can such a scheme be viable today? Ed had raised this question, using examples of users bringing in floppy disks, USB drives and such. Another aspect is users taking their laptops home or while travelling and VPN'ing into the corporate network. The problem with planning a perimeter defense is that there is no perimeter anymore. The example of VPN and mobility of elements also suggests that a color scheme would also have to consider the factor of time (or location depending on the way you look at it). A laptop when connected from inside the corporate network, is "Green". But when VPN'ed in it's "Blue" or even "Red" (it's pretty easy to hack the usual VPN settings so that you have access to both the internet and your corporate network). Talking about colors started me thinking of Butler Lampson's talk. He had presented such a colorful lecture on the red/green security zones on PCs. Butler used only 2 colors, but one can easily think of the use of more colors or security levels. E.g. a blue layer, through which all data movement occurs between red and green layers. Well, given that we are considering such schemes; what that signifies to me is that the perimeter has been invaded and become so fragmented that we now have the need for security layers on our own individual workstations!! Pretty depressing, I think something went wrong somewhere.
--Chris DuPuis 08:18, 8 December 2005 (PST) I would contend that any network design that even lets users' desktop systems be inside the "Green" zone is fundamentally insecure. Really, you don't want trouble caused by users' vulnerable applications, especially their email client and web browser, to be able to take out your mission-critical systems. This goes doubly for laptops, which are entirely outside your control once users leave the building with them.
