_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
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?
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.
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 email@example.com
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
Please report problems with the web pages to the maintainer