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 Supreme Court is divided over a case involving false arrest due to erroneous computer data, attributed to human error. Ruth Bader Ginsburg was quoted thusly: ``As automation increasingly invades modern life, the potential for Orwellian mischief grows.'' Antonin Scalia countered that nothing is gained by excluding evidence of true wrongdoing because some subordinate did not purge outdated information from a computer system. The case arose after Isaac Evans was stopped in 1991 in Phoenix for a minor traffic violation; he was arrested because of a hit identifying an outstanding warrant --- although though that warrant had been previously ``quashed'' and should have been removed from the database. Furthermore, the arresting officer then detected the presence of marijuana. The Court is reviewing whether, under the circumstances, that evidence can be used in a trial for drug possession in light of the false arrest. [Source: A Washington Post item appearing in the San Francisco Chronicle, 8 Dec 1994]
Act 4 of Shakespeare's 'Julius Caesar' opens with Mark Antony, Octavius,
and Lepidus meeting to work out the proscription that is to follow
Caesar's murder. To be proscribed means that you are rubbed out and
your property confiscated by the people doing the proscribing. Clearly,
proscription is a significant data processing problem since both the
rubbing out and the division of spoils have to be worked out to the
satisfaction of the proscribers.
In a recent production of Julius Caesar by the Folger Shakespeare Theater in
Washington, D.C., there was only a modest amount of tittering when one of
the proscribers arrived on stage to do the necessary work with a laptop.
Bob Morris
[I presume the character was ProScribe rather than ProLaTeX?
Was Folger in his Cups? or Caps?
(Sorry. That multipun is only for OLD Washington logicians.) PGN]
[Marc Rotenberg added, out of band, i.e., not in RISKS-16.63 as mailed:
If Caesar lived until proscribed at the Folger,
he was obviously good to the last drop.]
I got the following from ba.broadcast today and felt it was worth sharing here.... The following is an INEXACT quote from KCBS, one of our all-news radio stations: ...the police have called the bomb squad to defuse the hand grenades. Until the grenades are defused, the police have prohibited the use of 2-way radios in the vicinity of the scene here, so we are reporting by cellular phone instead of radio. Somebody needs to tell the folks at KCBS the meaning of "radio." Somebody also needs to give the police a clue. --Lynn
There are a lot of people over in the comp.infosystems.www.* newsgroups who are seriously talking about using the World Wide Web (WWW) as a digital cash system. I get the impression they want to do this in some number of months or a year. Apparently they want to use the FORMS feature supported by most web browsers in conjunction with some sort of encryption algorithm. The idea is you connect to a commercial site, see see something you want to pay for, fill your credit card number in on the form, and transmit it back to the http server with some kind of encryption. They're talking about using some encryption technique present or expected in the Netscape browser. As far as I can tell this method will not involve any sort of authentication, and it will only secure data after it has left your browser and before it gets decrypted. Are these people for real? This has to be one of the most foolish things I've heard in a long time, but I'd like to hear some comments from RISKS readers — I'm no expert in these matters. It might also be an idea to crosspost a bit of the discussion back to *.www.* to wake these folks up. Justin Wells rjwells@uwaterloo.ca
I received an envelope in the mail yesterday that was immediately identifiable as junk mail by the word "URGENT" printed in large red letters imitative of a rubber stamp. Thus I was taken aback that the envelope appeared to be hand-addressed with a felt-tip pen. Closer examination revealed that the apparently sloppily scrawled capital N in my first name was identical to that in "NY", the even sloppier lower-case A in my first name was identical to those in my street name and city name, and so forth. Nonetheless, to the casual observer, the effect was quite convincing. The risk is an old one--the use of computers to perpetrate a deception.
While watching the multicast of the current IETF session [Automatic Address Configuration], I was presented with a message imposed by the broadcasting group of "susanp@spinnaker please stop broadcasting". I looked at the monitor, and sure enough, there was *another* video session being broadcast. For the next ~5 minutes, everyone on the multicast backbone was allowed to watch as susanp worked on some html markup [using hotmetal], then responded to a bit of e-mail. The risk turns out to be that the newest version of the NV video transmission software allows you to transmit video across the mbone without a camera... any window or cursor-followed region will be happily transmitted to the world... It is not obvious in ANY way that you are actually transmitting any information... I called the person listed in the WHOIS database for the address range that Susanp was in and the session went away, BUT... what would have happened if susanp had started doing something that was more company confidential? Since folks are recording the multicast digitally, all it would take is one screen shot with private information.. - -abc
As many of you know, the National Research Council is undertaking a study of national cryptography policy (description available on request to CRYPTO@NAS.EDU). This note is the first of a number of questions that will be posted to the Internet community in our attempt to solicit input on a broad scale. Please circulate this request to anyone that you think might be able to contribute. The question of this posting is the following: How, if at all, do capabilities enabled by new and emerging technology in telecommunications (e.g., key-escrow encryption technologies, digital telephony) and electronic networking make it _easier_ for those who control that technology to compromise and/or protect the interests of individual end users? Please use as the standard of comparison the ease _today_ of compromising or protecting these interests. We are interested in scenarios in which these interests might be compromised or protected both individually and on a large scale. Please be sure to tell us the interests you believe are at stake. Please send your comments on this question to CRYPTO@NAS.EDU.
You may amused/horrified to hear of an incident that occurred at a major city bank last week here in the UK. On hearing of the Pentium bug, they decided to test all of their machines to see which had the problem. They compiled up a test program and checked all of their Pentium based machines and discovered that all of them had the fdiv bug. They decided to be extra cautious and run the same program on all the other machines. To their horror all of the 486 machines exhibited the same problem. After several days of headless chicken impersonations, a more-level head decided that something must be awry and called in a good friend of mine who in short order discovered their mistake. The test program was compiled on a Pentium box and had the sum performed with constants. The compiler had noticed the use of constants and had performed the sum there and then, putting the result in the executable to be printed on demand on whichever box it was run on. The risks involved are obvious but the solution is less so. Even if the sum is done using variables, what is to stop the compiler from noticing that the values do not change between initialisation and the time of performing the calculation, and cause the same problem ? (Yes, I know. Use functions, pass parameters. But what if it gets in-lined, and then optimised ?) Admittedly this only normally occurs on binaries that are shipped for alternative platforms, but how many software houses use the smaller chips (386/486) as the main compile engine before shipping ? And of course, users who have Pentiums without the bug, but use software compiled by a chip with it are also susceptible. The effects and problems of this are going to be with us for a long time. Martin Poole, Perot Systems Europe mpoole@heac006.gb.ec.ps.net mpoole@cix.compulink.co.uk
I spent 3 hours holding in the queue for XXX tech support before I got to speak to a person. When I did, I mentioned my wait. He apologized for the delay, then observed that his 'hold-time' counter had overflowed at 99 minutes..... Such invalid data should do wonders for their staffing projections.
> Many formal approaches would not have caught this kind of error ... I haven't followed all the arguments about random testing, but it's also the case that random testing is not appropriate for this sort of problem. If you have something like a lookup table in there, it really does make sense to make sure that you test *all* the entries in that table: trying to do this with random numbers is crazy. As to trusting it because it was generated by computer: well, I wouldn't trust *anything* that was easy to check if I was about to make millions of dollars worth of it. --tim
You may have received a few messages recently regarding a supposed computer
virus spread through the mail. Unfortunately, it's nothing new — in fact,
it was announced in a RISKS submission not too long ago. With the kind help
of the RISKS moderator (no doubt, digging out from under his own avalanche
of reports), I am enclosing it for your consideration.
Martin Minow minow@apple.com (note new address)
RISKS-LIST: RISKS-FORUM Digest Friday 1 April 1988 Volume 6 : Issue 53
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
[...]
Date: 1 Apr 88 00:00
From: minow%thundr.DEC@decwrl.dec.com
(Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)
Subject: Virus attacks RISKS
Today, I'm afraid I must confess that one of my recent postings to RISKS
contained a Virus that Peter (no doubt inadvertently) distributed to the
RISKS audience. The virus doesn't infect your programs or data files
directly, but in a manner analogous to the "Christmas card" virus discussed
here a few months ago, it causes increased network traffic.
As the virus establishes itself, you will note its affect by the increased
amount of electronic mail you receive every day. For some of you, the
increase is linear; but for others, I'm afraid you're on the early part of a
exponential curve.
Although the virus was easy to create, I'm afraid that I don't know how to cure
it. In fact, I believe I'm beginning to note its effects on my own system.
Humbly, Martin Minow
[PS: No avoid another visit from corporate security, please take careful
note of the date of the original submission.]
[PPS: No, I didn't hack the mail protocol to get that date: I just stayed
up late that evening.]
Naah — "Good Times" is the first *meta*virus. The target is available bandwidth itself; it acts by getting well-meaning users to send virus warnings to huge, massively overlapping mailing lists. :) Joe "Dyn-o-mite!" Chew
In RISKS 16.62 Zygo Blaxell (zblaxell@miranda.uwaterloo.ca) and Reuven
Lerner <reuven@hpwadck.wal.hp.com> both make good points re the "Good Times"
'virus' where the message about a virus it *itself* a virus! (With possibly
bad long term effects.) Computer viruses & human fads (like passing on the
Good Times warning) both fit the model of a meme. (See _Selfish Gene_ by
Richard Dawkins.) A meme is one type of *replicating information pattern*,
genes are the other main class. Putting a class name such as "meme" on Good
Times helps us group things/events into classes where we can expect
analogous effects.
What computers and fast communications have done is to radically change the
replication constants for memes, and to make unworkable the controls society
has tried to put on such things.
Keith Henson (whose articles on memes are widely available on the net.)
[Re: Joe Chew's previous item: *Meme chose?* PGN]
> ... the book contains a substantial number of typos ... This is all too correct. I should like, however, to add three points: (1) The book contains not only many typos, but also a number of serious errors in its descriptions of some of the algorithms. (I pointed out several of these last June; copies of my posting are available from me by e-mail.) (2) While Schneier himself maintains a cumulative errata sheet, the publisher (Wiley) apparently refuses to include it with copies of the book which have been distributed since the appearance of the errata sheet. (3) The good news is that Schneier is preparing a second edition, which will, of course, correct all known errors. It will also contain several new sections not present in the first edition. Y. Radai, Hebrew Univ. of Jerusalem, Israel, RADAI@VMS.HUJI.AC.IL
As one who worked on bill-payment ("remittance processing") systems many
years ago, I find this conclusion [take the phone number off the check, not
the stub] highly implausible, to put it mildly. A phone, utility, or
credit-card company in a moderately large city must process literally
hundreds of thousands of payments every day (divide the phone population by
30). The return portion of the bill is carefully encoded with many things,
including both the account number and the amount due. That way, when the
human operator types in the amount of the check, it is assumed correct if it
matches the amount due, saving a costly verification step. Since the bill
stub *has* to be OCR'ed, why would anyone build a complex and expensive
system to scan the check for a phone number, printed in an unknown location
in an arbitrary typeface (if it's present at all) instead?
It is far more likely that Russell accidentally sent in the wrong half of
the stub, or no stub at all, and a human somewhere was faced with trying to
credit the proper account with his payment. Since the phone number was on
the check, the human assumed it represented the proper account — an
unjustifiable assumption, but an understandable one when you consider that
there are thousands of these errors to deal with every day, so that it's not
practical to make a phone call to verify the assumption, and the customer
would probably get very upset if you mailed the check back without cashing
it.
The RISK here is not a computer risk, but simply that it is always
unfortunate to fall through the cracks of a system that is too big to
give individualized service.
Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com
>As one who worked on bill-payment ("remittance processing" systems many
>years ago, I find this conclusion highly implausible, to put it mildly.
So would I! But I am only repeating to you what the woman at the phone
company told me; and my $150 *was* credited to my dad.
Actually, on further reflection, I've come to the conclusion that it
probably *wasn't* an automatic scanner, but a human being. I suppose
that sort of invalidates this as a Technological RISK.
>It is far more likely that Russell accidentally sent in the wrong half
>of the stub, or no stub at all, and a human somewhere was faced with
>trying to credit the proper account with his payment.
No, I sent in the correct portion of the bill, as I always do. Believe
me, if you'd had the experiences I've had with the local US West office,
you wouldn't be so skeptical.
Russell Stewart Albuquerque, New Mexico diamond@rt66.com
Several people have suggested to me, some rather haughtily, that my
corrupted /etc/hosts file would not have come about had I been using an
operating system that supported file locking by default--that is, if only
one process could have a file open for writing at a time.
Looking over the code to see if this was true revealed Cause 4. It turns
out that the file is built up in several phases:
1. Generate the entries for `localhost' and `loghost'
in a temporary file.
2. Append the entries for machines I am likely to use often
to the temporary file.
3. Append all the other entries to the temporary file.
Because this is done as a shell script, each phase opens the file,
appends to it, and then closes it. That means that file locking
would not have avoided the race condition.
One person suggested to me that I should have built /etc/hosts in
a temporary file rather than immediately overwriting the good copy.
In fact, I did just that. However, since I `knew' that the program
would never run more than once at a time, I used a fixed name for the
temporary file. Since that name was in my home directory, each process
on each machine used the same file.
Finally, I will note that I know how to make the program safe against
multiple accesses, even without file locking: use a separate temporary file
for each invocation and then, instead of copying the file to its final
place, move it there atomically. I don't know how to make such things
automatic, though, and it's far from clear that one should always take such
precautions, even for programs one believes will be run only on one's own
behalf.
--Andrew Koenig ark@research.att.com
The Computer Science and Telecommunications Board (CSTB) is pleased to announce the availability of a new report entitled _Rights and Responsibilities of Participants in Networked Communities_. Given increasing public interest and concern over the behavior of people on electronic networks, the report seeks to illuminate, to question, and to articulate difficult issues that arise in this context, and thus to help to lay a foundation for a more informed public debate and discussion of the rights and responsibilities of those who operate in this domain. The report is based on a workshop and a public forum involving technologists, lawyers, policy analysts, network service providers, and network operators in the exploration of several hypothetical but plausible scenarios in four areas (free speech, electronic vandalism, intellectual property interests, and privacy). The report illustrates how disagreements in these areas are rooted in value judgments; for example, the extent to which continuity with past precedents is desirable. Lawyers and policy-makers often argue that rights and responsibilities in a new domain inherently derive from existing rules, the report says. By contrast, technologists with extensive network experience often assert that with a new medium and a new form of human expression should also come new rules of social intercourse. The report notes that these four areas have always been inherently contentious, but over time certain compromises and understandings have evolved that guide what people do when communicating via traditional media such as print, telephone, radio, and television. Today the proliferation of networking technology threatens this state of understanding because it changes the environment in which previous compromises were achieved, leading to a re-examination of the same fundamental issues. The report is available from the National Academy Press for $25.00 (prepaid) plus $4.00 shipping for the first copy and $.50 shipping for each additional copy; tel. (202) 334-3313 or 1-800-624-6242. It will also be available soon on the WorldWide Web at http://www.nas.edu; via Gopher at gopher.nas.edu; and via FTP at ftp.nas.edu. The National Research Council is the principal operating arm of the National Academy of Sciences and the National Academy of Engineering. It is a private, non-profit institution that provides independent advice on science and technology issues under a congressional charter. CSTB addresses national scientific and policy issues in computing science, telecommunications, and computer technology and their applications.
I have recently setup a Mosaic server with on-line copies of the
RISKS Digest and other on-line material on similar topics. This server
allows the user to search full text for any given word, and produces a
listing of all occurrences (in context). The user then selects the
desired item(s) and views the files they occur in.
I am writing to RISKS for 2 reasons. One is to ask permission
to use the Risks Forum in this way (after all, it is copyrighted as of
its creation), and the other is to inform your readers of the proper
URL (http://all.net:8080).
Please don't search for anything like "and". You will find that
the search produces a LOT of useless results.
FC
[FRED: Many thanks for doing this! I'll add it to the Info.
Yes, you have my permission. But I trust that your home page will
request users to respect any copyrights (explicit or implicit) and
fair-reuse practices. Also, suggest that folks should remember to
scan for subsequent corrections... PGN]
Please report problems with the web pages to the maintainer