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 19 Issue 27

Friday 1 August 1997

Contents

o 45,000 GSM phones recalled for software upgrade
Veliddin Eran Sezgin
o 24 more California DMV clerks fired in fraudulent license scheme
PGN
o Another phony-fax get-out-of-jail scheme
PGN
o Offshore Internet gambling taking *off*
PGN
o Strong Capital sues alleged hacker-spammers
Mich Kabay
o Risks of ordering airline tickets online
Craig Macbride
o What to do about software patents
o Re: AOL customer phone-number availability
Bill Seurer
o Political vs Technical Errors in CA Megan's Law CD ROM
Ed Wright
o Re: The dangers of Explorer-ation
Steve Loughran
o Re: DEC Alpha Bug: Intel x86 FPU Diagnostics
Steven Healey
o Re: DEC Alpha Bug, final resolution
Daniel A. Graifer
David R Brooks
o Re: General Mills, AOL, Chex Quest
Steve Lumos
Doug Linder
Padgett Peterson
o Re: Y2K: a different solution
Robert J. Sandler
Dave Weingart
o CfP: Y2K in Health Informatics Journal
M.F. Smith
o "CyberLaw: The Law of the Internet" by Rosenoer
Rob Slade
o Info on RISKS (comp.risks)

45,000 GSM phones recalled for software upgrade

Veliddin Eran Sezgin <sezgin@tsk.mil.tr>
Sun, 27 Jul 1997 12:00:00 -0700 (PDT)
Recent newspaper ads recalled Ericsson GF-788 GSM phones for a software
upgrade to remediate a software bug.  This particular Ericsson GSM model was
losing base-station signals and shutting itself off in "emergency call"
mode, while other brands work fine.  It should be switched off and on again
to operate.  Consumers' complaints about the GF-788 eventually led the
company to run the ads.

Well over 45,000 units have been sold in Turkey.  Some European countries
(like Austria and Greece) have banned import of that model GSM until the
software is fixed.  (Turkey has over 700,000 GSM customers.)  [Source: The
Turkish daily newspaper, *Hurriyet*]


24 more California DMV clerks fired in fraudulent license scheme

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 1 Aug 97 10:45:10 PDT
The California DMV has fired 24 more clerks who accepted bribes to issue
driver's licenses fraudulently.  This brings the total to 79 in the current
statewide probe, Operation Clean Sweep.  The going rate was $200 to $1000 a
pop for not checking the applicant's identity, typically paid by illegal
aliens, felons needing new identities, and drivers with revoked licenses.
[Source: *San Francisco Chronicle*, 1 Aug 1997, A25]


Another phony-fax get-out-of-jail scheme

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 1 Aug 97 11:18:42 PDT
Richard Foster, jailed for driving with a suspended licence, was set free
from South Carolina's Richland County jail -- based on a fax with an
``official-looking sheriff's letterhead''.  The fax stated that Georgia's
Augusta-Richmond County Sheriff's Office had no interest in Foster.
(Actually, at that time he was wanted on assault and weapons charges.)  The
fax had been sent from a public fax machine at a Kroger grocery store in
Augusta GA, and had the Kroger name and phone number on the fax.  As a
result of this spoof, the jail supervisor has been demoted from captain to
sergeant.  [Source: *San Francisco Chronicle*, 23 Jul 1997, A2]

  [This is a case where you can have your authenticate and eat it too?
  Is this another argument for better authentication?  Well, it certainly
  suggests greater suspicion of faxes.]

Similar cases are recorded in RISKS in March 1997 in Florida (RISKS-18.94),
and in December 1991 in Tucson AZ (RISKS-12.70).  That's THREE (at least).


Offshore Internet gambling taking *off*

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 1 Aug 97 9:56:21 PDT
There are now at least three dozen Internet gambling houses, the latest of
which -- Bet the Net -- begins operating as an Internet casino from Dominica
in the Caribbean in about two weeks.  The expected revenues from all such
Internet operations is estimated at $8 billion by the year 2000, where the
current total take for U.S. casinos is currently $23 billion.  [Source:
Bloomberg News, *San Francisco Chronicle*, 1 Aug 1997, B2.]

