The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 75

Friday 16 February 1996


o Computer unmasks Anonymous?
Peter Wayner
o ITAR Amended to Allow Personal Use Exemption
Dorothy Denning
o New Intuit software problems
o User failure or user-interface failure? [extra 0 in bid]
Dave Hsu
o Spreading the Word
o Help! No File-> Save Option on Menu
Russell Schulz
o Re: CDA interpretation: transmitting vs receiving
Tom Ohlendorf
o Re: Wildcards
Hugh J.E. Davies
Wei-Yuen Tan
Otto Stolz
Alun Jones
Peter Curran
Matthew Delaney
Matt Bishop
Pete Kaiser
o Re: Possible future risk of virtual reality
Doug Shapter
Jan Vorbrueggen
David Wood
Rob Streno
o Info on RISKS (comp.risks)

Computer unmasks Anonymous?

Peter Wayner <>
Fri, 16 Feb 1996 10:24:40 -0500

The 16 Feb 1996 edition of the *Baltimore Sun* announces that a computer program similar to one used to attribute unknown poems to William Shakespeare has been turned to solving the mystery of who wrote the best-selling book, *Primary Colors*. The work was apparently done by Donald Foster a professor at Vassar College who discovered that both Joe Klein and the author of *Primary Colors* used these adjectives quite often:

especially, entirely, fiercely, incredibly, mortally, particularly, precisely, profoundly, reflexively, relentlessly, seriously, subtly, surprisingly, ultimately, utterly, vaguely, wistfully

More information will be published in an article slated to run in the copy of *New York* magazine that goes on sale on Monday. This article seems to be the major source for the *Sun* piece.

If Joe Klein, a well-known political writer, is indeed the author, it is clear that he didn't learn one of the first lessons of Washington. If you're going to leak information or quotes to the world, make sure you use the diction of your enemy. That's ventriloquism Washington style.

-Peter Wayner

New Intuit software problems

Peter G. Neumann <>
Thu, 15 Feb 1996 09:27:31 -0500

Intuit Inc. has for the second year in a row delivered buggy versions of its tax-preparation software, TurboTax and MacInTax -- which can give wrong entries in cases involving depreciation of cars and real estate, self-employed taxpayers, and IRA contributions (expected to affect at most 1 percent of their users -- 20,000 out of about 2 million). Intuit is offering free updates of the software, and help in workarounds for the old software. Intuit also offered to pay any resulting penalties and interest charges. [PGN Abstracting. Source: Intuit Finds Errors In Its Tax Software, AP item, *San Francisco Chronicle*, 15 Feb 1996. A similar AP item, Errors Pop Up, Again, In Tax-Preparation Software, *The Boston Globe*, 14 Feb 1996 was forwarded to RISKS by "Lance J. Hoffman"
<> from Karen Ann Metivier Carreiro <>. PGN]

