Subject: RISKS DIGEST 17.11
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest  Thursday 4 May 1995  Volume 17 : Issue 11

  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:
Finnish Executives Jailed for Software Piracy (Edupage)
Cellular phones and Pacemakers: a RISKY Combination (Peter M. Weiss via
   Duane Thompson)
The Road Watches You: 'Smart' highway systems may know too much
   (Simson L. Garfinkel)
Using a car alarm to steal a car (Kevin Purcell)
Final Program for COMPASS '95 (John Rushby)
Safety through Quality Conference, 23-25 Oct, Cape Canaveral, Florida
``Cybercritical'' (Cliff Stoll's new book) (Edupage)
Re: Portable phone interference in hospitals (Derek Hill)
Re: CyberWinter: A Forecast (Arthur A Mcgiven)
Re: "Outrage! of the Month" (Jeff Grigg)
Year 2000?  Don't forget 1752! (Matthew D. Healy)
Re: Floating-point time (Andrew D. Fernandes, Peter Ludemann, Phil Brady)
Re: Radar-detector messages & cop-car computers (F. Barry Mulligan,
   Mark Seecof, Richard Soderberg)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date:   Sun, 30 Apr 1995 20:26:07 -0400
From: [email protected] (Edupage)
Subject: Finnish Executives Jailed for Software Piracy

The two top executives of a Helsinki engineering company have been given
60-day jail sentences and $72,000 fines for knowingly using illegal copies
of AutoCAD computer-aided design software.  The stiff punishment is a
victory for the Business Software Alliance, which says that its member
companies suffered $15.2 billion in global losses last year due to software
piracy.  (Financial Times 4/28/95 p.3) [Edupage, 30 April 1995]

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

Date: Mon, 1 May 1995 19:52:13 -0700 (PDT)
From: Duane Thompson <[email protected]>
Subject: Cellular phones and Pacemakers: a RISKY Combination

When they talk about a "heart stopping" telephone call, this must be what
they mean.

Date:    Mon, 1 May 95 11:15 EDT
>From:    "Peter M. Weiss +1 814 863 1843" <[email protected]>

BUT DO YOU STILL HAVE TIME TO CALL 911? [abstracted]

The Wireless Technology Group says studies show that in some cases cellular
phones placed near the chest can cause pacemakers to recalibrate themselves
or stop and restart.  The advisory group warns that new digital pocket
phones are of particular concern -- especially since their numbers are
likely to proliferate once personal communications services are widespread.
No such effects from the older analog cellular phones have been observed.  A
spokesman for Medtronic, a pacemaker supplier, says the company is advising
patients with pacemakers to turn off their portable phones when the phone is
in a shirt pocket, to hold the phone 10 to 12 inches from the chest when
using it, and to hold the phone to the ear opposite the side where the
pacemaker's implanted.  (*Wall Street Journal*, 28 Apr 1995, p. B1)

 [It is a very old problem.  The first pacemaker death due to interference
 was recorded in the Risks annals in 1980 (in Software Engineering Notes,
 before the on-line Risks Forum was established).  PGN]

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

Date: Wed, 3 May 1995 15:37:38 -0400
From: [email protected] (Simson L. Garfinkel)
Subject: The Road Watches You: 'Smart' highway systems may know too much

[This is slightly longer version of my article that appeared
in the March 3 1995 issue of The New York Times.]

The Road Watches You: 'Smart' highway systems may know too much
(C) 1995, Simson L. Garfinkel

Highway authorities throughout the country are building futuristic "smart
road" systems designed to unclog our highways and bridges, improve driver
safety, and create a variety of new services for our nation's motorists.
But these smart roads could lead to an Orwellian surveillance state if we
do not act now to change their course.

One smart road system is already in operation on New York's Tappan Zee
Bridge. Called E-ZPass, the system allows drivers to drive through the toll
plaza without reaching for their wallets or rolling down their windows.
Instead, a computer operated by the Thruway Authority reads an electronic
tag mounted inside the car's windshield, and automatically deducts the toll
from a special pre-established account.

Other systems are going up around the country. In Florida, the
Orlando-Orange County Expressway Authority has a system called E-PASS which
lets drivers pay their tolls on the East-West Expressway and certain parts
of the Central Florida GreeneWay. Instead of a windshield tag, E-PASS uses
a radio transponder the size of a flashlight mounted under the car's front
bumper. A similar system is being planned for the San Francisco Bay Area.

These automatic toll collection systems are just the beginning of a
nationwide plan called Intelligent Transportation Systems, or ITS. Rather
than have each city adopt its own tag or transponder, the Department of
Transportation and ITS America, a Washington-based organization that
promotes the system, are scrambling to create a single, national standard.

As envisioned, smart roads could further reduce highway congestion by
alerting drivers to upcoming accidents; a computer display mounted on the
dashboard could suggest alternative routes. With its planned two-way
communication between the car and the intelligent road, ITS could even
eliminate the search of a place to park. Instead, your car's computer could
automatically locate the nearest lot with an opening and electronically
reserve you a place.

But there is a dark side to this plan, a privacy problem that its boosters
are trying to pave under. These systems offer unprecedented opportunities
to monitor the movements of drivers. It would create a bank of personal
information that government and private industry might have difficulty
resisting.

Consider Florida's E-PASS system. Each month, every E-PASS subscriber gets
a detailed statement listing the exact time, date and location that each
toll was collected.  ITS America has adopted a set of privacy principles
which say that states shouldn't take advantage of this dat, yet the
organization  specifically envisions that "states may legislate conditions
under which ITS information will be made available."

Phil Agre, who teaches communications at the University of California, San
Diego, and closely follows privacy issues, warns that there might be other
unintended consequences of the widespread use of ITS systems.  Auto
insurance companies already offer discounts to driver who don't live in
areas of high auto theft or accidents; in the future, says Agree, they
might offer discounts to drivers who can prove that they haven't driven
onto "the wrong side of the tracks."

The data could also be sold illegally by insiders. Information about a
person's movements might be a key fact in forcing an out-of-court
settlement in a divorce or worker's compensation case. Private
investigators would have a big incentive to bribe low-paid clerical workers
for a photocopy of somebody's toll-crossing bill.

There is an alternative to this system. Instead of transmitting an account
number, a radio would transmit "digital cash" using a smart card inside the
car  similar to the telephone cards used in many European countries. But
judging by plans under way so far, state agencies and the Government
haven't shown much interest in making privacy a priority in the design of
the tomorrow's intelligent highways.

Americans have always loved the freedom that their cars give them. Could
that too become a thing of the past?

Simson Garfinkel is a Cambridge-based writer who covers privacy issues. His
fourth book, PGP: Pretty Good Privacy, was published by O'Reilly in January.

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

Date: Mon, 1 May 1995 16:43:26 -0700
From: [email protected] (Kevin Purcell)
Subject: Using a car alarm to steal a car

We had a car stolen from our company's parking garage recently. The car had
a car alarm which appears to have aided the car thief.

The thief wandered around our building (a separate risk) until he found an
a set of keys in an empty cubicle. The cubicle occupant had left the cube
for a few moments. The thief the keys and then wandered down to our five
level parking garage.

We presume he walked down the spiral pressing the button on the car alarm
transmitter on the key chain. When he came into range of the car it
chirped, giving away its location and he deactivated the alarm. He then
stole the car.

Personally I hate audible car alarms and prefer to mechanically immobilise
a car. Another argument in my favor!

Kevin Purcell // [email protected] // [email protected]

 PGN: This risk showed up in a tv program this week.

Interesting! I didn't figure it was original nor did I talk about how to
combat the problem which amount separating the alarm controller from the
keychain with the attendant risk of them becoming separated or lost or have
a silent alarm (indicate alarm state by a flashing LED rather than beeping
or flashing the headlamps). The latter is probably a better solution. The
best solution is to immobilise the car mechanically.

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

Date: Mon 1 May 95 10:40:22-PDT
From: John Rushby <[email protected]>
Subject: Final Program for COMPASS '95

                          COMPASS '95
         Tenth Annual Conference On Computer Assurance
   Systems Integrity, Software Safety, and Process Security

                       June 26-30, 1995
        National Institute of Standards and Technology
                       Gaithersburg, MD

                         Sponsored by:
        IEEE Aerospace and Electronics Systems Society
              IEEE National Capital Area Council
         In Cooperation with: British Computer Society

COMPASS covers several topics of interest to RISKS readers including
safety-critical systems, testing, formal methods, safety kernels, security,
standards, and processes.

The technical program features 22 papers on these topics, plus a panel
discussion on "Safety and Security Issues in Developing and Operating
Intelligent Transportation Systems."

The keynote speaker is Robert Veeder, Tax Payer Privacy Advocate of the IRS
on "Privacy Risks to Computer Systems."  The banquet speaker is none other
than Peter Neumann, illustrious moderator of this newsgroup.

There's also a tools fair (the WWW page has latest details of the tools to
be shown).