The risks include bogus virtual casinos whose payoffs turn out to be more
virtual than real, semi-legitimate casinos working credit-card scams on the
side, glorious opportunities for money laundering, serious gambling debts
accumulated in your name by a masquerader, spawning of serious undetected
addictive behavior that might otherwise be observed (on the Internet no one
knows you are a gambler, except for the casino), your 9-year-old gambling
with your credit card -- especially if your browser automagically inserts
your credit information -- and so on into the night.  As a second-order
effect, massive illegal activities could also lead to attempted restrictions
on the good system security and cryptography necessary to conduct legitimate
Internet commerce.  In any event, whether or not you bet on the Net, don't
bet on the Net being adequately secure!  You are already gambling with the
weaknesses in our computer-communication infrastructures, but NetBet could
raise the ante considerably.  Caveat aleator.


Strong Capital sues alleged hacker-spammers

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Mon, 28 Jul 1997 07:51:05 -0400
[From Associated Press via CompuServe's Executive News Service]

> Strong Capital Sues Alleged Hackers (AP Online, 26 Jul 1997)
> MILWAUKEE (AP) -- An international mutual fund and money management
> company has filed a $125 million federal lawsuit to stop the use of its
> name on e-mail advertisements that include on-line striptease services.

Key points:

* Strong Capital Management, Inc. alleges that David Smith and Glenn Canady
broke into SCM's computers to send 250,000 ads with fraudulent headers
for "cyberstripping," computer equipment and sports betting.

* SCM demands penalties of $5,000 per message -- about $125M in all.

* SCM has added mechanisms to stop further transmission of such messages.

  [Note from MK: The use of civil litigation to attack hackers is one of the
  most powerful tools available to fight them.  This will be an interesting
  and possibly landmark case with implications not only for the growing
  displeasure over fraudulent REPLY-TO addresses but also for penetration in
  general.]

M. E. Kabay (Mich), PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)  http://www.ncsa.com

  [We'll see how it holds up in court.  But beware of bogus FROM:
  addresses, short-lived 800 numbers and P.O. boxes, etc.  PGN]


Risks of ordering airline tickets online