[This must be a tough business to be in, with Congress not even establishing the rules until late in the game. Check Intuit's website ( for information about the new versions.]

ITAR Amended to Allow Personal Use Exemption

Dorothy Denning <>
Fri, 16 Feb 96 14:04:39 EST

Today's Federal Register contains a notice from the Department of State, Bureau of Political Military Affairs, announcing final rule of an amendment to the International Traffic in Arms Regulation (ITAR) allowing U.S. persons to temporarily export cryptographic products for personal use without the need for an export license. The product must not be intended for copying, demonstration, marketing, sale, re-export, or transfer of ownership or control. It must remain in the possession of the exporting person, which includes being locked in a hotel room or safe. While in transit, it must be with the person's accompanying baggage. Exports to certain countries are prohibited -- currently Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria. The exporter must maintain records of each temporary export for five years. See Federal Register, Vol. 61, No. 33, Friday, February 16, 1996, Public Notice 2294, pp. 6111-6113.

Dorothy Denning
[This will probably become known as the Matt Blaze exemption. See Matt's ``My life as an international arms courier" in RISKS-16.73, 6 January 1995. PGN]

User failure or user-interface failure? [extra 0 in bid]

Dave Hsu <>
Thu, 15 Feb 1996 23:09:25 -0500

This item appeared in *The Washington Post* two weeks ago; since I haven't seen any mention of it here, I thought I'd send it along.

Wireless Bidder's Inadvertent Zero Could Cost It Millions

...during still ongoing bidding for wireless telephone licenses at the Federal Communications Commission in the District, a Puerto Rican company, PCS 2000 L.P., mistakenly placed a bid totally $180 million for a small market that includes Norfolk and Newport News, Va. The bidder meant to tap $18 million into the computerized bidding form, but "it is obvious that an extra zero was somehow accidentally added to the end of the bid amount," PCS 2000 official said in a letter to the FCC. ...The FCC imposes tough penalties on those who withdraw bids, to guard against bidders running up the price of a license and then pulling out. Typically, bidders who withdraw must pay the difference between their aborted bid and the amount of money that the license actually sells for. ...What baffles FCC officials is that PCS 2000 didn't catch the error. The computerized bidding system gives contestants three opportunities to confirm their bid, followed by a final chance to get a paper printout. PCS 2000 blamed time pressure: It has been among the most active bidders for the licenses, competing in more than 48 markets in each round. Such typos have occurred three times before, amid the thousands of bids processed by the FCC since it began auctions in late 1994. The largest error was by a company called Atlanta Trunking, which recently bid $225 million, instead of $225,000, for a radio dispatch license.

The reference to "three opportunities to confirm their bid" leaves open the question of whether the operator is asked to reenter the number or if it's merely displayed for visual checks several times. The chief of the FCC's auctions division also notes that training seminars and walk-throughs of the process were conducted for the bidders. As of the article's writing, neither firm had been penalized yet, pending consideration of their appeals.

The reporter did not attempt to address the possibility of a breakdown in the bidder's own communications system between any decision-making authority and the agent who actually enters the bid.

Dave Hsu <> Systems Programmer Std disclaimers apply Software Development Group / UUNET Technologies

Spreading the Word (Edupage, 15 February 1996)

Educom <>
Fri, 16 Feb 1996 13:18:02 -0500 (EST)

*The Washington Post* has reported that a Maryland family received a number
of threatening calls after a University of Maryland student used the Internet to circulate a hearsay allegation that a daughter in the family was being mistreated by her mother. Posting his message on Internet newsgroups concerned with child welfare, psychology, left-wing politics, and civil liberties, the student urged people to call the mother "at home and tell her you are disgusted and you demand that she stops." The student claims: "You should be able to write what you want on the Internet, whether it's true or not." (*Houston Chronicle*, 14 Feb 1996, 2A)

Help! No File-> Save Option on Menu

Russell Schulz <Russell_Schulz@locutus.ofB.ORG>
Thu, 15 Feb 1996 21:38:44 -0700

<someone> writes [source not included]:

<> I have a Word 6.0a and there is no File->Save option on the menu.

> It would appear that the menu item has been deleted. It's easy enough
> to add back, just follow these steps: [...]
> What likely happened is that you accidentally hit Ctrl+Alt+Minus (-)
> and then you selected Save from the File menu. The Ctrl+Alt+Minus is
> the keyboard shortcut for the ToolsCustomizeRemoveMenuShortcut command,
> which will remove the very next menu item selected if invoked.

That's amazing -- hitting an easy-to-mistake key combination (considering what you have to hit for non-breaking hyphen and other common non-ASCII codes) puts you in a mode where the next item you select disappears (and apparently without confirmation)!

I don't think even vi is this modal!

Russell_Schulz@locutus.ofB.ORG Shad 86c

CDA interpretation: transmitting vs receiving

410 <"Tom Ohlendorf - TSU Admin. DP,>
Fri, 16 Feb 1996 08:21:10 -0400 (EDT)

The main provision in the CDA is the prohibition of individuals from "TRANSMITTING" offensive material to other people. In chat rooms it is true that you transmit material; in other words, you type something and it is transmitted to all of the computers logged into that chat room; however, when material is placed on WEB pages, nothing is transmitted, somebody has to physically search for it and view or download it. This is receiving, not transmitting.

I know this is semantics at this point; but, just because you have an adult bookstore or video store down the street from you doesn't mean you have to go in.

There are utilities that prevent access from URLs with adult content. There are also smart youth out there that can break these with out their (computer illiterate, for the most part) parents knowing. The utilities to prevent access to adult URLs are getting better; however, parents still have to monitor their children's activities on the WEB.

Preface the last paragraph with the fact that I don't have any children (yet). When my wife and I do have a child and it is old enough to start surfing, the surfing will be in an ocean liner and not a boogie board; I will have to control over the URLs open to my child until my child reaches the age in which he/she is allowed to enter an adult store.

The risks of all of this is obvious to me:

  1. Allowing the CDA to go through eliminates some rights. When one right goes, more follow.
  2. Being computer illiterate allows your children to see material that may be explicit.
  3. Not having a spell checker for VAX E-Mail means that there are probably spelling errors in this.
Tom Ohlendorf

Re: Wildcards (D'Oliveiro, RISKS-17.73)

Hugh J.E. Davies <>
Thu, 15 Feb 1996 11:16:36 +0000 (GMT)

> "DIR XX?" will show only the second file, but "DEL XX?" will delete both

This is presumably because DEL and DIR do their own filename globbing, rather than relying on a system function to do it for them. I find this highly entertaining, since one of the planks of the Unix-Haters argument has always been that having the shell do globbing (i.e. all the globbing is in one place) is Evil and Wrong.

Hugh J.E. Davies, AVP Unix Support, Republic National Bank, 30 Monument Street, London.

Re: Wildcards (Kaplan, RISKS-17.74)

Fri, 16 Feb 1996 02:47:56 -0500

As George Kaplan correctly points out, console programs are responsible for carrying out wildcard expansion (i.e. not the shell). However, if memory serves correctly, convention dictates that Windoze programmers use wildcard expansion library routines that behave in a standardized manner. Unless you enjoy reinventing the wheel and have written your own wildcard expansion routines, every console program should expand wildcards in exactly the same way. Therefore something must be *seriously* screwed up if "dir" and "del" aren't behaving as expected. Brain dead OS coding (what else is new?).

Wei-Yuen Tan * *

Re: Wildcards (Kaplan, RISKS-17.74)

Otto Stolz <>
Fri, 16 Feb 1996 12:15:04 +0000

Exactly this Unix feature has produced a new variant of the wildcard inconsistency: as a program does only see the expanded parameter list, it does not know whether a wildcard string was involved (and if so, which one). Hence, depending on the options specified, the Unix ls command (the equivalent of the DOS dir command) lists more files than the rm command (the Unix equivalent for the DOS del command) would remove on account of the same wild- card string. Example: ls -lg x* would not only list all files in the current directory whose names start with an "x", but also all files in any directory whose name starts with an "x".

Sure enough, this is quite better than listing less files than would be deleted, but I still find it disturbing.

In VM/CMS, the program gets the wildcard string, and it can use a central routine (LISTFILE) to expand this string. I think, this is the best solution.

Otto Stolz

Re: Wildcards (RISKS-17.74)

Alun Jones <>
Fri, 16 Feb 1996 09:16:31 -0600 (CST)

George Kaplan comments that the Unix shell handles wildcard expansion, whereas DOS and Windows programs receive their parameters as typed into the command line, and are left up to their own measures to expand them.

While this is true, there is a standard method for expanding wildcards - the "findfirstfile/findnextfile" functions. (Under DOS and Win16, _dos_find_first and _dos_find_next; under Win32, FindFirstFile and
FindNextFile). Where these commands are used, a uniform expansion of wildcards can be achieved.

There are two reasons that I can see for using a different behaviour, each with their own attendant risks:

  1. A lack of education about the appropriate commands, leading people to make their own solutions from more basic functions. Lack of appropriate knowledge usually leads to late delivery dates, slow and bloated software, and often more mistakes - the more code you have to write yourself, the more chances you have of making a mistake.
  2. A decision to change the interface 'for the better'. As noted below, the wildcard expansion has changed in some ways that might be beneficial - it seems this only applies to some commands, though. The risk here - people are used to the original interface, and make assumptions based on that knowledge. One of the hardest tasks for a Win3.1 user upgrading to Win95 is to forget many things they learned under Windows 3.1. Frequently this "knowledge" hampers their use of the new features of Win95.
Mr Kaplan might be intrigued, for instance, to note that in a DOS window under Win95, he can place an asterisk in the wildcard _before_ other characters, for example "DIR *MEMORY.H", which will list "VMEMORY.H" and other similar names.

In previous DOS versions, the presence of an asterisk was converted inside the BIOS to a series of question marks, as in my example, which would effectively become "DIR ????????.H" - obviously, for this to work as intended, a question mark must match an absent character in the file name, hence the behaviour noted in the original article where "DEL XX?" deletes both "XXX" AND "XX". Note that this expansion of the asterisk continues for eight characters - old DOS files are stored with eight characters of name, and three of extension.

The conundrum presents itself under Windows 95 with the dual nature of a filename. Each filename has a short and long version - when referencing the long version of the filename, it would be infeasible to represent an asterisk as a series of question marks to the point between the name and extension, since that position is no longer fixed - the name AND the extension may be arbitrary length; indeed, it is only by a stated convention that the extension is the last sequence of non-period characters following a period (if no period, there is no extension). So, the question mark is no longer forced to have one interpretation.

Experimentation shows that the DIR command seems to be the odd-man-out in Win95, since "EDIT XX?" pulls both files into the editor, for example. In the particular example given, "DIR XX?." (note the period) will list both files. Also, the assumption that the DIR command will list all files that would be deleted by the DEL command, when given similar parameters, can be proven wrong - simply try a file "XXX.TXT", and type "DIR XXX", followed by "DEL XXX" - the directory listing will show the file, whereas the delete will complain "File not found".


Re: Wildcard inconsistencies in Windows 95 (Kaplan, RISKS-17.74)

Peter Curran <>
Fri, 16 Feb 1996 21:19:59 GMT

This difference between MS-DOS and UNIX is a cause of frequent complaint from UNIX users. However, there are technical differences between the two solutions-The UNIX approach requires the ability to pass extremely long command lines to the invoked commands, whereas MS-DOS is limited (for good reason initially, given the hardware limitations) to about 128 bytes.

The first version of UNIX I used (circa 1975) limited command lines to about 51-bytes -- that made the UNIX approach almost useless, because so many
useful expansions required command lines longer than this. It was soon expanded to about 5120 bytes - much better, but still not sufficient on occasion.

There is also a significant effect on the user interface. In MS-DOS, a command like "copy A*.* B*.*" has the effect of copying a bunch of files, renaming them all consistently. A command like this is not possible in UNIX, without requiring awkward escapes, etc., because the invoked program never sees the original form of the parameters, to make the appropriate substitutions in file names. Whether one likes this or not is a matter of taste, but I think a good argument can be made that the capability is useful.

I am generally hard-pressed to find good words about MS-DOS, but I don't think it is completely evil :-) (I don't know if there is a RISK here, except perhaps to note again that problems can be trickier than they first appear.)

Peter Curran

Re: Wildcards (Kaplan, RISKS-17.74)

Matthew Delaney N2MDB <>
Thu, 15 Feb 1996 22:15:05 -0500 (EST)

The recent discussion in RISKS about wildcard expansion lead me to think of another security risk in Unix wildcard expansion. If I were to do a "sz *.zip", someone doing a "ps -aux" on my system would see the list of files
expanded. This could lead to some misunderstandings over what someone was downloading (how often have you had the wrong impression from a filename?).

As well, on a similar topic, my pppd (runs my Linux PPP connections) normally gets the logon and password passed on the command line, causing it to be displayed on a "ps -aux". I realized this, and after doing some researching, discovered I could pass the p/w from a file instead (which could be 400 root-owned).

Matthew Delaney N2MDB ax.25: Finger for PGP key

Re: Wildcards (RISKS 17.73, 17.74)

Matt Bishop <>
Thu, 15 Feb 1996 19:40:41 -0800

TOPS-20 (do I date myself?) was halfway between the UNIX and the Windows '95 approach -- it had a JSYS (system call) that would do the expansion, if my memory serves me correctly. So the program determined if wildcard expansion occurred, and if so, all programs would expand the wildcard in the same way, by issuing the appropriate system call.

I last used TOPS-20 in 1979, so my memory of the exact JSYS used is really shaky. It was a very nice system ...

Matt Bishop, UC Davis

Re: Wildcards (RISKS-17.73)

Fri, 16 Feb 96 10:12:52 +0100

The commonest VMS command shell, DCL, doesn't expand wildcards either, but VMS provides runtimes for that, and virtually all programs use these. This also applies to command procedures, since the runtimes are accessible at the shell level. The result is that wildcarding is very consistent under VMS, even though wildcards aren't expanded by the shell.

I gather this isn't the situation under DOS. Imagine my surprise.

Pete +33, FAX +33

Re: Possible future risk of virtual reality (Cohen, RISKS-17.73)

Doug Shapter <>
Thu, 15 Feb 1996 22:40:26 -0500

Martin Cohen <> wrote about the risk of virtual reality video games in which participants transfer skills, however anti-social, learned in their favorite games to real-world activities.

A variant on the risk is already apparent. I used to work on Navy research projects and one of our sponsors was actively seeking proposals for research on "trainer sickness." It seems that pilots experience numerous ailments during and after training sessions.

I've heard of, but cannot confirm, the following:

  1. A trainers for 2 crew jets (e.g. F14), in which the visual inputs are geared to the pilot. The pilot can spend a few hours in the trainer. The same visual inputs are askew for the flight officers/navigators, who last only a few minutes before becoming violently ill.
  2. Pilots who, after an intense training session, experience the illusion/hallucination of accelerated climbing while driving their cars.
  3. Pilots who have "trainer flashbacks" and become ill years after their active training ceased.
As I said, I cannot confirm these stories, but heard of them while working on other, unrelated research. Perhaps someone closer to the issue could comment.
Doug Shapter ||

Re: Possible future risk of virtual reality (Brady, RISKS-17.74)

Jan Vorbrueggen <>
16 Feb 1996 09:46:51 GMT

>... military aviators were not allowed to operate real aircraft for some > interval after using a VR simulator.

But for a totally different reason. Simulators have become, on the one hand, very similar to reality in the visual domain, but have obvious limitations when it comes to simulating movement. (If you integrate all the accelerations your simulated plane seems to be doing, you end up traveling the distance the plane would be doing if it were actually flying, which is a tad bothersome for a stationary simulator...) Thus, that part of your inner ear that measures acceleration is only briefly stimulated by the start of a movement in the simulator; the rest is done visually, which works because the visual system, having acquired extensive real-world experience, is capable of generating the same sensations as real accelerations (ever seen the IMAX versions of those nice JPL-produced Venus and Mars flyovers?). However, your neural system is capable of learning, and quickly at that: In a flight simulator, and especially a military one where manoeuvers are much more extreme than for a civilian craft, the pilot learns within an hour to associate visual movement with only very little input from the inner ear. When he next happens to accelerate in the real world (and it reportedly has happened just quickly walking down a stair after the simulator session) his system revolts 8-) because of the cognitive dissonance caused by conflicting actual input and experience. Not a good idea at Mach 0.8 and 50 meters above the tree tops... Fortunately, one un-learns (or, rather re-learns) within a day or two.


Re: Possible future risk of virtual reality (Cohen, RISKS-17.73)

Fri, 16 Feb 1996 04:44:38 -0800 (PST)

It struck me after reading the article that 'Realistic virtuality' may be a better term than 'virtual reality'.

I think the risks as listed by Cohen are obvious, but is not so obvious is the perception that 'virtual reality' is in some way linked to 'reality'. It gives the illusion of being 'real' in that it is realistic but it is only virtual and the virtual world is at the whim of the creator of that world.

Virtual world creators take note.

David Wood

Re: Possible future risk of virtual reality (RISKS-17.73.74)

Rob Streno <>
Fri, 16 Feb 1996 10:25:26 -0500

Having grown up in the 80's and still being a somewhat avid video gamer, I can attest to both the advantages and risks of habits gained in VR-like situations. It is common for me to drive 30 miles to my home after an intense hour long multi-player DESCENT(*) session, during which, my nerves are *still* on alert from the game. At these times, I am more alert and aware of my surroundings, however, my Jeep doesn't have the ability to fire homing missiles and take off vertically at mach-3.

I think the overall result, though, is that after being in VR-like (or traditional video game) situations, the individual winds up with better motion-perception ability. I think this sticks while the learned reactions (fire the homing missiles, Gunner!) are left in the fantasy world.

(*) DESCENT for those of you who do not know is a single or multi-player 3-D shoot-em-up, where you pilot a spacecraft within the shafts of deep-space mines. You have a plethora of weaponry available to you, and-- in multi-player mode-- it gives you the opportunity to blast your co-workers to space dust. More information can be found at

Please report problems with the web pages to the maintainer