The conference is preceded by two days of tutorials on the following topics
 "The Practical Application of Formal Methods to High Integrity  Systems"
 "Security Engineering Capability Maturity Model"
 "Safety Analysis in the Mil STD 498 Project Environment"
 "Metrics for Risk Assessment, Software Quality, and Process Improvement"
 "Real-Time Rule-Based Systems: Analysis & Optimization"

You can get the program and other details as follows.
1.  Via WWW from http://www.csl.sri.com/compass95.html
2.  Via FTP from ftp://ftp.csl.sri.com/pub/compass95-brochure.txt
3.  Email [email protected] if all else fails

The location is the National Institute of Standards and Technology,
Gaithersburg, MD, which is one of the northern suburbs of Washington DC.

  [Many thanks to John for having taken the time to post what I consider
  to be an ideal conference announcement, short, to the point, justifiably
  relevant to RISKS readers, and containing information on how to get the
  REST OF THE STORY.  Most often I have to edit down the full conference
  info; I get many complaints if I run the whole thing.  Cheers!  PGN]

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

Date: Mon, 1 May 1995 10:59:48 -0400 (EDT)
From: [email protected]
Subject: Safety through Quality Conference, 23-25 Oct, Cape Canaveral, Florida

Abstract deadline:  15 May 95

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