Craig Macbride <craigm@bf.rmit.edu.au>
Wed, 30 Jul 1997 08:25:01 +1000 (EST)
Last Thursday night, 24 Jul 1997, a friend of mine on the east coast of the
US tried using the web server of the Internet Travel Network (www.itn.net)
to book a trip. [For convenience, I'll give all dates/times in US EST.]
The web server, on submission of the information (including billing
address, credit card information, etc), replied with this:

  Data transfer complete          Internet Travel Network - Server Error
  Could You Give Us A Hand?
  _________________________________________________________________________
  One of our server's programs has just experienced an unrecoverable error.
  This is neither normal, nor desirable. We are extremely interested in any
  occurrence of this! Could you please send a note to bugs@itn.net and relay
  the precise conditions that may have sparked this incident? This is a
  special, high-priority mailbox that we will check right away."

The details were e-mailed to bugs@itn.net that was redirected to an
individual's e-mail account. That person was not only not providing
high-priority service to such e-mail, she had an automatic responder in
place which e-mailed back to say she was on vacation, and to try sending
anything important to support@itn.net.

So, e-mail was sent to that account, as well as to the response form on the
web site. On Friday morning, more e-mail was sent, but by Friday midday, ITN
had not responded to any of the e-mail messages that had been sent to them.
One e-mail to them asked when their hours were and when they were likely to
get around to responding one way or another, and this was finally answered
on Friday afternoon, along with a California phone number.

The customer had no idea whether a booking had been made by the web site,
despite the error message from the server. She had no idea whether the
booking had been made by whoever had finally received the bug report e-mail.
She could have booked through someone else and ended up with 2 sets of
non-refundable tickets. She could have left things as they were, and been
forced to pay much more. She was going away for the weekend, so left it.

ITN, when phoned on Monday, claimed that no booking had been made, and had
little excuse for the 6-8 pieces of e-mail they had not responded to.  They
said all they could do was book on another airline, on flights which were
far less convenient.

Imagine our surprise when the originally booked tickets turned up on
Tuesday, 29 Jul, postmarked the previous Saturday. ITN support again tried
to access the booking and again couldn't immediately find it, despite the
tickets having arrived! It appears the booking had been processed by the web
server in the first place, despite the error message!

The risks are almost too many to count here. The risk of getting an error
message when buying something, so submitting it again N times, and actually
getting N+1 tickets. The risk of assuming that an error message means that
an order failed, and going and booking somewhere else, not realising that
the order really did go through. The risk of not knowing what is happening
when the people in such organisations don't bother to answer e-mail in a
timely manner. The risk that an error, if it really does mean that the order
wasn't processed, will result in enormous extra costs once this is
confirmed. In this instance, it was necessary to phone long-distance to get
any sort of meaningful response from the company. (It is possible to contact
them toll-free, as I later found out, but this is not mentioned on their web
site, and was explicitly denied in e-mail!) However, a seat on the same
flights that were booked 5 days ago for US$164 would have cost US$563 to
book today! The person who waited until contacted by the company could find
themselves severely disadvantaged.

There are, of course, plenty of security issues as well, particularly when
sending billing details to an e-mail address, which duplicate details sent
to a web server, and when that e-mail address is being redirected to a
person's account who is currently away from the office.

Craig Macbride <craig@rmit.edu.au>  http://www.bf.rmit.edu.au/~craigm


What to do about software patents

<[Identity withheld by request]>
Thu, 10 Jul 1997 20:03:14 -0400 (EDT)
Seeing the vast numbers of non-novel and obvious software patents issuing in
my area (financial services), a number of unorthodox ideas are crossing my
mind, such as ...

We all know that when a governmental body, such as a city welfare agency,
state prison system, state housing agency, or the like is found to be way
out of line as far as administering and enforcing the laws, one of the more
drastic remedies is to place the deficient agency or department into a court
or legislatively ordered receivership.

Are we reaching the point where we should ask a judge to place the Patent
Office, or the software art areas, under a court-appointed receiver or
administrator, due to its manifest ongoing failure to carry out its official
duties under Federal Law with respect to 35 U.S.C. 101, 102, 103, Rule 56
and so on?

I am starting to think so, but it would be a major political undertaking, to
put it mildly, so I figured I would start this inquiry.  Yes, it would be a
lot of work to document the problem and prepare for court and/or legislative
hearings, etc.


Re: AOL customer phone-number availability (PGN, RISKS-19.26)

<billseurer@VNET.IBM.COM>
Mon, 28 Jul 1997 09:17:11 -0500
|> ...  (But opting out is apparently not easy.)

While I completely disagree with AOL's former intention to "share"
telemarketing information with its "partners", it is *trivial* to opt out of
any of their marketing stuff.  If you go to the marketing preferences area,
you can tailor what marketing information you receive if you want it or
completely opt out.  As far as I know this has been there for quite some
time.  Most people don't bother, of course, but whose fault is that?

Bill Seurer, IBM Rochester, MN, BillSeurer@vnet.ibm.com  BillSeurer AT aol.com
(replace " AT " with "@" to e-mail me)   http://members.aol.com/BillSeurer


Political vs Technical Errors in CA Megan's Law CD ROM (RISKS-19.24)

Ed Wright <emw@teleport.com>
Thu, 24 Jul 97 09:02:00 PDT
While much of the issue here is technical, dealing in part with inaccurate
data, perhaps a more major risk is social.  The Attorney General's office
has been under substantial pressure from Government, caused in part by
substantial public pressure to "do something".  I have the pleasure of
working with some of the tech. folks in that arena, and they are well aware
of data inaccuracies, but have been directed to publish. Period.  The risk
of have politicians mandate poor quality technical activity is obvious as is
the risk of hysteria in a punitive public.  I just want to point out that
the folks in the trenches are not the culprits in this case.


Re: The dangers of Explorer-ation (Barnett, RISKS-19.26)

"Steve Loughran" <steve_loughran@hp.com>
Thu, 31 Jul 1997 20:54:37 +0100
Roger Barnett pointed out that with some new MS products -- the compiler
tools and "Visual Studio 97" presumably -- the user has to install Internet
Explorer with ActiveX, Scripting and Java turned on to get at the
documentation.

There is a simple solution to ensuring that the web browser never access the
net with any "potentially" unsafe features enabled: set it up to point to a
nonexistent or "null" proxy server, so that all non-local web sites are
inaccessible. This technique works pretty well -at least until all
applications expect full web access for dynamic loading of remote code
components and help files.

The implementation of a web proxy that returns "Server Unavailable" to all
requests is left as an exercise for the reader.


Re: DEC Alpha Bug: Intel x86 FPU Diagnostics (March, RISKS-19.25)

Steven Healey <sphealey@worldnet.att.net>
Sun, 27 Jul 1997 09:06:03 -0500
Those who have used Intel FPU's for a while may remember that Intel used to
distribute FPU diagnostics both as marketing material and with FPUs sold as
upgrades (e.g. 8087).  These diagnostics still exist, but Intel no longer
advertises or distributes them.  Poke around on the Intel web site until you
find the FPU technical area, then send an e-mail to the FPU tech support
group asking for a copy.  (Sorry I can't be more specific, but it has been
more than a year since I did this).

Steven Healey  sphealey@worldnet.att.net


Re: DEC Alpha Bug, final resolution (March, RISKS-19.25)

"Daniel A. Graifer" <dgraifer@cais.com>
Mon, 28 Jul 1997 15:38:18 -0400
Many years ago (early 1970s), there was a CDC3600 at the University of
California, San Diego.  At the insistence of the users, a test sequence was
run at the beginning of every work day to validate the floating point unit
in particular.

I was a student employee there, and recall one failure.  It turned out
to be cooling related, and removing the skins from the racks cleared the
problem, driving the CDC technicians crazy for several days...

Daniel A. Graifer, Parker & Company
1-888-426-6548  1-703-425-6091  dgraifer@cais.com


Re: DEC Alpha Bug, final resolution (Chase, RISKS-19.26)

David R Brooks <daveb@iinet.net.au>
Sun, 27 Jul 1997 08:04:50 GMT
Of course, for the PC (and some other machines), you could simply
participate in the Great Internet Mersenne Prime Search (GIMPS)
  http://www.mersenne.org/prime.htm
The Mersenne code runs some (reputedly) real mean FPU tests as it
starts up, and thereafter runs in the background, using surplus
resources to hunt down prime numbers. Any FPU bugs (pre-existent or
arising) are likely to be hooked by this.

Dave Brooks <http://www.iinet.net.au/~daveb>

  [PGN asked: That code might not even use floating point!??]

I checked with George Woltman <74473.2626@CompuServe.COM> (the author): he
replies:

> GIMPS is virtually all floating point.  It is quite superb at finding a
> variety of problems (floating point, heat-related problems, memory
> problems, and even some device driver problems).


Re: General Mills, AOL, Chex Quest (Baker, RISKS-19.26)

STEVE LUMOS <slumos@nevada.edu>
Sun, 27 Jul 1997 20:35:34 -0700
The message from Bruce N. Baker <baker@hooked.net> in RISKS-19.26 is just
another example of what happens when children are allowed free access to
complicated machines like computers without adult supervision.  Had his
grandson not had implicit permission to use the computer, Bruce would have
been able to review the documentation and note that the Chex Quest game
(which is present on the CD-ROM), requires DOS/Windows, while both the
Windows and Mac versions of AOL software are included.  I would imagine that
including AOL on the discs cut duplication costs for Ralston Foods, probably
to zero.

I had no problem installing the game on a Windows 95 machine without
installing AOL software.  The game itself is definitely not related to AOL
in any way.

What I find far more interesting about Chex Quest is that it is in fact a
modified version of Doom (or possibly Quake), yet has an RSAC rating of
"ALL" (suitable for all audiences).  How did they get the rating? By
changing occurrences of "shoot" to "zorch" and "kill" to "return to their
own dimension", and using different graphics.  This leads to odd sounding
constructions like "Many of the Flemoids will need to be zorched a couple of
times before they will return to their own dimension".

The RISK is that violent actions are suddenly non-violent, mainly because
certain terminology has changed.  Is a child used to "slagging demons to
death" really more likely to become violent than one who is used to
"zorching Flemoids until they return to their own dimension"?  It is still
up to the parents to explain the difference between the game and reality.

Steve Lumos <slumos@nevada.edu>

  [A related note from "Harlan Rosenthal" <rosenthh@dialogic.com> notes that
     ``The decision about whether to install AOL is very clearly
     given as an option, and my 12-year-old has been trained not to install
     anything without checking and ESPECIALLY not AOL or MSN.''
  PGN]


Re: General Mills, AOL, Chex Quest (Baker, RISKS-19.26)

Doug Linder <linder@dave.nrl.navy.mil>
Mon, 28 Jul 1997 11:59:18 -0400 (EDT)
Something tells me that this legal language would not be enforceable.  I Am
Not A Lawyer, but I'd say that any reasonable judge would rule that people
can't be expected to read every word on every product they buy, nor can they
be bound by something like that just through the act of buying that product.
After all, if that were the case, why couldn't I put something on my product
that says, in fine print, "By buying this I agree to give Doug Linder all my
money."

This seems to me to be very similar to the "shrink-wrap" licenses on
software which have, in most cases, been found to be unenforceable.  I
believe companies just persist on putting such language on packaging because
they figure it will probably scare people, or at least convince the less
determined folks that they can't sue.

If you're feeling litigious, I'd say go for it and nab 'em for a few bucks
for their irresponsible behaviour.

Doug Linder <linder@dave.nrl.navy.mil> 202 767 2572 (x28), UNIX SysAdmin,
Kaman Sciences @ Naval Research Laboratory, Washington, DC


Re: General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game

"A. Padgett Peterson" <PADGETT@hobbes.orl.mmc.com>
Sun, 27 Jul 1997 10:38:19 -0400 (EDT)
IANAL but suspect a good one could have a field day with this "attractive
nuisance" comes readily to mind as does the case eons ago of the children's
program host who told his viewers to go to daddy's wallet, take out the
money, put it in a envelope, and send it in. (May be legend, suspect true
but why the show/host was not named - is there a legal citation?).

Actually is a much more sweeping question - is a preprinted notice ("by
breaking this seal") adequate to block the sharks?  Suspect it might be
today since is so common as to be expected but for children?  In cereal
boxes?

Just a few years ago there was no concern about children and on-line
services since they did not go together, but today?

Is this really connected to the 809 (and certain other area codes) scams,
where the perpetrator relies on ignorance.  At what point is the "common
knowledge" boundary crossed?  How much "due care" is necessary?

There is always the RISK that amoral people will exploit ignorance.
Computers just make it easier/faster.

Padgett (UDA)


Re: Y2K: a different solution (Driss, RISKS-19.26)

"Robert J. Sandler" <rsandler@compuserve.com>
Sun, 27 Jul 1997 22:48:35 -0400
Driss's solution is not new.  It is already in use for some Y2K projects,
and is much discussed in the Year 2000 Mailing List run by Peter de Jager.
The method is generally called program encapsulation, and it is patented --
U.S. Patent number 5,600,836, assigned to Turn of the Century Solutions,
Inc. of Wayne, PA.  (I have no connection with this company.)  The usual
setback is 28 years, rather than 10, so that leap years remain leap years
and the shifted dates fall on the correct day of the week.

Robert J. Sandler  rsandler@compuserve.com


Re: Y2K: a different solution (Driss, RISKS-19.26)

Dave Weingart <dweingart@chi.com>
Mon, 28 Jul 1997 11:22:50 -0400
Driss (driss@golden.net) mentions a number of concepts as a possible
solution to the Y2K problem in RISKS-19.26 that hold, I think, more severe
risks than the original problem!

I'll summarize briefly, so as not to have to quote too heavily.  I'm sure
Driss will be happy to correct me if I'm missing something here. :)

1)  Take all active records with dates from 1900 to 1910 and put them
    in a separate database.  Archive all inactive ones elsewhere.
2)  Subtract 10 years from the dates in the remaining data.
3)  Add a new program layer to handle the conversion between "real" dates
    and the stored dates, leaving the current i/o interface intact.

