Subject: RISKS DIGEST 16.05 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 11 May 1994 Volume 16 : Issue 05 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Are we betting on horses or computers? (off-track betting) (Reva Freedman) Amusing computer-related anecdote about local cable service (H Morrow Long) MTV Sues Curry (Adam Curry) China Airlines A300 Crash (Mark Stalzer) Re: Elevators, Car bumpers and Cryptography... (Peter Wayner) Re: Bellcore cracks 129-digit RSA encryption code (Fred Cohen, Amos Shapir) Re: ACM Nightline (Robert Morris) Don't always believe those E-Mail addresses (A. Padgett Peterson) EFF's Kapor announces new cyberspace TV show (Kapor via Stanton McCandlish) Automation: request for input (Ken Funk) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 10 May 94 15:46:02 CDT From: freedman@merle.acns.nwu.edu Subject: Are we betting on horses or computers? (Risks of off-track betting) Illinois has off-track betting on horse races. You can place your bet at one of these legalized bookie joints, then watch the race on TV and collect your winnings. If you place your bet early in the day, you don't even have to wait around for the race. You can watch the race at home and come back later to collect. That's the theory, anyway. On Saturday, April 23, the computer system handling the betting for some of the remote sites crashed after the fourth race. People at the betting parlors were told that they couldn't place any more bets. But what about those who had placed their bets and left? When winners returned on Sunday to collect, they were surprised to learn that, from the racetrack's point of view, they had never placed a bet, and were offered only a refund of the cost of their ticket. So were losers, if they had kept their tickets and happened to hear about the computer crash. However, the fact that refunds were available was not listed in the newspaper with the race results, mentioned on the telephone hot line, or mentioned on cable TV broadcasts of the races. On Monday a class-action lawsuit was filed. By Tuesday, racetrack management had decided to pay up. The system, designed by Amtote International, had only been in operation for a month. On the other hand, state officials had sued Amtote before for deficiencies in the previous system. No description was given of the original failure, but newspaper reports (Chicago Tribune, 4/26/94 and 4/27/94) said that a hardware problem caused the backup system to fail. The new system was designed to be "user-friendly." I hate to say it, but the most user-friendly component in this incident was the lawyers! Reva Freedman freedman@merle.acns.nwu.edu ------------------------------ Date: 9 May 1994 17:21:07 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Subject: Amusing computer-related anecdote about local cable service A very interesting program was on Storer cable channel 70 last night [they call themself Comcast now, and serve the areas of West Haven, New Haven, and Hamden]. For a long time, only the following message was flashing at the top of the screen: ---------------------------------------------------------------- | Software Failure. Press left mouse button to continue. | | Error: 0000 0003 Task: 002006f0 | ---------------------------------------------------------------- Talk about having your software problems out where the world can see them. Didn't look like anyone was minding the store(r). I guess someone there had to press the left mouse button this morning... H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, (203)-432-{1248,1254} Long-Morrow@CS.Yale.EDU [In the old days, it was not unusual for a mouse to nibble into a cable. Now we have cable nibbling at the mouse. Turn(er)about is fare prey. PGN] ------------------------------ Date: 10 May 1994 03:44:36 -0400 From: curryco@panix.com (Adam Curry) Subject: MTV Sues Curry [IMAGE] MTV SUES CURRY Last update: May 10 1994 _New Jersey, May 10 1994_ I had planned to keep the following quiet until more information was available, but since several journalists have already caught wind of it, I decided to get it out into the open so my side of the story is heard as well. The domain I maintain and operate on the Internet, mtv.com was founded approximately one year ago. At that time I registered mtv.com with the InterNIC, purely because it was a cool address to have, and it was available. What a great "vanity plate"! The site quickly became a frequently accessed "hangout" on the net, with an average of 35000 accesses daily from Mosaic clients alone. During the start up months I had many conversations with executives at MTV Networks about my endeavours, which btw, were all financed out of my own pocket, and vps from MTV Programming as well as Viacom New Media were aware of what I was doing on the internet, and although they stated "MTV has no interest in the internet" they gave me their blessing and supported my efforts. This was enforced when I set up several email accounts on mtv.com for use in MTV's on-air programming. Ever since the summer of '93, popquiz@mtv.com was used for trivia quiz questions, that were then aired on MTV's "Most Wanted" a program I hosted at the time. Solicitations were made on the air, and the address was shown on the screen. For MTV's annual Valentines video dedications, viewers were offered the choice of calling in their dedications, or sending them via email to elove@mtv.com. I never charged MTV Networks for this service, I purely saw it as a cool feature to introduce to MTV's programming, spreading the "gospel", so to speak. Then I started to get a lot of press about mtv.com, and some people started to wake up at 1515 Broadway (MTV's HQ in New York City). And I was served with a "Cease and desist" on the use of mtv.com. MTV's attorneys claimed that there could be "confusion" for users of the internet, when connecting to *anything* that had the letters mtv in the address, and then receiving music and entertainment information. I was obviously hurt by this move, but did see what point they were driving at, an asked if we could settle this matter amicably. The situation cooled down for a couple of months, but when I resigned on-air from my job as a VJ, which MTV chose not to air btw, things started to get ugly. Long story short, MTV Networks has filed a lawsuit against me, for copyright infringement of their "trademark", that being their "MTV" call letters, as well as having information online that was MTVN "property". In this case they are referring to several press releases I put up on mtv.com, such an announcement about Beavis and Butthead's "experience" cd release. Understand that MTVN sent me these releases over their own internal computer network for this very purpose! Again, I was only doing this to promote the channel, not for my own personal gain..after all...mtv.com is free access for all, no charge. Throughout all of this I have offered to maintain the site specifically for mtv, but again they said "we're not interested". Of course, I have no problem whatsoever removing all references to MTV Networks and it's projects from mtv.com, no that I don't work there anymore gives me even more reason to want to do this, but the kicker is they are moving for an injunction to make me stop using the internet address mtv.com! This is of course totally unacceptable: I registered the domain name, and I don't plan on giving it up. Sure MTV and their parent company Viacom have a vast legal team, but david also nailed goliath, so I have faith. In the long run, everyone knows that the only *true* winners will be the lawyers. There are many different viewpoints on this situation, but I feel that the use of mtv in an addressing scheme can't be seen as an infringement of intellectual property laws, and a search of the InterNIC database shows at least 15 domain names registered with mtv in the address. Irony is that I incorporated a company called ON RAMP, Inc (tm) and onramp.com was already registered to someone else, but I'm not suing them :) It appears to me that MTV has their mind set on the address mtv.com, maybe not for now, but possibly for future use, and I feel extremely used, in that I built up quite an audience for that address, and they are basically saying "thank you very much, you may go". A pre-motion hearing is scheduled for this thursday morning at 11am, wit the honourable Judge McKenna presiding, in an attempt to get an injunction to make me stop using the address mtv.com. I will update the situation as it unfolds. Adam Curry, adam@mtv.com ------------------------------ Date: Wed, 11 May 1994 09:02:33 +0800 From: stalzer@macaw.hrl.hac.com Subject: China Airlines A300 Crash The L.A. Times today (May 11) published a story on the A300 crash last month at Japan's Nagoya airport. I'll quote the first paragraph and then summarize the remainder of the story. "A terrifying battle between an inexperienced co-pilot and his airplane's super-sophisticated computer system preceded last month's crash of a Taiwanese jetliner that killed 264 people..." The events described in the rest of the article are as follows: 1. The plane was being hand-flown on approach to landing by its 26-year-old copilot. 2. About 2 minutes prior to landing, the A300 went into "go-around" mode for reasons unknown. 3. Even though the pilot warned the co-pilot 3 times in 30 seconds, as recorded by the voice recorder, the co-pilot continued to attempt to land the plane. The effect was that the auto-pilot was trying to pitch the nose up using the "horizontal stabilizer flaps" while the co-pilot was trying to pitch the nose down using the "elevator flaps" (the Times author might have this a bit confused). 4. The crew then switched the "go-around" mode off. However, the "stabilizer flaps remained set at a sharp angle." 5. The crew realized the plane was too high to land, so they set the "go-around" mode back on. 6. This caused the plane to climb sharply and approach a stall. The A300 stall-prevention system automatically increased the engine thrust but this INCREASED the climb angle to 53degs. 7. The airplane stalled. 8. The nose dropped and the airspeed increased to 150mph at an altitude of 260 yards. 9. At this point, the entire electrical system stopped functioning for reasons unknown, including the flight data and voice recorders. 10. The plane crashed, killing 264 people. There were 7 survivors. The root cause of this crash seems to be a confused co-pilot. However, the A300's automatic systems contributed in two ways. First, it continued to attempt the go-around even though the plane was still being flown by hand. Had the auto-pilot disengaged (with a suitable warning!) this whole disaster may have been adverted. I think a human supplying control inputs is the "final authority" and the automatic systems should "back off". Second, the stall-prevention system's actions (increasing thrust) contributed to the stall. This is a serious kind of failure, if a automatic system designed to prevent a problem makes it worse, it should do nothing at all! -- Mark Stalzer (stalzer@macaw.hrl.hac.com) ------------------------------ Date: Tue, 10 May 1994 15:37:05 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Re: Elevators, Car bumpers and Cryptography... I once talked to a major elevator company about doing just what the Schindler Elevator Corp. is accused of doing by the Toronto government. (RISKS-16.04). The company told me that they were in the habit of selling the elevators at a loss so they could make up the money in service contracts. Then they found themselves battling independent service companies who undercut their prices. They hoped to use cryptography to lock out any other service provider without the right key. Of course, this loss-lead approach is common in many businesses. Car companies often sell their cars at a low price and hope to make it up selling spare parts later. That is why I discovered that a spare bumper for my car cost over $500. The difference is that other companies are now making duplicate parts. The major automakers can try and discourage them, but they can't lock them out of the business. Cryptographic locks, though, are a different story. They probably can't be broken in a reasonable amount of time. (See also 16-04) I'm not sure of the case law on this, but I would suspect that it might fall under questionable or illegal trade practices. At least in the US. ------------------------------ Date: Tue, 10 May 94 19:33:36 PDT From: Fredrick B. Cohen Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04) I think a lot of people are missing the real point about the RSA. On my pocket PC, I can create a code that requires 5,000 MIP years to break in a matter of seconds. If I am willing to use several more seconds, I can make a code that takes 10^25 MIPS years to break. Compare this to any other encryption scheme, and you will find that the workload amplification of the RSA is quite good. And Shannon told us in 1949 that any non-perfect information transform can be broken with enough cyphertext - and developed the concept of workload for evaluating cryptosystems. If we want perfect cryptosystems we know how to get them, but it requires secure distribution. On the other hand, the RSA provides any degree of complexity we wish to generate (finite) and a fantastic complexity amplification factor, and the advantages of a dual public key system that can be used for both encryption and authentication. The point is that the RSA has not been broken, rather it has shown just how much of a David is required to defeat a given Goliath. After all, in terms of that story, David would have been a MIP second and Goliath 5,000 MIP years in relative sizes for a break-even fight. I'll take that David any day. FC ------------------------------ Date: 11 May 1994 15:19:01 GMT From: amos@CS.HUJI.AC.IL (Amos Shapir) Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04) > So where does the 40 quadrillion figure come from? It comes from this very table. 10^9 is a billion, not a trillion, in the US system, and 40 quadrillion is 4 x 10^16, which is even less than what I get by interpolating to 425 bits (can anyone who has access to the original RSA article verify this?). There seems to be an interesting risk here: most encryption methods rely on "hard" problems, i.e. problems whose "brute force" solutions require computation resources which are an exponential function of the key length. But in a world in which computing power grows exponentially, such problems can be solved in polynomial (or even linear) time! Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel +972 2 585706,586950 amos@cs.huji.ac.il ------------------------------ Date: Wed, 11 May 1994 10:09:00 -0400 From: Robert Morris Subject: Re: ACM Nightline (Kabay, RISKS-16.03) >...they have _no right_ to use the product without that contractual agreement. This confuses several issues--that of theft, that of use and that of licensing, and in an important case Kabay's implied position is wrong. Certainly---and this is his main point---theft of intellectual property is theft. However, property protected by U.S. intellectual property laws, notably copyright and patent protection (especially the latter)---can not simply be withheld from use at the whim of the owner. For example, patent holders MUST license equally to all who meet reasonable terms. Indeed, the _purpose_ of copyright and patent protection is to promote the widest possible access to the new ideas by insuring that their creators have economic motivation to do develop them. The owners of intellectual property who want to restrict its distribution are expected to look to the trade secret laws to protect them. I'm not sure what requirements are imposed on copyright holders (and as an aside, I sure would like The National Computer Security Assn. to argue that copyright, not patent, is the only appropriate form of protestation for software! heh, heh, heh.), but I suspect they can not capriciously and arbitrarily withhold copy permission from some but not others, and it will even surprise me if they can put irrelevant terms in the copy permission. None of this speaks to licensing, but (I speculate) the only legal culprit in a licensing violation is the licensee who allowed the copy. And presumably that contract violation is a civil, not a criminal matter in American law. Bob, not an attorney, Morris ------------------------------ Date: Wed, 11 May 94 08:17:46 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, Information Security) Subject: Don't always believe those E-Mail addresses One of the more subtle RISKS of E-Mail is in believing what you see. Recently a good friend of mine was repeatedly accused of posting not-so-nice messages on various news-groups. Not so blatant as to be unbelievable but morally damaging. This irritates me. A few months ago I was flamed in RISKS for talking about the use of Ethernet card firmware addresses as for tracking. Two weeks ago it enabled me to quickly and positively identify the source of repeated failed attempts to log into an Ethernet server as supervisor. When I asked the administrator for the data in the log, he told me that he had never known that the six hex bytes had a meaning. Similarly, forged E-Mail is possible only because many E-Mail packages throw away the Ethernet wrapper that made the communication possible in the first place, a wrapper that *must* contain the return address or "the mail won't go through". Here I have FTP Software's (plug) PCTCP which provides an MSDOS machine with more built-in features than many UNIX implementations (won't go into them all else it would be an adv't but will just say that it allows me to identify not only the source, but the path used to get here). For example what most people see in an E-Mail posting is this (lines have been wrapped to 80 characters & true returns masked) - Judge and Goat are two PCs in my office. ----------------------------------------------------------------- From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34 To: padgett@goat.ppp.qqq.rrr Return-Path: Demonstration of message headers. ----------------------------------------------------------------- What was actually received from the SMTP server was this but most newsgroups & many mailers strip the "Received: from..." as above: ----------------------------------------------------------------- From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34 X-Envelope-To: padgett@goat.ppp.qqq.rrr Return-Path: Received: from judge.ppp.qqq.rrr ([123.456.789.000]) by Goat.ppp.qqq.rrr (SMTPSRV); Wed 11 May 1994 07:34 Demonstration of message headers. ----------------------------------------------------------------- Note that not only the originating name is sent but also the true IP address [123.456.789.000]. Again this *must* be there. Not to say that this is not a valuable capability since I prefer that all incoming E-Mail come to a common point, just don't rely on them since they can be *anything* the sender wishes. Don't just toss those wrappers, dispose of them properly. Padgett ------------------------------ Date: Tue, 10 May 1994 20:47:23 -0400 (EDT) From: Stanton McCandlish Subject: EFF's Kapor announces new cyberspace tv show Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist Forwarded message: Date: Tue, 10 May 1994 09:13:23 -0400 From: mkapor@kei.com (Mitchell Kapor) Subject: My tv show (I thought you might be interested in this.) New Cyberspace TV Program I am developing a new program on cyberspace in conjunction with WGBH-TV, PBS' Boston affiliate. The show is intended to be a window onto the world of computer networks for the television viewer, whose point of view is that the world of on-line communications is interesting because of what people do there, not because of the digital plumbing which enables it. We will be focusing on the human aspects of networking and the individual and social aspects of being on-line. Cyberspace will be portrayed as a not-so-really strange territory after all, where all of us will increasingly come to live and work. My role is to guide people through this new territory, introducing the audience to its native culture, its scenic attraction, and its sights and sounds. We assume our audience is motivated by curiosity to learn more about what goes on in cyberspace, but we do not assume they are knowledgeable or, in general experienced with it. On the other hand, we will not trivialize the subject matter by reducing it to a least common denominator. We will give the show a look and feel which is approachable and down-to-earth. Interview guests and roundtable participants will be drawn from the net community itself. There will be plenty of demos of cool net stuff from Mosaic, CU See Me, and other cutting-edge applications and services. We are taping two test shows in mid-June which will be shown in Boston and other cities and hope to have some sort of national distribution (to be determined) in the fall for a regularly scheduled program. We are also going to create a WWW server for the show, the segments of which will be downloadable. The server will be have on it additional material which won't fit into the show format. An Invitation: We would like to include some video clips of net citizens expressing their greatest hope and worst fear about the future of the net which we will edit into an on-air piece for our regular feedback session. It's important to me to have the voices heard (and faces seen) of people already on the net. This is an opportunity for those of us who enjoy appreciate the decentralized and democratic character to express that sentiment to a mass audience. I hope you'll take advantage of the opportunity. Guidelines: Since an individual on-air clip will run at most 20-30 seconds, please keep your statement succinct. In shooting the clip, please feel free to pick a location which says something about yourself, whether it's your computer, your pet, or the great outdoors. We can accept Quicktime movies, VHS cassettes, or 8mm tapes. If you enclose a mailer, we will return your tape. We can also pick up digital submissions from any FTP site, etc. Contact Information: email: cybertv@kei.com Postal: CyberTV c/o Kapor Enterprises, Inc. 238 Main St., Suite 400 Cambridge MA 02142 ------------------------------ Date: Thu, 28 Apr 94 06:59:08 PDT From: funkk@ENGR.ORST.EDU (Ken Funk) Subject: Automation: request for input Oregon State University, America West Airlines, and Honeywell are conducting a study of flightdeck automation for the Federal Aviation Administration which requires input from the scientific community. The increasing use of automation on the flightdecks of commercial transport aircraft has raised concerns about the overall safety effects of this equipment. While several studies have attempted to address some of these automation issues, until now no one has tried to systematically identify all issues that exist about flightdeck automation. The objectives of this study are to collect and compile a comprehensive list of all flightdeck automation problems and concerns and to address them in order to identify or generate recommendations and guidelines for the FAA, manufacturers, and operators. To achieve these objectives we are soliciting information on automation problems and concerns from individuals in a variety of disciplines. When we have compiled these problems and concerns we will prioritize them, study the highest priority items using analytic methods and simulator studies, and identify and develop recommendations based on our findings. Although we are primarily targeting the aviation community for sources of automation problems and concerns, we recognize that individuals in other disciplines have knowledge of other kinds of system automation and know of automation problems or have concerns about automation that would be very relevant to our study. Experts in computer science, human factors engineering, psychology, and other fields often deal with the automation of industrial systems, office equipment, and even consumer devices, so we welcome information from them. If you have direct knowledge about system automation and you know of problems with or have concerns about the safety of such automation, you can help us by filling out a copy of our Automation Problems and Concerns Questionnaire. This is an opportunity for you to contribute to flight safety and, if you wish, we will put you on our distribution list to receive copies of reports on the results of our study. If you would like to fill out a questionnaire, send a message to flight@engr.orst.edu (don't post your request to this newsgroup!). Request a copy of the Automation Questionnaire, and I will send you a copy via e-mail. When you have completed it (which should take between 15 and 30 minutes), just e-mail the completed version back to me. The problems and concerns you identify will be added to our database and used in our study. Ken Funk, Assistant Professor of Ind. and Mfg. Engineering, Oregon State Univ. flight@engr.orst.edu, funkk@engr.orst.edu (503) 737-2357 FAX: (503) 737-5241 ------------------------------ Date: 9 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.05 ************************