Subject: RISKS DIGEST 17.75

RISKS-LIST: Risks-Forum Digest  Friday 16 February 1996  Volume 17 : Issue 75

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

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

----------------------------------------------------------------------

Date: Fri, 16 Feb 1996 10:24:40 -0500
From: Peter Wayner <[email protected]>
Subject: Computer unmasks Anonymous?

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

------------------------------

Date: Thu, 15 Feb 1996 09:27:31 -0500
From: Peter G. Neumann <[email protected]>
Subject: New Intuit software problems

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 IRS 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"
<[email protected]> from Karen Ann Metivier Carreiro
<[email protected]>.  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
    (http://www.intuit.com) for information about the new versions.]

       [NOTE ADDED SUBSEQUENTLY: I mistakenly typed "IRA contributions"
       instead of "IRS contributions".  I fixed it in the archive copy.]

------------------------------

Date: Fri, 16 Feb 96 14:04:39 EST
From: [email protected] (Dorothy Denning)
Subject: ITAR Amended to Allow Personal Use Exemption

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]

------------------------------

Date: Thu, 15 Feb 1996 23:09:25 -0500
From: [email protected] (Dave Hsu)
Subject: User failure or user-interface failure? [extra 0 in bid]

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  <[email protected]>   Systems Programmer   Std disclaimers apply
Software Development Group / UUNET Technologies   http://www.va.pubnix.com

------------------------------

Date: Fri, 16 Feb 1996 13:18:02 -0500 (EST)
From: Educom <[email protected]>
Subject: Spreading the Word (Edupage, 15 February 1996)

*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)

------------------------------

Date: Thu, 15 Feb 1996 21:38:44 -0700
From: [email protected] (Russell Schulz)
Subject: Help! No File-> Save Option on Menu

<someone>@microsoft.com 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!

[email protected]  Shad 86c

------------------------------

Date: Fri, 16 Feb 1996 08:21:10 -0400 (EDT)
From: "Tom Ohlendorf - TSU Admin. DP, (410) 830-3642" <[email protected]>
Subject: CDA interpretation: transmitting vs receiving

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

------------------------------

Date: Thu, 15 Feb 1996 11:16:36 +0000 (GMT)
From: [email protected] (Hugh J.E. Davies)
Subject: Re: Wildcards (D'Oliveiro, RISKS-17.73)

> "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.

------------------------------

Date: Fri, 16 Feb 1996 02:47:56 -0500
From: [email protected]
Subject: Re: Wildcards (Kaplan, RISKS-17.74)

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 * [email protected] * http://pobox.com/~monkeyboy

------------------------------

Date: Fri, 16 Feb 1996 12:15:04 +0000
From: Otto Stolz <[email protected]>
Subject: Re: Wildcards (Kaplan, RISKS-17.74)

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

------------------------------

Date: Fri, 16 Feb 1996 09:16:31 -0600 (CST)
From: Alun Jones <[email protected]>
Subject: Re: Wildcards (RISKS-17.74)

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".

Alun

------------------------------

Date: Fri, 16 Feb 1996 21:19:59 GMT
From: [email protected] (Peter Curran)
Subject: Re: Wildcard inconsistencies in Windows 95 (Kaplan, RISKS-17.74)

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   [email protected]

------------------------------

Date: Thu, 15 Feb 1996 22:15:05 -0500 (EST)
From: Matthew Delaney N2MDB <[email protected]>
Subject: Re: Wildcards (Kaplan, RISKS-17.74)

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    [email protected]   ax.25: n2mdb@k2sk.#eny.ny.usa.na
Finger for PGP key      http://www.j51.com:80/~delaney/

------------------------------

Date: Thu, 15 Feb 1996 19:40:41 -0800
From: Matt Bishop <[email protected]>
Subject: Re: Wildcards (RISKS 17.73, 17.74)

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

------------------------------

Date: Fri, 16 Feb 96 10:12:52 +0100
From: [email protected]
Subject: Re: Wildcards (RISKS-17.73)

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  [email protected]  +33 92.95.62.97, FAX +33 92.95.50.50

------------------------------

Date: Thu, 15 Feb 1996 22:40:26 -0500
From: Doug Shapter <[email protected]>
Subject: Re: Possible future risk of virtual reality (Cohen, RISKS-17.73)

Martin Cohen <[email protected]> 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 [email protected] || [email protected]

------------------------------

Date: 16 Feb 1996 09:46:51 GMT
From: [email protected] (Jan Vorbrueggen)
Subject: Re: Possible future risk of virtual reality (Brady, RISKS-17.74)

 >... 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.

       Jan

------------------------------

Date: Fri, 16 Feb 1996 04:44:38 -0800 (PST)
From: [email protected]
Subject: Re: Possible future risk of virtual reality (Cohen, RISKS-17.73)

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      [email protected]

------------------------------

Date: Fri, 16 Feb 1996 10:25:26 -0500
From: [email protected] (Rob Streno)
Subject: Re: Possible future risk of virtual reality (RISKS-17.73.74)

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.

Rob

(*) 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 http://www.idsoftware.com

------------------------------

Date: 14 February 1996 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED info on RISKS (comp.risks)

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
  INFO     [for further information]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution.  Diversity is welcome, but not personal attacks.  [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form.  Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.  [...]
[Back issues are in the subdirectory corresponding to the volume number.]
  Individual issues can be accessed using a URL of the form
    http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
    ftp://ftp.sri.com/risks

PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
  see the INFO file at RISKS-Request (one-line message INFO noted above).

------------------------------

End of RISKS-FORUM Digest 17.75
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.