There are a number of problems with these assumptions that I see right off
the bat.  First is that most running databases have several date fields;
which ones do you choose to archive off to the "other" set of tables (that
you must still handle)?  Far more serious, however, is the second.  Need I
even point out the inherent Risk in mucking up your data this way?  The
entire *point* of data processing is to deal with large amounts of data as
quickly and **accurately** as possible, and an enormous amount of
programming and checking goes into making sure that that this gets done,
with data validation, dependencies, etc.  In the corporate world, here's
every chance that more than one person will get the task of doing this
setting your data back 20 or more years.  Or the computer will crash halfway
through the operation, leaving you with some unknown chunk of your data with
some fields munged.  Or that some of the fields will be skipped in the
general chaos; it isn't as simple as telling your DBM to type "SUBTRACT 10
YEARS FROM ALL DATES"

Adding another set of programs between your data i/o and your front end
interface adds additional failure points and validation problems, adds time
to the processing (a millisecond here and there may not sound like much,
but add it up over several millions of data records accessing
constantly...), and increases your systems' complexity.  Plus, there's
often no easy way to accomplish this feat; many programs put requests to
the database server; these programs would have to be modified to run to a
different server program (I shudder to think at the concept of replacing
the database server itself; that would then affect any non-date-dependent
programs running!)

