risks@CSL.SRI.COM (RISKS Forum) (04/09/91)
RISKS-LIST: RISKS-FORUM Digest Monday 8 April 1991 Volume 11 : Issue 41
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Bogus License Upends Life (Tony Lombardi)
RISKS of unreadable mammograms (Espen Andersen)
New Zealand Strides towards Big Brother Society (CLear@caveBBS)
Rapid dissemination of half-truths, lies, and disinformation (J.E. Oberg)
Re: Another computer time/date processing problem (Andy Goldstein)
The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive
"Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For
vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
----------------------------------------------------------------------
Date: 5 Apr 91 18:29:00 EDT
From: 2206ca@gmuvax.gmu.edu
Subject: Bogus License Upends Life
_The Arlington Journal_ [April 5-7 Weekend Edition]. Article by Geoffrey Brown.
Teresa Stover's life turned upside down after a woman walked into the Arlington
County Department of Motor Vehicles office Dec. 14 and, using a fake
identification card, got a duplicate driver's license with Stover's name on it.
The woman promptly got charge accounts in Stover's name, according to
police. Stover now has to convince creditors she isn't the woman who went
on a $30,000 shopping spree.
Stover, 25, who now lives in Philadelphia, said she has spent weeks trying to
clear her name. She charges the DMV gave the woman a license to steal. "As
far as I'm concerned, DMV hung me. They helped her out tremendously." "It's
far too easy to get a driver's license," Stover said. Stover is not the first
to claim that DMV issues licences without properly checking identification.
Her story follows reports from DMV employees across Northern Virginia that
they have given licenses to people with little proof of identification
because managers have told them to bend the rules rather than risk getting
complaints from noisy citizens.
People from as far away as New York and New Jersey have trekked to Northern
Virginia DMV offices to get licenses because it is easier to get a license here
than in other states, according to court documents and reports from state and
federal officials. [...] [The woman] apparently got Stover's Social Security
number and other information from a bank - but how that happened Stover didn't
know. [She] got a copy of Stover's driving record, and got her birthdate and
home address from a DMV employee, Stover was told. [The woman] has brown eyes
and black hair, while Stover is blond and blue-eyed, and that is recorded in a
DMV computer. [...]
The article goes on to discuss in general the problem of fraudulent
driver's licenses:
A 2 and a half year federal investigation of corruption and fraud at the
Baileys Crossroads DMV branch has revealed that perhaps thousands of illegal
aliens have gotten driver's licences from corrupt DMV employees, and that DMV
has done little in 2 and a half years to track the bad licenses.
A law enforcement official said the amounts employees took were small -
as little as $10 for a license. [...]
This is of some concern to me because the DMV branch mentioned in the
article just happens to be the branch that I go to.
There's more than one risk in this story, of course. Here are some
observations:
- The woman apparently had no problem getting personal information
on other people from such institutions as banks and the DMV. (The
article went on to say that she had 11 other Virginia licences - for
different people, including one for a man!)
- The woman obviously had no trouble obtaining credit from other
institutions with nothing but her fraudulent driver's license.
The power of a driver's license cannot be underestimated.
- It's interesting to note the managers weighing risks against each
other - and, of course, choosing the risk that is the least
inconvenient for them (but riskier for society).
- Lastly, I'm not sure what would perturb me more - if the DMV
employee had refused to give the woman the license because of
the discrepancy between her physical appearance and the data
stored in the computer ("But the computer says...") or what really
happened, with the discrepancy obviously being disregarded.
-- Tony Lombardi
------------------------------
Date: Mon, 8 Apr 1991 10:40 EST
From: ESPEN ANDERSEN <EANDERSEN@HBS.HBS.HARVARD.EDU>
Subject: RISKS of unreadable mammograms
The columnist Bella English had a story today (4/8/91) in The Boston Globe
about a woman who was denied health insurance of her breasts, and therefore
went uninsured.
Excerpts:
"Apparently, the problem was that she'd had two mammograms within
six months. It didn't matter that the second one was ordered
because the first one was unreadable. She tried another agent,
who told her that the information would be in a national data
bank, and that she would face the same problem with other insurers."
She had been to other doctors, who had said that there were nothing wrong with
her.
The article goes on to list other examples of a bloated health care system,
"driven by special interest groups of doctors, hospitals and insurance
companies."
The main RISK here, of course, lies in the inability of a human being to
override the "systematic" decision (not necessarily computer programmed):
IF mammograms >= 2 AND time_between_mammograms < .5 year
THEN deny_insurance
ELSE grant_insurance
Or maybe the error lies on the input side: that inconclusive mammograms should
not be included. Or in the choice of the number of mammograms as a decision
parameter.
Note, however, that the "national data bank" does not necessarily constitute a
risk in itself; the main problem is not (as the article seems to imply) that
everybody uses the same data base; it is rather the way information from this
source is used by the individual insurance companies that is a problem. Could
it also be the case that this "national data bank" only gives out certain types
of data - so that the insurance companies have to base their decisions on
"available" data (number of mammograms) instead of the data they should use
(diagnosed cancer), which might not be available?
------------------------------
Date: 6 Apr 91 22:56:28 NZT (Sat)
From: clear@cavebbs.gen.nz
Subject: New Zealand Strides towards Big Brother Society
Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ
Last year rumours were strenuously denied that the New Zealand Inland Revenue
Department (controlling taxation) and the Social Welfare Department
(controlling benefit entitlement and payouts) would link databases to provide
powerful searching and data matching facilities for staff. The government of
the time, Labour, also proposed to introduce a national identity card scheme.
Both schemes were thought to have been abandoned when Labour lost the October
1990 election. Not so. I leave it to readers of RISKS Digest to draw your own
conclusions from the following:
New Zealand Computerworld, 1 April 1991.
Randall Jackson of IDG's Wellington office confirmed this is NOT a hoax.
PM'S TEAM GETS SET TO MOVE ON ID CARDS
by Clive Mathew-Wilson
The Government plans to introduce a National Identity Number scheme for
all New Zealanders by the end of next year, Computerworld sources say.
The numbering system is likely to involve the use of a "smart" ID card.
A team working on the project with the Prime Minister's office has yet
to announce its findings to Parliament, but it is understood it is the
format of the ID scheme, not the scheme itself, that is being debated.
Usually reliable sources within Parliament suggest the ID scheme -
originally proposed by the International Monetary Fund - was already
part of Treasury's economic reform plans before the election, and that
it is being implemented virtually without change by the new Government.
The first stage of implementation - data sharing between the Social
Welfare department and the IRD - is expected to take place shortly.
It is understood that in place of any new common identity numbering
scheme, the issuing and control of IRD numbers will be tightened, and an
IRD number used in all relevant transactions throughout various
government departments.
More than 1.7 million IRD numbers are currently allocated to wage and
salary earners, and recent changes to tax laws require every bank
account to be tagged with an IRD number by 1992.
This would, in effect, give every New Zealander a unique, computerised
serial number.
It is believed the only real problems facing the ID card scheme are
those of computer power.
Doubts have been raised over the ability of existing systems to cope
with the information-handling and storage needs of a National ID Card.
The most likely scenario at present, entails a gradual phasing-in of
both the card and the information-matching based around it, starting
with data-matching between the huge Social Welfare and IRD computer
systems, which operate out of the same GCS [Government Computing Service]
installation at Trentham.
One key target of the ID card is understood to be the public health
system. The computerised "smart" card, with its instant reference to a
person's income details, is to be used to target healthcare as the
public health system is wound down.
If Computerworld's source is correct, a number of politicians and civil
servants appear to have been economical with the truth.
Prime Minister Jim Bolger, while he was in opposition, undertook not to
introduce a common identification number system, despite a confirmation
by the IRD at the time that the IRD number was, in fact, such a system
already.
Similarly, shortly before the elections last year Inland Revenue
Commissioner Dave Henry denied the IRD had plans to link its computer
systems with those of Customs, Births, Deaths and Marriages, Social
Welfare, Housing Corporation and ACC. Shortly after the election, plans
to link the Social Welfare and IRD computers were announced.
The Australian Government, which failed dismally in its plans to launch
a national ID card, is understood to be watching the New Zealand
experiment with interest, pending a possible re-introduction of the
scheme in Australia in a somewhat different form.
Civil liberties spokesperson Barry Wilson attacks what he terms a
"conspiracy of silence" over the issue.
"When has there been any informed public debate over whether New
Zealanders need or want ID cards? The public, by and large, has been
completely ignored," he says.
"New Zealanders voted against the ID card scheme when they dumped
Labour."
Computerworld sought ministerial and IRD response on the issues, but
neither had answered our calls by press time.
------------------------------
Date: Fri, 5 Apr 91 20:22 CST
From: "Jonathan E. Oberg" <PH461A04@VAX1.UMKC.EDU>
Subject: Rapid dissemination of half-truths, lies, and disinformation
The following posting recently appeared in several newsgroups and forums:
>Subject: MODEM TAX
>A new regulation that the FCC is quietly working on will directly
>affect you as the user of a computer and modem. The FCC proposes
>that users of modems should pay extra charges for use of the public
>telephone network which carry their data. In addition, computer
>network services such as Compu Serv, Tymnet, & Telenet would also
>be charged as much as $6.00 per hour per user for use of the public
>telephone network. ...
Almost immediately after its posting, dozens of responses were posted claiming
this was a hoax/fable/etc that was posted on a regular basis to the net.
Having never seen the posting, nor having seen any reports on other media
regarding this, I can not speak to whether it is accurate or not.
However, I am concerned with the way the network:
a) allows for the rapid propagation of inaccurate, misleading
and bogus information
and more especially:
b) the desensitization that the net can inflict.
By the latter I intend the following. Let us suppose that this message was
indeed posted on a regular basis and is known to be false. As soon as it is
posted again, it is immediately flamed down as bogus. Now further suppose that
what the message claims *comes to pass!* How would this information be
disseminated?? Any postings to the net would be shot down, and/or ignored. The
sheer volume of information passing through daily makes scanning information
and discarding junk messages not only prudent by necessary. How many users'
mail programs out there are already customized to scan and ignore messages
containing "modem tax" in the subject line?? Certainly the *users* have become
programmed to do just that.
Knowing this, and presuming that the typical users ar both literate, informed,
and sources of some authority on their local systems, one can easily propose
the situation where a group floods the net with bogus information regarding a
risk (say, a security hole found in ftp protocol) that doesn't exist, and
"re-flooding" the net with a similar posting on a semi-regular basis. When the
net becomes desensitized to that information, that group than exploits the
(formally bogus) information [in our example a security hole in ftp protocol].
Even were it discovered that someone was exploiting this security hole, how
would information of this discovery be communicated?? Would not the
knowledgeable, net-literate at each site be likely to convince those
responsible that this was just another hoax??
This is less a computer/risk as a societal/risk carried on computers, so
apologies to uninterested risk readers.
Jonathan ph461a04@vax1.umkc.edu
------------------------------
Date: Fri, 5 Apr 91 14:40:17 -0800
From: goldstein@enet.src.dec.com (Andy Goldstein - VMS Development)
Subject: Re: Another computer time/date processing problem
You're right in questioning the 366 day uptime value in your VMS SHOW SYSTEM
display (although we know of VMS systems that have stayed up that long!) The
cause of the problem is that SHOW SYSTEM does not compensate for changes made
to the system time since the system was booted. The system time is saved as an
absolute value when the system is booted; uptime is computed simply by
subtracting the boot time from the current time. Thus, the likely cause of your
366 day uptime is having the system time set ahead one year after the system
was booted.
The fact that this happened to you right after the new year suggests you may
have been bit by the foibles of VMS time keeping. (Then again, it may also be
that the system had been booted with the time set back a year and then
corrected right after the boot.) Depending on the circumstances, you are likely
to be prompted for the time the first time you boot after the new year. That's
also a likely time for you to type in last year. (It take me well into February
before I stop writing last year on my checks.)
The attached article, already sent to many customers, explains the foibles of
VMS timekeeping.
=============================================================================
You have run into one of several problems associated with how the time and date
are maintained in VAX/VMS. We must first present some background.
VAX VMS makes use of several clocks, some in hardware and some in software, to
keep track of the date and time. Because none of the available clocks solves
all the problems of time keeping, they must be used in concert and be
maintained in synch by the operating system. Under some circumstances, they
may get out of synch, causing obscure and sometimes incomprehensible problems
with the system date and time.
The "master" clock is maintained as a software construct by VAX VMS. It is a
cell in the exec that contains the current date and time in the VMS quadword
time format. This value represents the time elapsed since 17-Nov-1858 in tenths
of microseconds. With this precision, the 64 bit signed value has a range of
approximately 29,000 years; VMS development has not developed a plan for what
to do when it overflows.
Most VAX cpus provide two hardware clocks from which the VMS master clock is
derived. The interval timer is used to provide an interrupt every 10
milliseconds. At each interrupt, the quadword master clock is incremented by
the value 100,000, and time-dependent scheduling activities are initiated.
A "time of year" clock is build into the console subsystem of most VAX cpus.
This clock is a 32 bit counter that is incremented every 10 milliseconds,
whether the cpu is running or not, and, if battery backup is available, whether
power is on or not. Every time VMS is booted, the software master clock is set
from the time of year (aptly named TOY) clock. This is where the trouble
starts. The 32 bit, 100HZ counter has a capacity of 497 days, and therefore
cannot be used by itself to represent time over an indefinite period. This 5
cent optimization has caused VMS engineering more grief than any other feature
of the VAX architecture.
VMS uses the TOY clock to maintain the date and time relative to the current
year, and stores the current year on the system disk in the system image file
SYS.EXE. This value is updated whenever the system time is recalibrated (when
the system is booted or when any SET TIME command is entered). What is saved in
the system image is the quadword master clock value and the TOY clock value
that corresponds to it in the current year. To recalibrate the time, the TOY
clock is read and a delta is computed from the saved TOY clock value. This
delta is converted into quadword time units and is added to the saved quadword
time to yield the new current master clock value. If the TOY clock is found to
have more than a year of time accumulated on it, one year's worth of time is
subtracted out and the new value is set in the TOY clock. Finally, the new TOY
clock and master clock values are saved in the system image.
VMS adds a bias of 2**28 (31 days) to the time since January 1 to compute the
value maintained in the TOY clock. Thus, should the TOY clock be reset or
overflow, the value read will likely be less than the bias and will be rejected
as an invalid clock value. Also, if the value read from the TOY clock is a day
or more earlier than the saved value, it is rejected as invalid. Because of the
bias, the TOY clock overflows 100 or 101 days after the first of the new year
(depending on whether the previous year was a leap year or not). Thus, provided
the system is rebooted or a SET TIME command is performed some time between
January 1 and April 11 of each year, the TOY clock and system time will be
correctly maintained indefinitely.
Problems arise when more than one copy of VMS is run on the same machine (for
example, one's normal system and stand-alone BACKUP), and when new copies of
the VMS exec are booted for the first time. For example, if two different
copies of VMS are used at different times on the same machine, only one system
will be presented with the opportunity to reset the TOY clock when it is first
booted after January 1. The other system, when subsequently booted, will find
that the TOY clock has a much smaller value than its saved value (from the last
boot), and will reject the time as invalid, causing it to prompt for a new date
and time.
When a new VMS system is distributed, it has assembled into it a quadword time
and saved TOY clock value that represent January 1 of the current year. For
example, VMS V5.3 was completed in October of 1989; therefore its internal time
as distributed is based in 1989. Should a new copy of a system image be booted
in a subsequent year, the TOY clock will be evaluated against the base date
assembled into the system, and it will come up with the date set to
approximately the current day in the year 1989. This will happen, for example,
with the stand-alone BACKUP kit distributed with VMS magtape kits. The problem
with stand-alone BACKUP is particularly bothersome because its system time is
never updated when it is booted (because the disk it is being booted from is
either write-locked or SYS.EXE is no longer present because the first floppy or
TU58 has been removed).
Andy Goldstein, VMS Development
------------------------------
End of RISKS-FORUM Digest 11.41
************************