Date:   Sun, 30 Apr 1995 20:26:07 -0400
From: [email protected] (Edupage)
Subject: ``Cybercritical'' (Cliff Stoll's new book)

A new book ("Silicon Snake Oil") by Clifford Stoll, the scientist and
computer security expert who once tracked down an international spy ring
using the Internet, documents his disdain for most of what goes on in
cyberspace.  "The information highway is being sold to us as delivering
information, but what it's really delivering is data... Unlike data,
information has utility, timeliness, accuracy, a pedigree."  He says that
what's missing in cyberspace is "anyone who will say, hey, this is no
good...  Editors serve as barometers of quality, and most of an editor's
time is spent saying no."  (New York Times 4/30/95 E7) [Edupage, 30 April 1995]

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

Date: 3 May 1995 16:57:28 GMT
From: Derek Hill <[email protected]>
Subject: Re: Portable phone interference in hospitals

Following the posting quoting the Nottingham Recorder article about an
incident at the Bassetlaw General Hospital, in which 100s of patients died,
I contacted the Medical Devices Agency to check the truth of the story.  It
was the first time I'd tried to contact the MDA by email, and I got a reply
- by fax :-(

 Thank you for your enquiry concerning the Nottingham Recorder.
 There is no truth in the newspaper's allegation regarding an
 incident at the Bassetlaw General Hospital.

Mr J Lefever also confirmed that the Safety Action Bulletin, which I have
posted here in the past, is the most recent advice on the subject of mobile
phones in hospitals.

So, as far as I understand, there are anecdotal stories of mobile phones
interfering with medical equipment, but these incidents have not been fatal.
The current advice is that the use of mobile phones, two-way radios etc.
should be discouraged in the vicinity of sensitive monitoring equipment.

Derek

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

Date: Tue, 02 May 95 14:23:19 GMT
From: [email protected] (Arthur A Mcgiven)
Subject: Re: CyberWinter: A Forecast (Moore, RISKS-17.10)

It seems clear to me that much of the anti-free-internet propaganda comes
from journalists, politicians, etc who are technologically illiterate - one
only has to analyse what they say to see that.  Clearly such people don't
surf the internet, so someone is feeding them with stories, knowing full
well what reaction to expect. That could be someone with an interest in
converting the internet into a controlled and / or profitable enterprise.
There are similar attacks here on the BBC and no doubt in the USA on the PBS
from similar quarters.

Arthur A Mcgiven  [email protected]  Compuserve 100315,3453

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

Date: Wed, 3 May 95 15:10:04 CDT
From: [email protected] (Jeff Grigg)
Subject: Re: "Outrage! of the Month" by National Taxpayers Union Foundation

> In "Capital IDEAS" (Vol. 3, No. 6, April 1995) ... [conversion to
> correctly handle the year 2000] is expected to take SSA seven years.

Interesting.  The way I figure it, 1995 + 7 years = 2002.
I think I see a problem here.

 [Yeah, Jeff!  I was wondering if anyone would pick up on that one.  PGN]

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

Date: Mon, 01 May 1995 16:04:09 -0500
From: [email protected] (Matthew D. Healy)
Subject: Year 2000? Don't forget 1752!

 [I deleted a comment about accounting software that plans 5 years in
 the future already being at risk.  We've done that one before...  PGN]

I recently saw a posting in comp.databases.sybase about another problem.
The date/time functions of Sybase won't accept dates before 1753 because
most of the English-speaking world changed over to the Gregorian calendar in
1752, and they wanted to avoid all the OldStyle vs NewStyle problems with
earlier dates.  Well, this guy was in charge of alumni records at an
institution that was founded before 1725; for their oldest records they've
had to roll their own date/time functions.

[email protected]  Postdoc, Genetics & Medical Informatics

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

Date: Tue, 2 May 1995 19:49:51 -0400
From: "Andrew D. Fernandes" <[email protected]>
Subject: Re: Floating-point time

It seems to me that the real issue as to whether or not floating point
representations are appropriate for timestamps is not "can I get microsecond
resolution?" but "is it going to work unconditionally?"

Floating point numbers bedevil numerical programmers for several reasons; we
need to know the radix, number of mantissa and exponent digits, behaviour of
rounding, etc. to guarantee "good" results---there is a reason that
textbooks have been written about numerical analysis. Modern computers
generally stick to the IEEE-754 standard for floating point arithmetic, and
thus code is usually fairly interchangeable, but anyone who has ever done
intensive number crunching on old IBMs, VAXen, or CRAYs can tell horror
stories about interchanging floating point programs between systems. Even
going between a SPARCstation and my '486 at home, I can see a few digits
change. "Unconditional portability" is ludicrous under these conditions.

A 64 bit integer can represent 1.84e19 values, which implies about 2
nanosecond resolution of a thousand year interval. Integer math is very
portable across computer systems, or at least is very easy to describe
fully, and 1 + 1 always evaluates as 2, and not 2.0001.

-Andrew D. Fernandes ([email protected])

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

Date: Thu, 4 May 95 11:42 PDT
From: [email protected] (Peter Ludemann)
Subject: Re: Floating-point time

In my original note I mentioned something really simple: handling clock
ticks.  Not handling time, which is a topic for PhD theses (Stanford is
about to grant a PhD for a thesis on temporal representation in databases).

My problem was simple: I needed to do 48-bit arithmetic on a machine which
had 32-bit integers.  I had been given an assembler routine which did the
48-bit arithmetic wrong; and I was fortunate to test it in December when its
accumulated error was about 3 minutes in converting clock ticks to a date
(in January, it had almost no error).

So, what to do?  Obviously, writing 48-bit arithmetic in assembler was
error-prone and tedious.  Doing it in PL/I (this was before C was generally
available) wasn't much more fun nor less error-prone (anyone who has read
the PL/I manual's description of handling overflow and precisions will agree
that it's not a pretty sight; and I later learned that the PL/I implementors
had got it wrong anyway).  And I didn't have access to LISP's
rational-number packages.

In a flash of inspiration, I realized that double-precision floating
point, with 53-bit mantissas, would handle my 48-bit integers with no
round-off errors.  Converting between 48-bit integers and floating
point is simple (it's a "well-known assembler idiom" that takes about
3 instructions).  And everything would then proceed perfectly (even a
Pentium can get floating-point addition and subtraction right).

At one stroke I had removed a few pages of difficult assembler and
replaced them by a few lines of PL/I.  Less code, less chance of error.

[Inspired by this, I wrote a disk accounting package that eschewed
packed decimal arithmetic and instead used floating point (of
course, I calculated everything in cents because 1.01 doesn't
represent exactly but 101 does.  Another success.)]

One of my jobs as a programmer is to reduce the risk of error in my system.
I can only test so much.  Testing 48-bit integer arithmetic is not fun, at
least for me; and proving the code right is difficult (Knuth allegedly wrote
"Beware of bugs in the above code; I have only proved it correct, not tried
it.").  PL/I's implementation of 15-digit packed decimal was buggy.  And I
wasn't being paid by the number of lines of code (au contraire: if I
finished early, I took time off).

The lessons for RISKS: before you try to do something complicated, maybe
there's something simple and reliable lying around that you can pervert
slightly into the form you want.  [My original RISKS lesson was to be sure
to test time/date conversion routines at many times of the year; if they
work in January, they might not work in December.]

- Peter Ludemann

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

Date: Tue, 2 May 1995 18:26:06 GMT0BST
From: Phil Brady <[email protected]>
Subject: Re: Floating-point time

 [Your moderator is dismayed that this is dragging on so long! PGN]

Agreed - the debate has been interesting, but hasn't it run it's course yet?

The fact is that every programmer needs to decide whether to use floating,
decimal, integer, string, etc and the appropriate precision for every
variable in every program depending on the application.  If they don't know
the appropriate form for time for the problem in hand, then they aren't
programmers!

Phil Brady,  University of Wales, Swansea    01792 295160

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

Date: Sun, 30 Apr 1995 23:08:03 -0500 (CDT)
From: "F. Barry Mulligan" <[email protected]>
Subject: Re: Radar-detector messages & cop-car computers (Seecof, RISKS17.10)

>... microwave transmitters designed to set off speed-radar detectors.

It's interesting to note a recent thread in rec.radio.scanner, where a
number of posters recounted with glee their use of low-power microwave
emitters to trigger radar detectors. The uniform response by drivers was to
hit the brakes. Equipping an ambulance with such a device should ensure that
the first vehicle on the scene of a rear-end collision will be equipped for
the emergency.

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

Date: Thu, 27 Apr 1995 19:22:22 -0700
From: Mark Seecof <[email protected]>
Subject: Radar-detector messages & cop-car computers

At page 91 of the April 1995 Law and Order magazine (v.43 no.4) in the
"Police Equipment News" section a short item describes a "Collision
avoidance system" that "takes advantage of the millions of radar detectors
in civilian use."  Basically, the system requires police cruisers and other
emergency vehicles (e.g., ambulance) to be equipped with microwave
transmitters designed to set off speed-radar detectors.  Drivers will
presumably react to radar-detector alerts by looking around, improving the
chance that they messages from the alerting signal.  Cobra's present CAS
transmitters can be programmed to send either "Emergency Vehicle" (moving
vehicle) or "Road Hazard" (vehicle stopped on highway) and the scheme allows
for other messages.

Michael Hoffberg  [email protected]  [email protected]

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

Date: Thu, 4 May 1995 13:46:39 +0100 (NFT)
From: richard soderberg <[email protected]>
Subject: Radar-detector messages & cop-car computers

Having done some emergency medicine in ambulances, I cannot refrain from the
following reflection.  What does the average (slightly speeding) motorist do
when s(he) realizes that someone is aiming a radar beam at the car? Easy,
they will slam the brakes!  This is precisely what I would *not* want to
happen a few cars up front if I was trying to negotiate a tricky traffic
situation at high speed, instead, I'd like people give way in a controlled
manner.  /RS

Richard Soderberg, MD, The Karolinska Institute, Libr. and Med. Info. Center,
Doktorsringen 21 C, S-104 01 Stockholm SWEDEN  +46 8 728 80 00

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

Date: 24 March 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (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.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

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

End of RISKS-FORUM Digest 17.11
************************

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.