In short, too many risks for too little benefit.  Mangling your data doesn't
SOLVE the problem; it only sets it off 10 more years.  (Everyone who
believes corporations will continue tackling Y2K if there's another decade
on the the deadline instead of putting it off AGAIN, raise your hand.
Anyone?  Anyone?)  And it's not entirely clear to me that this would, in
fact be any easier or faster than using field expansion and/or date
windowing as appropriate.

Only 886 more days to go...

Dave Weingart, AccuStaff Inc.  dweingart@chi.com  516-682-1470


CfP: Y2K in Health Informatics Journal

"M.Smith" <M.Smith@qmw.ac.uk>
Sun, 27 Jul 1997 20:47:17 +0100 (BST)
... Healthcare organisations could suffer even more serious consequences
than ordinary commercial enterprises from Year 2000 problems.  Urgent action
is required, yet reliable reports suggest that healthcare organisations have
hardly begun to consider the problem seriously.  Unfortunately, discussions
with healthcare computing and clinical colleagues generally confirm these
reports.  ...  To address this urgent problem, HEALTH INFORMATICS JOURNAL
will be producing a special issue this autumn, entitled Year 2000 and
Healthcare Computing.  This special issue will also be available as a book
from Sheffield Academic Press. ...  [Contact Mike Smith if you are interested.]

