Subject: RISKS DIGEST 12.33 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Sunday 15 September 1991 Volume 12 : Issue 33 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: British Telecom computer failure cuts off 42000 (Paul Leyland) Security Software Bug Locks Up System (Sanford Sherizen) Companies Steal Information (Sanford Sherizen) Industrial espionage (Jerry Leichter) Re: Junk Mail ... 737 crash (Steven Philipson) RSA vs. NIST (digital security standards) (Tom Slone) Re: Salomon Brothers -- Database Design (Gary Beckmann) Secret Computations the basis for Corporate Decisions (Jeffrey Sorensen) Re: +&*#$ (Bob Clements, H. Fuss) History of Internationalization of ASCII (Paul Green, Lars Henrik Mathiesen) Export controls on workstations, or, more mantras (Jerry Leichter) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. 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. ---------------------------------------------------------------------- Date: Fri, 13 Sep 91 13:15:30 +0100 From: Paul Leyland Subject: British Telecom computer failure cuts off 42000 A very brief report appears in the Friday 13th edition of _The Times_ (London): 42,000 cut off Police sent out emergency patrols after a British Telecom computer breakdown cut off telephones in 42,000 homes and businesses in the West Midlands ------------------------------ Date: Sun, 15 Sep 91 19:57 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: Security Software Bug Locks Up System The 9Sep91 issue of Computerworld had an interesting twist on security and reliability. A faulty piece of code embedded in the Tandem Safeguard security system interpreted 4:22 PM on 27 August as an impossible command. Affected systems tumbled into an endless loop that tied up all computer resources. The security package then locked up the system. The only way to fix the problem, once it began, was to take the affected computers off-line before restarting them. Starting in Asia and continuing on to Europe, the appointed hour of doom arrived, precipitating system shutdowns. Users in the U.S. were warned by last-minute phone calls. (Luckily, there were no phone outages this time.) In an understatement, the writer said that some sources expected Tandem to announce a fix later this fall. Security is becoming more system critical, sometimes in ways that are not easily anticipated. Unless non-security aspects of system are fully tested and integrated, the need to have security controls shut down systems in the event of a (perceived) attack may lead to inappropriate system lockdowns and other large-scale problems for hospital and other critical applications. Sandy ------------------------------ Date: Sun, 15 Sep 91 19:56 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: Companies Steal Information The Boston Globe (13Sep91) had an article on the competition between traffic spotting services that sell their information to the media and to commuters. A federal lawsuit alleges information piracy, theft and use of trade secrets, which involved listening in over two-way radios. Metro Traffic Control said that it feared piracy of its information by a new competitor, SmartRoute Systems, and created a disinformation program that passed made-up reports on traffic troubles. This was reported by company employees over the radios to the Metro Traffic headquarters (but not passed on to the media customers). SmartRoute is charged with getting that information and passing it on to their radio customers, who broadcast it. An example of planted information that the lawsuit contends was stolen and broadcast include a report on a dog running loose in the South Station tunnel. (A personal note: I thought that I saw the dog but it could have been a politician looking for votes.) This example, as well as the Samurai Hacker article from Rolling Stone, are just a few indications that information stealing and manipulation is no longer a phone phreak/hacker issues. There is a long history of businesses misusing information and attempting to restrict information by others. Increasingly, these misuses have moved into learning from and using acts that these companies and others have condemned as hacker terror. It will not be long before we hear about a company setting off a virus against its competitors in order to gain a larger market share. Competitive business intelligence has become an accepted form of industrial espionage, with major corporations reporting a trend to establish intelligence gathering units as a necessary part of marketing research. There are some dangerous trends here that can erase the lines between legitimate and illegitimate acts. The computer crime of today may become the business strategy of tomorrow. It is getting tough to tell the good from the bad, for the scorecards don't list all of the players, the rules, or even the referees. Sandy ------------------------------ Date: Fri, 13 Sep 91 23:06:56 EDT From: Jerry Leichter Subject: Industrial espionage I heard on All Things Considered tonight that one of the TV news magazines is reporting that the French have a large industrial espionage operation in effect. The data, gathered by the French intelligence services, are distributed to French companies to help them in business. According to this report, the seats on Air France flights have been bugged, and some of the passengers are crew are actually intelligence agents. Question: If these reports are confirmed (of even if they aren't but cannot be fully refuted), would you ever consider buying a French computer, or even French software? Are other countries playing the same game? Attempts by US government agencies (especially the NSA) to play a role in specifying cryptographic techniques raises huge suspicions. Just who CAN you trust to sell you equipment you can confidentially use to store important restricted data on? Can you only safely use such equipment if you can guarantee that it's not connected to the networks, and that it's never touched by people you don't completely trust? Consider how much interesting data a disk with an intelligent interface could squirrel away on a board that then gets replaced.... -- Jerry ------------------------------ Date: Thu, 12 Sep 91 18:17:21 -0700 From: stevenp@kodak.pa.dec.com (Steven Philipson) Subject: Re: Junk Mail -- In memoriam, Dave Sharp (Mellor, RISKS-12.31) >... collision between a 737 and a private aircraft The collision was between two aircraft in commercial service, the smaller of which was a Swearingen Metro turboprop, certified and operating as an airliner. General Aviation frequently gets a bum rap. No reason to blame that segment of the community for something in which it wasn't involved. ------------------------------ Date: Thu, 12 Sep 91 21:06:45 PDT From: potency@violet.berkeley.edu (Tom Slone) Subject: RSA vs. NIST (digital security standards) The National Institute of Standards (NIST) has proposed a standard for secure encryption of messages for non-classified digital electronic transmissions. The method relies on a method that lacks widespread familiarity among cryptographers. RSA is the name of the most widely known and used cryptographic method; it is controlled by several patents. The patenting of RSA led NIST to seek a non-patented method that could be used as a standard. The NIST proposal and RSA both use pairs of related cryptographic keys: one to encode and one to decode the data. The difference in the two methods lies in how the keys are generated. RSA relies on the difficulty of factoring large prime numbers, and the NIST proposal relies on the difficulty of generating something called "discrete logarithms", presumably these are logarithms that have truncated to a finite but large length. Jim Bidzos, president of RSA Data Security Inc. (owner of at least one of the RSA patents), said, "If no one challenges what they've [NIST] done, we'll be stuck with a weakened standard." Obviously, Bidzos is biased, since his company would potentially lose out should a non-RSA standard be adopted. But there is some merit in his statement since knowledge of prime-factoring has a long mathematical history, and discrete logarithms is presumably a new sub-field. [Science News 140(10):148(1991)] There would seem to be merit both in having a standard and in not having one. The lack of a Federal standard has apparently hindered the commercial use of encryptions schemes, so data transmission has been insecure. The existence of a single standard, however, would seem to be more vulnerable to cracking via technological and/or mathematical advances. Recall the recent advances in factoring primes made possible by the combination of better algorithms and inexpensive, fast computers. These advances have forced made it necessary to increase the length of encryption keys for the RSA method. ------------------------------ Date: Fri, 13 Sep 91 09:47:55 EDT From: beckmann@das.harvard.edu (Gary Beckmann) Subject: Re: Salomon Brothers -- Database Design (Drake, RISKS-12.29 I have a good friend who works for one of the large financial houses, and he informs me that very often the programmer will be brought in for a few weeks to implement a design that very likely has not been reviewed by anyone (especially not the end user!!) except the manager who has ordered the design. There is no reason to assume that other companies work differently. The pressure in the field is simply too great for the people to "worry about such things". Seems to me that they are setting themselves up for more experiences like the Salomon Brothers. Gary Beckmann beckmann@das.harvard.edu ------------------------------ Date: Fri, 13 Sep 91 10:40:01 EDT From: sorensen@spl.ecse.rpi.edu (Jeffrey Sorensen) Subject: Secret Computations the basis for Corporate Decisions On the topic of risk assessment, a particularly chilling episode is discussed in _The Media Monopoly_ by Ben Bagdikian. Some excerpts: [Mark] Dowie is the investigative reporter who disclosed that the Ford Motor Company and knowingly produced dangerous gas tanks in its Pinto cars, having decided that it was cheaper to pay off heirs of the dead than to spend a few dollars per car to make the tanks safer. The book he was proposing in 1979 would examine the history of this kind of corporate decision making. ... [Beginning with] Cornelius Vanderbilt, who rejected air brakes for his nineteenth-century trains. [The editor Nan] Talese was excited. One of the most respected editors in New York, she had produced a series of successes for her employer, Simon & Schuster. ...Dowie, almost as an afterthought, said, "Do you think the title, _Corporate Murder_, will be acceptable." Talese then asked an odd question: "Is Gulf and Western one of the corporations?" When Dowie said the book did not mention Gulf + Western, Talese said, "Fine. I don't think we'll have any problem getting that title past our corporate people." But she was mistaken. Even though she and her staff unanimously supported the book, neither the title nor the book itself was acceptable. ...The president of Simon & Schuster, Richard Snyder, was vehemently opposed to the manuscrip because, among other reasons, he felt it made all corporations look bad. If Simon & Schuster had been an independent book company, as it once was, [and, not owned by Gulf + Western,] Tales would not have asked an author the question she asked Dowie. It is also possible that Dowie's manuscript would now be available to the public, which, as of 1987, it was not. For more info see pp.27-31 in _The Media Monopoly_ 3rd edition, 1990 by Ben H. Bagdikian, ISBN 0-8090-6156-X published by Beacon Press. The field of risk assessment involves numerous assumptions at every calculation, and if these assumptions are wrong, the resulting decisions will also be wrong. The errors will continue to be wrong because these assumptions are not effectively challenged by open and competitive ideas. In an era of almost complete control of the media by a handful of monopolies, the assumptions involved in risk assessment are deliberately withheld from public scrutiny to create the illusion that the trade-offs between safety and cost are not being computed, when, clearly, they must be. The result is, we are left with no information discussing the _philosophy_ of risk assessment while on a daily basis risk assessment continues in the back closets of our many institutions... Jeff Sorensen sorensen@ecse.rpi.edu (518) 276-8202 ------------------------------ Date: Fri, 13 Sep 91 10:41:20 -0400 From: clements@BBN.COM Subject: Re: +&*#$ In RISKS-12.31, Dik T. Winter mentions that some Yugoslavian license plates are distinguished only by a diacritical mark, and Mike Morris reports on trouble with the encoding of Ham Radio callsign plates in California. Here in Massachusetts, those two themes are combined. Someone decided that our Ham plates should have a jagged line (stylized lightning bolt) after the digit in the callsign. My plate reads "K1BC". This is actually encoded in the RMV computer as "K1/BC". In the continuing effort to raise money, the RMV started issuing some more patterns of low-numbered (extra fee) plates a few years ago. One of the patterns is , such as "A2A". The FCC has allocated that pattern to ham radio callsigns, too, though it has only issued one such callsign that I know of ("N6V", to JPL's ham club, for a short period, in honor of the Voyager flight). It is entirely possible that they may issue more of them, though, and if my call were "K1B" then there would likely be both a "K1B" and a "K1/B" plate in the computer. Admittedly they would be distinguished in the computer by a "real" character, but not by the one actually on the plate, the "lightning bolt". Queries to the computer would seem pretty likely to be confused, with the consequent RISKS. [Two asides that I can't resist: I looked up the "hajek" (Dik Winter's spelling) in the dictionary. I found it listed as a "haek". So in our ASCII forum we can't even enter the name of the character we are talking about. And, to top it off, the dictionary that I checked was the one commonly referred to as the W9NCD, which acronym is itself a Ham Radio callsign issued to a gentleman named Dunbar in Clinton, Wisconsin.] Bob Clements, K1BC ------------------------------ Date: Fri, 13 Sep 91 17:07 From: "H.Fuss= F1Fuss@DBNGMD21.bitnet" Subject: re: ##$@*, !names, umlauts and other nonstandard print chars and: mis-printed official documents Besides those umlauts "a, "o, "u, "A, "O, "U (the dots are supposed to sit _upon_ the characters) and the use of the dots as diaeresis, we in Germany have one more special character, a special form of double-s. Though pronounced `es-zet', it has nothing to do with `sz', but derives from a ligature of two different s's: a 'long-s' (which looked roughly like an 'f' without the horizontal bar), used in the middle and beginning of words and syllables, and a 'round-s', used at ends. The nearest glyph to an `es-zet' is a greek 'beta'. (For explanation, please read 'long-s' instead of 'f' in the following 7 words: is, fend, eafy, mistake, grafs, clafsroom, H.Fufs). As 'round-s' appears at ends only, there is no upper-case `es-zet'. However, computers and their chain printers had (numbers... and)... uppercase letters only, so all the `special characters' had to be replaced by something else, and the `Duden', the official spelling book for schools etc. suggests a additional `e' for the umlauts (what is in line with the history of handwriting since medieval times) i.e. `ae' for `"a' etc., and `ss' for the missing `es-zet'. (Interesting aside: the case of a Herr `Sch"on', who refused to accept official letters addressed to `Herr Schoen', -- which was decided against him, and his second case, an application for an official change of his family name from `Sch"on' to `Schoen' ((in order to accept properly addressed letters now)) -- which was also decided against him.) According to this, my name was officially printed as `FUSS'. However again, when printers were able to print lower case letters as well (and available in state administration), very clever people decided --for easy readability!-- to use the font `small capitals' a-n-d an additional 'beta'-like glyph for the `es-zet'. As 'small capitals' are nearly as tall as ordinary capital letters, and as a misprinted 'beta' among all capitals looks more like a poorly printed 'B', my passport carries at first sight the name 'FUB'. My wish, to print my name according to `Duden' as `Fuss', because I might get into troubles at foreign borders, whose policemen might not know `es-zet's and might accuse me of using false documents (passport differs from visa and customs documents) was turned down: not Duden, but _l_a_w_ decides how to write names, and they had their rules!! (Up to now, I did not yet have problems from wrong name-spelling in foreign countries (borders), perhaps it could have been that messages for Mr.Fub did not get to Mr.Fuss in his hotel, and vice versa). .... BUT IT COULD BE WORSE!!!! Following is the sad story of my friend Cesar Fernandes L. As everybody in the civilized world knows, everybody has one or more first (`Christian', given) name(s) and a family name (inherited). (In Germany, one has 1-3 first names, but to have more is a little unusual, but nothing wrong with). As everybody knows, first-names come first, and family-name is last (only in some official administrations the order is, for sorting and finding reasons, reversed); this is important if somebody's family name should be a first name (e.g. the ketchup producer Heinz), or if somebody has a first name which is rare and therefore not recognized as a first name by everybody (e.g. Orlambugo). Some people carry their first name(s) as initials only; some people have some abbreviations as an addition to their name, e.g. Dr., MdB (=MP), etc. (omission of rules of how inheriting family manes... but...) There are countries, where the equality of sexes is more advanced than in our country, e.g. in Chile. There everybody has t-w-o family names, one from his father, the second from his mother. (In order not to exaggerate the equality of sex, the second family name, which is the less important one, is very often abbreviated, because it is only the resp. first of the two names which is transferred to the children, and in this order: father(1), mother(1).) The signature of my friend Cesar Juan Adolpho FERNANDEZ Lopes is: Cesar Fernandez L. Everywhere in an index, he is listed under the letter F. There are not 2 family names in Germany, so he got into troubles with his official documents when he stayed here for several years; they offered him to list his name as Cesar ... Fernandez-Lopes, (because family names are positioned last -- and not as last-but-one), but that steals him one name, because it is quite possible to have a hyphenated (first) family name. Finally, the case was decided that he has officially to be listed as Cesar Juan Adolpho Lopez FERNANDEZ; according to the rule: family names are at the end (e.g. in his international drivers license). When he returned to Chile and once had to produce his drivers license, he was detained into custody because of using false documents, here those of somebody else, namely those of Senor (Mr.) Cesar Juan Adolpho LOPEZ Fernandez. Risks of unflexible use of computerized prints. Dr. H.Fuss, Inst. of Foundations, National Research Centre of Information Technology, 5205 St.Augustin / Bonn, Germany ------------------------------ Date: Fri, 13 Sep 91 17:06 EDT From: Paul_Green@vos.stratus.com Subject: History of Internationalization of ASCII (RISKS 12.30-32) I think we may be getting off of the part of this debate central to RISKS, but as someone who has some familiarity with this area, I can't help but correct some of the earlier statements. The real history of internationalization is far more complex than the mail so far would suggest, and far less sinister. I believe that simple economics has dictated most of the decisions. Hugh Davies notes (in RISKS 12.30) that "European consumers demand that their consumer products 'talk' to them in their language." It isn't just the Europeans; every prospective customer I've ever met wants this. Those of us on the vendor side have to balance what we can do with what people are willing to pay. Those replacements of square brackets, etc., that he complains about were an official part of the original ASCII standard. The designers recognized that ASCII would be inadequate to meet the needs of everyone and so wisely defined ten "national use" positions that could be changed in each country. There are many so-called national versions of ASCII that exist, typically one for each country. This was the state-of-the-art in the 60's and 70's; when a US vendor exported their product to a "foreign" (non-US) country, vendor personnel in that country translated the messages, screens, and, yes, manuals, into the native language of the country. In fact, ASCII is officially just another national version of ISO-646, the so-called International Reference Version. In practice this is irrelevant. Eventually, vendors discovered they were spending vast sums to translate the software and manuals, were delaying the shipment of new products by months, and were greatly complicating support efforts. In the 1980's vendors turned their efforts to creating software products that would have the same binary image in each country, but would support multiple code pages at a time, and dynamically switch between them. All they would have to translate would be the manuals and error messages. The emergence of computer networking was also a major influence here. ISO 2022 describes a technique for handling multiple code pages for the ASCII class of standards; there is a similar standard for EBCDIC. Anyone who has used MS-DOS since about version 3.0 has seen the extensions that were made to it to support multiple code pages; they are fairly typical. The next effort was to reduce the number of code pages down to a manageable number. ISO has registered 155 code pages as of July 1990! There is considerable complexity just from the sheer number of them. ISO 8859 is a series of 8-bit code pages that have ASCII (real, true, American ASCII without substitutions) in the lower 128 positions and room for 32 new control characters and 96 graphic characters in the upper 128 positions. There are 9 variations of 8859 that I am aware of; the best known is 8859/1, also known as Latin Alphabet No. 1, which covers most of Western Europe. All together the 9 versions of 8859 cover some 40 languages. Asian ideographic languages (Japanese, Korean, Chinese, etc.) have so many symbols that 2 bytes are needed to encode a useful subset of characters. The Taiwanese ISO-compliant standard for Chinese requires two double-byte code pages. Even at 17,672 (2*94**2) positions, this is still a subset of written Chinese, which has over 80,000 characters! Japanese requires both a single-byte code page (Katakana) and a double-byte code page (Kanji). Handling this requires two sizes of characters and shift characters to switch code pages. This has meant a new level of complexity in programming languages, operating systems, and applications. Further, I've only described the ISO-compliant schemes. There are a variety of non-ISO schemes; for Japanese, Chinese, etc. The Stratus VOS operating system presently supports 9 ISO-compliant code pages that cover 17 languages. This covers the primary language of 65 countries that account for half the world's population. Same binary OS image, no confusion of codes, worldwide ability to use any supported character without confusing it with any other supported character. Oh yes, we can translate these code pages to and from EBCDIC. I'm proud of what we did, but I'll be happy if something like Unicode can take its place. It would be nice to go back to simple, fixed-width characters again, without shift bytes. I don't expect it anytime soon, however. Paul Green , Director, System Availability (ex-National Language Project Mgr) Stratus Computer Marlboro, Mass., USA ------------------------------ Date: Sat, 14 Sep 91 16:40:14 GMT From: thorinn@diku.dk (Lars Henrik Mathiesen) Subject: Re: Multinational Character sets (Davies, RISKS-12.30) I just wanted to point out that these extensions are not the manufacturers', but rather nationally standardized (and internationally registered) variants of the ISO 646 set, which explicitly sets code values aside for such variant uses. Formally, ASCII is just the USA version of this, but of course ASCII was the base for 646, and the ``reference'' version of 646 is almost identical to ASCII. The point is, ASCII is _supposed_to_ contain only the characters that are useful in the USA. Of course, ISO 646 doesn't in itself have any facilities for handling more than one language at a time. Later ISO standards do define ways of changing between variants, but none were widely implemented, I think. Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn ------------------------------ Date: Fri, 13 Sep 91 22:58:34 EDT From: Jerry Leichter Subject: Export controls on workstations, or, more mantras (For the sake of simplicity, assume it's two years ago, before all the recent changes in South Africa.) Should US companies sell computers (guns, tear gas -- take your pick) to the South African security agencies? After all, if the US doesn't, that just opens the market for the Japanese, the Taiwanese, the Koreans, or whoever. Once again, the issue of control of exports of high-powered computers has been raised: As reported in a recent RISKS, the US DoD has proposed new regulations on the sale of high-end workstations. The ritual responses have shown up in this forum: Why bother, they'll just buy from the Japanese, or the Taiwanese, or whoever. These ritual responses display, to me, a certain unwillingness to really think about the issue. "Someone else will do it anyway" is an excuse. It's not at all clear that someone else will; and it's a morally bankrupt argument in any case. There are two distinct, though related, issues that need to be resolved before deciding whether export controls on high-powered workstations should be imposed: a) Is it RIGHT that such machines should be kept out of certain foreign hands? b) Is there a PRACTICAL way to implement such controls, should the answer to (a) be yes? I'll contend that hardly anyone will disagree with (a), posed in isolation, though there will certainly be disagreements about exactly which foreign hands should be allowed access. So let's examine (b). First of all, on a moral basis, controls may be justifiable EVEN IF IT'S PRETTY CERTAIN THEY WON'T WORK. Sure, others may do the dirty deed, but that doesn't mean WE should; while we may not be able to stop some evil, at least we should being involved. Should we sell arms to terrorist organizations because, after all, they can always buy them from someone else? Should we sell nuclear materials and technology because, after all, the Chinese seem to be willing to? Every effective embargo has to start with individual decisions that "No, I'm not getting involved in THAT." Is (b) really out of the question? At the moment, the CPU's for high-end workstations are made predominantly by a small number of US companies. An increasing number are made by Japanese chip houses, but under license from US companies. With the exception of the Transputer, all CPU's in wide use today are controlled by US companies. The US could probably require US companies to place appropriate restrictions in their licensing agreements. Should the US move in this direction, the British would probably go along and similarly restrict Transputers. It would take years for another architecture, developed and controlled entirely by non-US interests, to become a significant market force - and, frankly, I don't see that happening as a response to US attempts to control exports. It's just too expensive an undertaking, and the potential market is too limited. By the way, just about all these systems run Unix - also under US control. Those outside of the US may not like it, but as a practical matter the US has a solid lock on leading-edge CPU hardware technology at the present time. That's not likely to change in the next couple of years. What the US chooses to DO with that lock is, of course, another issue. So: The legal and practical bases for controls exist. What kind of controls might be practically applied? Historically, the controls have mainly been of a go/no go sort: Anything above some speed limit could not be exported. The DoD is taking a much more sophisticated approach to things this time around. Among the suggestions mentioned in the newspaper article are software limits on what kind of programs could be run (no details, but it might be things like maximum memory size allowed, I suppose), and verifiable logging of information describing the workload to a WORM device, whose media would have to be returned for inspection on a regular basis. As I recall, conditions of this sort were enforced on CDC machines sold to the Soviets for weather forecasting many years ago. How effective they can be is an open question - but it's one that can only be answered by experimentation. Sure, any controls can be gotten around. Terrorists do manage to get arms. Iraq came quite close to building a nuclear bomb, despite all the controls on nuclear materials. Then again, people get away with robbing banks. Does that mean we should legalize bank robbery? As Shaw put it, we already know what you are, we're just haggling over price. If you agree that, as a matter of morality, computers should not have been sold to South African security forces maintaining apartheid, then the only arguments you can have with the current proposals are (a) that they aim at the wrong people; or (b) that they are too easy to get around. If your real problem is with (b), the right response is to try to find better implementations, not whine about what the Taiwanese may do. -- Jerry ------------------------------ End of RISKS-FORUM Digest 12.33 ************************