Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!qucdn!spraggej From: SPRAGGEJ@QUCDN.QueensU.CA (John G. Spragge) Newsgroups: comp.org.eff.talk Subject: Re: "Computers at Risk" Message-ID: <90349.173353SPRAGGEJ@QUCDN.QueensU.CA> Date: 15 Dec 90 22:33:53 GMT References: <1990Dec11.213718.13211@Think.COM> <90349.014530SPRAGGEJ@QUCDN.QueensU.CA> <1990Dec15.174416.6338@Think.COM> Distribution: na Organization: Queen's University at Kingston Lines: 83 In article <1990Dec15.174416.6338@Think.COM>, barmar@think.com (Barry Margolin) says: >References: ><1990Dec11.213718.13211@Think.COM> <90349.014530SPRAGGEJ@QUCDN.QueensU.CA> >The recommendation wouldn't depend at all on the planned use of the >computer? I admit that there are environments where security is not >tantamount, but for applications such as banking and the Defense >Department, security can be very important. I'm not interested in providing software for military purposes. As for financial transactions: yes, I agree they ought to be secure. However, in banking, as in every other field, it is equally important that the system work to avoid errors, which can have consequences that are just as severe, if not more so, than security breaches. Discussing this with other business people, I heard of one large commercial organisation that made an error in the supplier's favour in 20% of their transactions. If that had been caused by sabotage, it would have been reported as a nice haul. >They must pay more attention to details, because that's where most security >flaws are. Better design and development methodologies are used. Good >system structuring is necessary so that it is possible to understand the >system and believe that it is secure. Once you are in this mindset, it is >normal to think this way for all the software on the system, not just the >security-related parts. For instance, in Multics development, all changes >to the system are subject to peer review of the proposed change, and the >code must be reviewed and approved by at least one other developer familiar >with that area of the system. This is a somewhat circular argument. The desire for a secure system leads to the development of "better" design techniques, which are by definition "better" because they allow you to verify system security. I understand what you are saying: any determined pursuit of a goal will focus your efforts, and in software design that usually produces clearer, "better" thinking. But I don't think you have established that the quest for security will lead to better results than a quest for "user friendliness", or simply error free code. >The same design processes that result in more correct systems can also >produce easier to use systems. For instance, the peer design review was >good at preventing user interface inconsistencies from being implemented. Peer review is only useful for determining user friendliness if the "peers" in question are also the end-users of the systems. If this is not the case, you also need "user review". The internals of the system should be designed as consistently as possible, but with human interactions, logic doesn't work the same way. In some cases, what is consistent to the user may seem very inconsistent to the software designers. In such a case, if the user's view does not agree with the programmer's, I would argue the program is not "user friendly", and likely to be part of a disaster down the line. > And if your >personal computer hasn't been hit by a virus, you've just been lucky so >far; I think part of the problem is an "it won't happen to me" attitude by >many people. I haven't been hit by a virus (that I know of) because I religiously crank up the virus scanner for every disk that goes into or out of my computer that could be carrying viruses. I have still had to deal with massive data losses caused by "user error" (read: systems that weren't easy enough to understand or use). And before you tell me that I'm blaming the system for my mistakes, they were someone else's mistakes: I just had to clean them up. And I see no reason we should expect to "educate" naive users to accept things that we as a programmer community think are "user friendly enough". I do take security seriously, in its place. I merely insist that it ought not to be top priority for 90%+ of applications. >-- >Barry Margolin, Thinking Machines Corp. > >barmar@think.com >{uunet,harvard}!think!barmar disclaimer: Queen's University merely supplies me with computer services, and they are responsible for neither my opinions or my ignorance. John G. Spragge