M F Smith, Editor, HEALTH INFORMATICS JOURNAL m.smith@qmw.ac.uk
+44 171 582 1409  http://www.shef.ac.uk/uni/projects/hij/


"CyberLaw: The Law of the Internet" by Rosenoer

Rob Slade <roberts@mukluk.hq.decus.ca>
Wed, 30 Jul 1997 10:33:46 EST
BKCYBRLW.RVW   970302

"CyberLaw: The Law of the Internet", Jonathan Rosenoer, 1997, 0-387-94832-5,
U$34.95
%A  Jonathan Rosenoer
%C  175 Fifth Ave., New York, NY   10010
%D  1997
%G  0-387-94832-5
%I  Springer-Verlag
%O  U$34.95 800-777-4643 fax: 201-348-4505 wborden@springer-ny.com
%P  362
%T  "CyberLaw: The Law of the Internet"

Unlike "NetLaw" (cf. BKNETLAW.RVW), which was written for sysops and users,
"CyberLaw" is written for lawyers.  It is liberally supplied with footnote
references to case studies and decisions dealing with the topics discussed.
(Because of this, "CyberLaw", more than any other computer law book I have
reviewed, is pertinent *only* to the United States.)

Unlike "Net Law" (cf. BKNLHLUI.RVW), which looks at legal practice,
"CyberLaw" deals strictly with points of law.  Topics covered include
copyright, trademark, defamation, privacy, duty of care, criminal liability,
procedural issues, electronic contracts, misappropriation of information,
civil rights, tax, and evidence.  (One chapter which does *not* deal with
the law is entitled "Ethics".)  As noted, there are extensive footnote
references to case law, as well as reprints of relevant issues of the
author's "CyberLaw" column.

For those outside the legal profession, the book is reasonably clear on the
major issues.  Its real value, however, would be to lawyers looking for a
quick introduction to US law in respect to information technology.  For this
purpose, it is ideal.

copyright Robert M. Slade, 1997   BKCYBRLW.RVW   970302
roberts@decus.ca           rslade@vcn.bc.ca           rslade@vanisl.decus.ca

Please report problems with the web pages to the maintainer

Top