Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The U.S. Justice Dept.'s Web site < http://www.usdoj.gov/ > took on a quite different look after crackers broke in this weekend and altered the page to include swastikas, obscene pictures and criticism of the Communications Decency Act. The site was shut down following the discovery Saturday morning; the department expects to reconstruct the page and have it running again by Monday, if not before. (*St. Petersburg Times*, 18 Aug 1996, A12)
The FBI pulled out of an investigation concerning glued switches discovered in a backup control room at FPL's Hutchinson Island (near Ft Pierce, Florida) nuclear facility, so reports the AP in an item carried in 16 August's _Florida Today_. A security alert was issued Wednesday when glue was discovered in three locked switches in the backup control room, a facility used in case the primary control room is unusable. An FBI spokesman is quoted as justifying pulling out of the investigation because the FBI lacked "jurisdiction...it really came down to an act of vandalism or tampering." The piece fails to mention the plant features that would have been affected by the glued switches. Investigation is reportedly focused on employees. The article implies a link between the vandalism and complaints about a November round of job cuts at the facility.
My company recently got ripped off by a competitor. We build Websites and thus had constructed a site detailing our products and services. A rival Website constructor (!) copied practically the entire site, changing the background color, changing our name into theirs, and making other slight changes like alignment, add and delete a word or phrase here and there... I complained about it, not only to them directly, but also on a local USENET newsgroup (we're both located in Belgium, so the newsgroup was be.providers). On the phone they just laughed at me and admitted to copying, but on USENET they claimed I had copied their site! There's nothing I can do to prove them wrong, even though we both know what happened. The risk: if you put your materials on the Internet, where they can be freely copied, make sure you have some way to prove you made them yourself, and when you did it. Roy Dictus, NET bvba, Internet Projects & Consulting roy@net.be http://www.net.be [Interdictus becomes Enter Dictus. PGN]
My sister in Israel recently joined the Internet. She had a certain amount of trouble getting her PC configured correctly to hook to the service provider, in part because (I'm told) the name of the semicolon in Hebrew is (translated) "period comma". So when she was told over the phone to put in a "period comma" in a configuration file, she did that (.,) rather than the required semicolon (;). Needless to say, the software didn't find the two interchangeable. I think the risk is that we computer-types assume that everyone will understand the ambiguous meaning of terms. The fact that this happened to be in another language just makes the point a bit clearer.
When my father was nine, his Uncle Will, who was fond of practical jokes, gave him a magnetic compass--and said "Why don't you take it apart and see how it works?" Technical education rests on intuitive understanding gained through unsupervised, unstructured exploration in childhood. Before I went to MIT, I was crushing vacuum tubes in vises, and connecting automobile spark coils to a big antenna to see whether my friend with the shortwave radio could pick up the resulting RFI. [...] Thirty years ago, a lot of our technology was accessible to direct exploration. You could "take it apart to see how it works." You could see the grooves in a phonograph record, put it under a microscope and see the wiggles, and experiment by putting fingernails or sharp objects into the grooves. You could smash a vacuum tube and see the little grid wire inside it. You could overload a vacuum tube and see the anode get red hot. (My real learning took place in the basement, not the science fair). What is the effect on our society as more and more of our technology vanishes inside the chip? The behavior of engineered objects depends less and less on physical and mechanical relationships, and more and more on arbitrary behavior designed into firmware. I fear that the engineers of the future will lack a certain kind of gut intuition that comes from direct tactile contact with "the works." We know what is being gained, but are we sure we know what is being lost? Daniel P. B. Smith dpbsmith@world.std.com
As did many organizations, the National Institutes of Health received several bomb threats on Monday, July 29, in the wake of the bombing in Atlanta, GA. Several buildings were evacuated and searched but no bombs were found. While the NIH campus is extensively networked, the use of e-mail as a general nofication mechanism was found to be wanting: [excerpted from a memo from the NIH Director] "In addition to notification of all staff through usual administrative channels, an attempt was made soon after the threats were received to utilize our e-mail system to inform all NIH staff of the threats. The delivery of this notification was delayed in many cases because an equipment failure over the weekend created a backlog of messages on Monday morning and because our current list-serv system was unable to deliver 24,000 messages in a timely fashion." This incident serves to underline the oft-stated (and oft-ignored) risk in relying on systems that were (a) not designed to do the job required of them and (b) never subjected to realistic testing to see if they *could* do it anyway. Ramon L. Tate, Ph.D., National Institutes of Health, Bldg.14A, Rm. A116 Bethesda, MD 20892-5515 rt3e@nih.gov
[The following transcript of the Olympic 911 bomb call and the ensuing
conversation suggests that many of our nontechnological risks are not
being adequately addressed. PGN]
http://www.cnn.com/US/9608/09/olympics.bomb.911/911.transcript.wir/transcript.html
Excerpts from a transcript released Thursday by the Atlanta Police
Department regarding the bomb threat telephoned to 911 on July 27. Times
have been converted from military time to standard notation, and punctuation
and spelling have been edited. Parenthetical notes are part of the police
transcript except where labeled as an editor's note.
The transcript refers to these police terms: Code 73, bomb threat; and
Zone 5, a police precinct near Centennial Olympic Park.
The transcript did not explain the Zone 5 dispatcher's references to Code
17 and Code 8, which apparently were unrelated to the bomb call.
12:58:28 a.m.: [Call to 911]
12:58:32 a.m.: Atlanta Police Department 911 Operator: "Atlanta 911."
Caller: "There is a bomb in Centennial Park, you have 30 minutes."
12:58:45 a.m.: Caller hangs up.
1:01:20 a.m.: 911 operator calls APD Agency Command Center (all lines busy).
....
1:01:30 a.m.: 911 operator calls Zone 5 and notifies Zone 5 of Signal 73 and
requests address of Centennial Park — unable to get street
address.
Dispatcher: "Zone 5."
911 Operator: "You know the address to Centennial Olympic Park?"
Dispatcher: "Girl, don't ask me to lie to you."
911 Operator: "I tried to call ACC but ain't nobody answering the phone ...
but I just got this man called talking about there's a
bomb set to go off in 30 minutes in Centennial Park."
Dispatcher: "Oh Lord, child. One minute, one minute. I copy Code 17. OK,
all DUI units are Code 8 and will not be able to
assist on the freeway.
Oh Lord, child. Uh, OK, wait a minute, Centennial
Park, you put it in and it won't go in?"
911 Operator: "No, unless I'm spelling Centennial wrong. How are we spelling
Centennial?"
Dispatcher: "C-E-N-T-E-N-N-I — how do you spell Centennial?"
911 Operator: "I'm spelling it right, it ain't taking."
Dispatcher: "Yeah."
911 Operator: "Centennial Park is not going. Maybe if I take 'park' out,
maybe that will take. Let me try that."
Dispatcher: "Wait a minute, that's the regular Olympic Stadium right?"
911 Operator: "Olympic Stadium is like Zone 3, though. Centennial Park."
Dispatcher: "That's the Centennial Park?"
911 Operator: "It's near the Coca Cola Plaza, I think."
Dispatcher: "In 5?"
911 Operator: "Uh huh."
Dispatcher: "Uh, hold on. Sonya, you don't know the address to the
Centennial Park?"
2nd Dispatcher (in background): "Downtown."
911 Operator: "Male, about 30."
Dispatcher: "1546, Code 17, 23."
911 Operator: "White."
Dispatcher: "Uh, you know what? Ask one of the supervisors."
911 Operator: "No, Lord help me, you know they don't know."
Dispatcher: "I know, but it gets it off you."
911 Operator: "Alrighty then, bye."
Dispatcher: "Bye."
1:02:40 a.m.: 911 operator calls APD ACC for address (telephone line problem;
operators cannot hear each other.) ...
1:02:50 a.m.: 911 operator calls APD ACC again and requests address for
Centennial Park and is given the telephone number.
ACC: "Atlanta Police, Agency Command Center."
911 Operator: "Hey, can you hear me now?"
ACC: "Uh huh."
911 Operator: "OK, can you give me the address of the Centennial Park?"
ACC: "I ain't got no address to Centennial Park, what y'all
think I am?"
911 Operator: "Can you help me find the address to Centennial Park?"
ACC: "I can give you the telephone number of Centennial Park."
911 Operator: "I need to get this bomb threat over there to y'all."
ACC: "Well."
911 Operator: "But I need the address of Centennial Park. It's not taking,
the system is not taking Centennial Park, that's not
where it came from, but you know the system is not
taking Centennial Park, that's where he said the bomb was."
ACC: "No particular street or what?"
911 Operator: "He just said there's a bomb set to go off in 30 minutes in
Centennial Park."
ACC: "Ooh, it's going to be gone off by the time we find the
address."
911 Operator: "Are you kiddin'? Give me that, give me that."
ACC: "I mean I don't have an address, I just have phone
numbers."
911 Operator: "Give me the phone number."
...
1:05:10 a.m.: 911 operator calls Centennial Park for street address and
is placed on hold. Receives address at 1:07:10 a.m.
Centennial Park: "Centennial Park, this is Operator Morgan."
911 Operator: "Hi, can you give me the address to Centennial Park?"
Cen Park: "The address?"
911 Operator: "Uh huh."
Cen Park: "Uh, hold on a second."
1:06:30 a.m.: 911 operator notifies Communications Supervisor, Sgt.
Montgomery.
911 Operator: "Does anybody — Sgt. Montgomery, do you know the address of
Centennial Park? Do you know the address to Centennial Park.
Well, I need to get the address of Centennial Park 'cause, I
mean I don't mean to upset nobody, but we got a bomb threat
over there."
(Editor's note: The transcript does not further indicate whether this
comment about a bomb threat was directed only to Sgt. Montgomery in the
911 center or to Centennial Park's Operator Morgan, who is shown to come
back on the line just after the comment.)
Cen Park: "Ma'am."
911 Operator: "Yes."
Cen Park: "OK, it's 145 International Boulevard."
911 Operator: "145 International Boulevard."
Cen Park: "Uh huh."
911 Operator: "OK."
Cen Park: "All right, uh huh."
911 Operator: "Thank you. Bye bye."
1:08:35 a.m.: 911 operator sent call to dispatch.
1:11:10 a.m.:
Dispatcher: "1591. Radio raising 1594."
Unit 1594: "1594. You call?"
1:11:20 a.m.:
Dispatcher: "1594, that's affirmative, got a Signal 73 at 145
International Boulevard. It came from the pay phone at
the Days Inn. The caller is advising that he has one set
to go off in 30 minutes at Centennial Park. Sounded like
a white male."
(Editor's note: The same information is then given to Unit 1593 and the
dispatcher calls Unit1546.)
1:12:30 a.m.:
Dispatcher: "Did you copy?"
1:12:40 a.m.:
Unit 1546: "1546. I copy. Advise the state police, they police that park.
I'll go the Days Inn and see if I can locate the caller."
Dispatcher: "OK, that's affirmative."
(Editor's note: There are sporadic entries over the next seven minutes.
Another officer, designated Unit 1593, also instructs the dispatcher at
1:18:50 a.m. to "contact the state police supervisor." The transcript
contains no indication, however, that state police were notified.)
1:20:00 a.m.:
Unit 2924: "2924 to Radio, be advised that something just blew up at
Olympic Park."
Lowell Gilbert wrote in RISKS 18.34: > The metaphor of hardware design ... is so weak as to be downright disingenuous. A better metaphor might be crime. It is hard for a detective to predict accurately how long it will take to find out who committed a crime. It is equally hard to prevent future crimes. And we've been trying to solve those problems for much longer than we have been debugging software. - Bill E
Bruce Sterling provides a very interesting summary of how the telephone companies take care of software upgrades to switching systems in his book _The Hacker Crackdown_. The basic process is this: start with all of the switching stations with the old software. Outfit one station with the new software. Watch it run for a while and see what happens. If it's broken, only a few (!) people will be out of phone power. When it seems like it's working OK, add another station. When that one seems like it's working, add another station. And so on until all of the switches are outfitted with the new software. The legendary Crash of 1990 happened when AT&T had approximately 75% of stations outfitted with new software, and the bug that caused the crash could only cause a crash when a critical mass of stations had the new software (and the new bug). R. Spainhower rs@world.std.com
The recent discussion of seamless upgrades, and the idea that telephone switches might never have been "booted" to begin with (having been seamlessly upgraded over the years from their original mechanical incarnations) reminded me of a similar situation. This was when I worked for a large mainframe manufacturer (the adjective applies to both the company and their products) in the mid-1980s. I was working with the folks who wrote the operating systems for these mainframes, and we had roughly half a dozen machines used by various software development projects (OS, compilers, databases, tools, etc.). Many of these machines were running early beta test versions of the operating system. These machines could either be "cold booted", where a fresh operating system image was loaded from tape to disk and various data structures on the disk re-initialized, or "warm booted", where the current operating system image was used, with the data structures as they were when the machine was stopped. Patches could be (and frequently were) applied to the operating system image on disk, followed by a warm boot. It turned out that no one was cold-booting the machines, because it took too much time and effort. It was discovered that some machines hadn't been cold-booted for many months! Typically, in that time, dozens of patches had been installed, some of which might affect the cold-boot process. Management announced that all machines would henceforth be cold-booted weekly, to verify that they still could be. The risk of a system that almost never needs to be taken down is that when it does need to be taken down, it might be hard to bring it back up! Or, practice makes perfect? Jeremy Leader Tujunga, CA, USA jleader@alumni.caltech.edu <http://www.alumni.caltech.edu/~jleader/>
1. Upgrading a program is usually pretty easy — the hard part is upgrading
the database it operates on. It's amazing that 'program development
environments' spend all this effort on the program portion, and virtually
none on the database portion. Common Lisp Object System (CLOS) is one of
the few systems that actually provides a smooth 'upgrade' mechanism in which
multiple versions of objects can simultaneously coexist, along with a 'lazy
upgrade' ability — older objects can be automatically upgraded 'on sight'.
2. Without rehashing all of the arguments for/against N-version again, I
just want to point out a few key ones against. There are occasions where
_any_ decision is better than _no_ decision — e.g., which side of an
obstacle to detour around; it usually doesn't matter, but you are guaranteed
to crash if you don't choose one. Apparently, at least one crash (or
near-crash) of an experimental, statically-unstable NASA airplane occurred
when two different systems proposed two different answers, and the
supervisor system concluded that both subsystems must have malfunctioned,
thus causing the big red light on the pilot's console to come on ("total
computer system malfunction") (heresay from a conference lunch
conversation). Another problem from the multiple language N-version efforts
(C/Fortran/Ada): a _good_ answer from — e.g. — the Ada implementation can
be outvoted by a _bad_ answer from — e.g. — the C and Fortran
implementations.
Henry Baker ftp.netcom.com:/pub/hb/hbaker/home.html
Several people have made the point that you can't classify bugs in advance of fixing them and therefore can't make much in the way of useful predictions of how long it will take to fix them. This is quite true (although some very vague generalizations can be made.) It would be more interesting, however, to measure the time it takes to fix bugs in particular programs. Some programs are better designed than others. Some of the time this translates into some programs being more debuggable than others. (And sometimes it doesn't.) There are thousands of other factors involved, but I suspect most of them are reasonably uniform for the lifetime of a single project at a single company. Thus you might be able to make some vague predictions for the time it takes for the average bug in a specific program (well, code base, probably) to be fixed. Admittedly this is not especially useful for telephone companies and the like, but it might work for an operating systems vendor. Or for customers choosing software, if vendors could be convinced to disclose the data. One would have to get some actual data to see if any statistically useful conclusions can be drawn. David A. Holland dholland@hcs.harvard.edu
Last spring, I asked readers of RISKS for suggestions on alternatives to Social Security numbers in organizations with large data bases of information about individuals. Many such organizations find they do not need to use SSNs, and avoid privacy problems associated with using them. For a copy of all of the responses, send a request to us and specify whether you want hard copy or electronic edition of our August issue, and provide postal address or e-mail address. Robert Ellis Smith, Publisher, Privacy Journal newsletter, Providence, RI, 401/274-7861, e-mail 5101719@mcimail.com. Excerpts from the suggestions follow: * FROM WASHINGTON, D.C.: Maryland uses Soundex (of name and birth date concatenated [linked in a chain]) both for driver and vehicle registrations. * FROM CAMBRIDGE, MASS.: "Against Universal Health-Care Identifiers" in the JOURNAL OF THE AMERICAN MEDICAL INFORMATICS ASSOCIATION 1:316-319, 1994, by Dr. Peter Szolovits of MIT and Dr. Isaac Kohane of Children's Hospital in Boston, discusses a number of ways in which cryptography- based health care identifiers can be used to preserve privacy while remaining manageable for typical medical purposes. This is publication #49 (in Postscript format) at http://medg.lcs.mit.edu/people/psz/publications.html. * FROM YARDLEY, PA.: One way is to use a simple scheme like three letters from last name, the first initial, and some digits; another is just to use sequential numbers. Another is an MD5 hash of the full-name string [a one-way mathematical function as a stand-in for the name that makes translation back to the original name impossible]. This is always unique for a unique string, so you might need to add some numbers. * FROM MADISON, WISC.: When I was working on the development of the Wisconsin Student Data Handbook - we tried to develop what we called an "SSN surrogate," also of nine bytes per individual. It involved an algorithm which combined year, month, and date of birth with sex and two consonants each extracted from the first and middle names. * FROM CYBERSPACE: I worked with a banking software company that set up employee records simply by exact hire date and time. Since they never hired anyone at exactly the same time, it gave each person a unique number. You could do the same for any data base in which records are added gradually one at a time - just number them based on exact date and time added. * FROM PALO ALTO, CAL.: At Stanford University we made a decision long ago not to use SSN for identification except where required by law (payroll taxes, for example). We use a unique Stanford University ID (SUID), which is a lifetime number and applies to all students, alumni, faculty, staff, and patients. It serves all the same purposes that the SSN would do if it were used.
Johnsrude writes:
> This lack of protection distinguishes American law from most European
> democracies. "Data protection" is an important part of European human
> rights law.
A very important point. In Germany, this was actually derived, in the
context of a census, from the constitutional right to freedom from injury by
the Bundesverfassungsgericht (sort-of-analogue of the US Supreme Court). The
laws that were made in response to this decision actually strive to handle
the problem at the correct point, IMO, namely when the data in question is
created. And there is a distributed system of "watch dogs" whose annual
reports are widely discussed (if not always read).
However, I think the bulk of Johnsrude's contribution and the further
discussion in this thread misses a major point. The DMV database is quite
different from, say, VISA's or your favourite retailer's, in that the DMV
occupies a monopoly, and a publicly mandated one at that. If you don't like
the data handling procedures of whoever offers you a service, in general
there will be a competitor who might have better practices regarding your
objections. Or you can make a purchase explicitly contingent on data
concerning it not being made available to others, and in the case of
infraction sue for breach of contract (of course, this entails other barrels
of worms, but that's a separate discussion). In the case of the DMV, there
is no alternative, because the DMV itself, as an issuer of drivers'
licenses, serves a public watchdog function, and the service it offers is
not in any practical sense optional, especially in wide parts of the United
States. Putting severe restrictions on the DMV's use of the data entrusted
to it is sensible, for any number of reasons; the technical problems in
distributing data to those that need to know (e.g., police officers) come up
in other situations as well and have well known solutions.
One of the root problems here is that, IMHO, the way legislative
responsibility has been divided in the USA is just crazy. The (I assume)
federally mandated inclusion of the SSN in state controlled DMV records,
without any clauses on how to protect this data, is a case in point; I
suppose this was foisted on the states in a similar way the drunk driving
rules were (according to urban legend, by making federal subsidies for the
interstates contingent on such legislation). Thus, responsibility is divided
- in a similar way later noted as being the result of the privatization of
the British rail network.
Jan
Not to hammer this point, but if DMV records are going to be readily and speedily available to law enforcement agencies at the lowest level, e.g., deputy sheriffs and dispatchers in the smallest communities, as seems necessary to me for rational police work, then as a practical matter these records are not secure at all, at least not to any intruder with a modicum of intelligence.. The RISK of thinking that DMV records are secure when in fact they're not then seems worse to me than the benefits, if any, of thinking they are secure.
Please report problems with the web pages to the maintainer