RISKS-LIST: Risks-Forum Digest Weds 21 February 2007 Volume 24 : Issue 57
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/24.57.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Govt Health IT: Electronic prescribing is no panacea (Deborah Peel)
DNS roots attacked (PGN)
AACS: A Tale of Three Keys, by J. Alex Halderman (via Monty Solomon)
Amazing boilerplate text in Fairfax County e-mail (Gabe Goldberg)
Crashing an in-flight entertainment system (Steve Summit)
Infrastructure risks: pump-station alarm (Matt)
Carmakers copy and repeat error almost forever (Doug McIlroy)
Two war stories from the NASA trenches (Ron Garret)
US government's contracts tracked by contractors (Ken Knowlton)
Study Finds Security Flaws on Web Sites of Major Banks (Gabe Goldberg)
Web Site Wants JPEG of Government ID (Mike Conley)
Re: Math libraries (Peter B. Ladkin)
Re: Excel Date Bug (John Levine)
Impact of DST changes on BlackBerry device users (Monty Solomon)
Re: Digital cameras converted to weapons (Leonard Finegold)
Re: Canadian coins containing tiny transmitters (Adam Abrams)
New Short Video: "Is Your Cell Phone Bugged?" (Lauren Weinstein)
REVIEW: "Code Quality: The Open Source Perspective", Diomidis Spinellis
(Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 18 Feb 2007 00:27:48 -0600
From: "Dr. Deborah Peel" <dpeelmd@private>
Subject: Govt Health IT: Electronic prescribing is no panacea
You should know about this massive violation of the privacy of every
American who takes medication.
This opinion piece is about the fact that there is no such thing as a
private prescription in the nation. Identifiable prescription data is sold
to insurers for medical underwriting and to large employers to use as they
see fit (discrimination?).
Electronic prescribing is no panacea
By Dr. Deborah Peel, Saturday, February 17, 2007
http://www.governmenthealthit.com/article97686-02-19-07-Print
When a coalition of technology companies, insurers and health care providers
launched a $100 million project last month to provide free electronic
prescribing software to every physician in the United States, it was greeted
with cheers. The presence of brand name vendors was supposed to ensure that
sensitive prescription records would be private and secure.
But those who believe there is anything private about e-prescribing under
the National ePrescribing Patient Safety Initiative (NEPSI) - or any other
e-prescription system - are simply incorrect.
Security makes little difference because every identifiable prescription in
the country is data mined and sold daily. Nobody needs to break into
pharmacies to steal our prescriptions; they are for sale. For example,
market intelligence firm IMS Health reported revenues of $1.75 billion in
2005 solely from the sale of prescription records, primarily to drug
companies.
Privacy is the right to control who sees your sensitive health records and
the right to decide if those records are even entered into electronic
systems. But it is impossible for anyone to have a private prescription -
meaning that it is never disclosed without a patient's consent - because
data mining has eliminated that right.
Furthermore, many people refuse to take psychiatric medication or other
medications in an attempt to prevent the pharmacy benefits management
industry from reporting to employers that they are on antidepressants or
other medications.
Knowing that prescriptions are not private also keeps people with other
sensitive illnesses from taking medications. And that exerts pressure on
doctors to avoid prescribing pain medications - out of concern that the
Drug Enforcement Administration is tracking their prescribing patterns.
The lack of prescription privacy is a problem that endangers people's
lives and quality of life.
That brings us to more misinformation about e-prescribing: that it is a
panacea for preventing prescription errors. Pharmacies have been
converting handwritten prescriptions into electronic prescriptions for
more than a decade, so software that catches errors and drug
interactions could have been used before with electronic prescription
data. Doctors don't need to issue e-prescriptions to reap the benefits
of software that checks for correct doses and a drug's conflicts with
other medications.
In the rush to extol the benefits of e-prescribing, NEPSI also neglects
to mention that e-prescribing will introduce new sources of error. It
could produce about the same rate of errors as written prescriptions.
With written prescriptions, two licensed professionals - the physician
and the pharmacist - look at the prescription. Two experienced humans
are paying attention. If there are any questions, the pharmacist calls
the doctor. With e-prescribing, only one human will look at the
e-prescription, the doctor. Indeed, e-prescribing may make errors more
common than when doctors write prescriptions.
Most people do not know that they cannot keep prescription records
private - it's a huge area of ignorance. Now that we are moving rapidly
into an e-health system, we need to build it right. Congress should
follow the lead of New Hampshire, which passed a law in 2006 to stop
illegal and unethical prescription data mining.
We need all the benefits that health information technology can bring,
but we also need privacy. Technology can provide both - we should never
have to choose between our privacy and our health.
Peel is a physician and chairwoman of the Patient Privacy Rights
Foundation based in Austin, Texas.
------------------------------
Date: Tue, 6 Feb 2007 17:19:19 PST
From: "Peter G. Neumann" <neumann@private>
Subject: DNS roots attacked
Hackers briefly overwhelmed at least three of the 13 computers that help
manage global computer traffic Tuesday in one of the most significant
attacks against the Internet since 2002. Experts said the unusually
powerful attacks lasted for hours but passed largely unnoticed by most
computer users, a testament to the resiliency of the Internet. Much rogue
data was traced to South Korea. UltraDNS was a particular target. Attacks
passed largely unnoticed by most computer users. [Source: AP item, 6 Feb
2007, PGN-ed; Thanks to Lauren Weinstein.]
http://www.cnn.com/2007/TECH/internet/02/06/internet.attacks.ap/index.html
[See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in
Oct 2002. Perhaps the Internet is somewhat more robust now? PGN]
------------------------------
Date: Sat, 17 Feb 2007 11:35:21 -0500
From: Monty Solomon <monty@private>
Subject: AACS: A Tale of Three Keys, by J. Alex Halderman (Re: RISKS-24.55)
This week brings further developments in the gradual meltdown of AACS (the
encryption scheme used for HD-DVD and Blu-Ray discs). Last Sunday, a member
of the Doom9 forum, writing under the pseudonym Arnezami, managed to extract
a "processing key" from an HD-DVD player application. Arnezami says that
this processing key can be used to decrypt all existing HD-DVD and Blu-Ray
discs. Though currently this attack is more powerful than previous breaks,
which focused on a different kind of key, its usefulness will probably
diminish as AACS implementers adapt.
To explain what's at stake, we need to describe a few more details about the
way AACS manages keys. Recall that AACS player applications and devices are
assigned secret device keys. Devices can use these keys to calculate a much
larger set of keys called processing keys. Each AACS movie is encrypted
with a unique title key, and several copies of the title key, encrypted with
different processing keys, are stored on the disc. To play a disc, a device
figures out which of the encrypted title keys it has the ability to
decrypt. Then it uses its device keys to compute the necessary processing
key, uses the processing key to decrypt the title key, and uses the title
key to extract the content. ...
http://www.freedom-to-tinker.com/?p=1121
------------------------------
Date: Mon, 05 Feb 2007 17:20:04 -0500
From: Gabe Goldberg <gabe@private>
Subject: Amazing boilerplate text in Fairfax County e-mail received today
The following hard-to-believe text speaks for itself. Fairfax County (VA)
prides itself on being techno-savvy, on the cutting edge of the new economy,
and other similar blather. Looks like the "cutting edge" is severing Fairfax
from the Internet. Being offline would be bad enough, but bouncing e-mail?
For three or four days? Amazing. I wonder how many people won't know in
advance and will be baffled/frustrated/angered/outraged?
*** Fairfax County information technology services will be unavailable
beginning February 17 and resume on February 20. My account will be
inaccessible during this timeframe and any incoming e-mail will be bounced
to the sender. In effect, Fairfax County will temporarily cease to exist
online for this period. We apologize for the inconvenience.***
------------------------------
Date: Wed, 21 Feb 2007 00:16:08 -0500
From: Steve Summit <scs@private>
Subject: Crashing an in-flight entertainment system
Hugh Thompson reports that he was able to get an airplane's in-flight
entertainment system into a significantly unexpected state, by (a) using a
numeric keypad, rather than the normal up/down buttons, to enter a value one
higher than a Tetris game's preference was intended to allow, then (b) using
the normal "up" button to increment the value still further -- evidently the
programmer had implemented "if(value == 4) {don't increment}" rather than
the more robust "if(value >= 4)". When he incremented the value past 127,
not only his screen, but every seat-back screen on the whole plane went
black, until a flight attendant reset the system. Further details at
http://blogs.csoonline.com/node/151 [with some subsequent discussion].
------------------------------
Date: Tuesday, 5 Feb 2007 13:55:00 -0500 (EST)
From: "Matt"
Subject: Infrastructure risks: pump-station alarm
A tree-trimming contractor clearing power lines cut a phone line which
serviced a pump-station alarm. The alarm is supposed to be checked twice
daily, but the pump was out of commission for four days, leading to a
massive sewage spill.
http://www.charlotte.com/mld/charlotte/news/16593620.htm?source=rss&channel=charlotte_news
The risks are clear; multiple single points of failure (the alarm, the phone
line, the pump station, the human verification), no method to check for a
failure of the alarm, and a possible flaw in the human logging / reporting
side of things.
------------------------------
Date: Sun, 18 Feb 2007 14:25:50 -0500
From: Doug McIlroy <doug@private>
Subject: Carmakers copy and repeat error almost forever
RISKS-16.3, 5 May 1994, contained an account of the shock of being locked
out automatically after closing the door on a stopped car with the engine
running. (Not unlikely if you get out to check the roof rack, fetch the
mail, etc.) The problem was reported for a Chevvy; I met it years later in
a 2001 Ford Focus. Poking around the web, I find reports of the same
trouble in car models as recent as 2006 from various makers. Disheartening
that such a trivially fixable misfeature should be imitated so widely and
persist so long.
------------------------------
Date: Wed, 7 Feb 2007 23:55:32 -0800
From: Ron Garret
Subject: Two war stories from the NASA trenches
One of my favorite case studies is getting a bit long in the tooth, but it
has never to my knowledge been cited or discussed in RISKS, so from the
better-late-than-never department I give you:
http://ase.arc.nasa.gov/publications/pdf/2000-0176.pdf
This is the story of the NASA Deep Space 1 Remote Agent Experiment (RAX),
and a bug that appeared in the RAX executive despite a then-
state-of-the-art effort to develop fault-free software. The approach was
very much like the "software-IC" approach that has been advocated off and on
for decades (I remember first hearing about it when I was a grad student,
and a 5MB hard drive was considered a lot of storage). To summarize and
radically oversimplify, a "substrate" layer was developed and exhaustively
analyzed using formal methods to insure that it maintained certain
invariants (like being deadlock- free). Application code was then developed
on top of this exhaustively analyzed substrate, in effect "wiring together"
the supposedly reliable components.
To make a very long story much too short, one of the applications
programmers inadvertently undermined the invariants that were supposed to be
guaranteed by the substrate when he needed a feature that the substrate
didn't provide. Instead of requesting that the feature be added to the
substrate, he just "rolled his own" (it was only two lines of code), and
thereby undermined the guarantees that the substrate provided. The
resulting bug was never detected during extensive ground testing, but
nonetheless failed in flight.
It was quite a humbling experience, and it makes a worthwhile read even
today.
As long as I'm telling war stories, I'll offer up a second one which was
never published. This happened in 1989.
We were developing code for autonomous mobile robots (what was to eventually
become the Mars Pathfinder mission) using a dialect of Lisp called T. We
had ported the T compiler from a Sun3 to a Heurikon 680x0 board running
vxWorks. We found that when the robot moved its arm the Lisp process would
crash intermittently. Forensic analysis after the crash revealed a
completely and nondeterministically corrupted heap.
This was the probably the most challenging bug I've ever encountered in my
career because it was impossible to reliably reproduce, and when it happened
it obliterated everything that might provide a clue as to why it happened.
Another long story short (it took us over a year to figure it out) the
problem turned out to be a bug in the T compiler: in the code emitted to
return from a function, the stack pointer was adjusted while they were still
live vales on the stack. On the Sun this was not a problem because user
processes ran in a different address space from the kernel. But under
vxWorks interrupt handlers used the same stack as the process being
interrupted. So when an interrupt happened right in between those two
instructions the unprotected value on the stack was obliterated by the
interrupt handler code, resulting in a gradual corruption of the heap.
The moral of the story is that even code that tests perfectly under formal
analysis and/or extensive use may yet contain latent bugs.
------------------------------
Date: Mon, 5 Feb 2007 18:09:32 EST
From: Ken Knowlton <KCKnowlton@private>
Subject: US government's contracts tracked by contractors
(From AOL's NY Times news section, pertinent to "RISKS" for several reasons.
Complete article: http://www.nytimes.com/2007/02/04/washington/04contract.html
Contractors still build ships and satellites, but they also collect income
taxes and work up agency budgets, fly pilotless spy aircraft and take the
minutes at policy meetings on the war. They sit next to federal employees at
nearly every agency; far more people work under contracts than are directly
employed by the government. Even the government;s online database for
tracking contracts, the Federal Procurement Data System, has been outsourced
(and is famously difficult to use).
------------------------------
Date: Mon, 05 Feb 2007 09:02:02 -0500
From: Gabe Goldberg <gabe@private>
Subject: Study Finds Security Flaws on Web Sites of Major Banks
Internet security experts have long known that simple passwords do not fully
defend online bank accounts from determined fraud artists. Now a study
suggests that a popular secondary security measure provides little
additional protection. [Source: Brad Stone, *The New York Times*, 5 Feb
2007]
http://www.nytimes.com/2007/02/05/technology/05secure.html?th&emc=th
http://topics.nytimes.com/top/reference/timestopics/people/s/brad_stone/index.html?inline=nyt-per
------------------------------
Date: Sun, 18 Feb 2007 12:17:45 +0000
From: Mike Conley <nomad@private>
Subject: Web Site Wants JPEG of Government ID
I recently visited a Web site, <http://www.istockphoto.com>, which provides
low-cost downloads of photographic images submitted by registered
users. It's actually quite nice, and rather professional-looking, and I was
interested in uploading some of my photos and perhaps making a few dollars
on them.
I discovered while registering that, in order to upload images, one has to
establish an upload account, a requirement for which is the submission, over
the Internet, of a scanned JPEG image of a government-issued identity
document, such as a driver's licence or -- even better -- a passport.
Further comment doesn't really seem necessary.
------------------------------
Date: Mon, 05 Feb 2007 09:03:49 +0100
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: Math libraries (Robinson, R 24 54, Karpinski, R 24 56)
Dick Karpinski suggests in RISKS-24.46 that Paul Robinson's worries about
the hardware math functions in the 586 class of processors are not as well
founded as his worries about software math functions. I concur. Dick could
have told more of the history.
William Kahan at U.C. Berkeley has been worrying about floating point
calculations in computers for the last four decades and won the Turing
Award, the highest award for technical contributions to computing science,
in 1989 for these efforts. Intel was interested in defining portable
accurate floating point computations, in advance of their introduction of
the math coprocessor for the i8086/8 series (i.e., what was to become the
8087). Impressed by Kahan's understanding of the problems as well as his
efforts on behalf of Hewlett Packard, Intel engaged him to help further this
cause. Kahan worked with a PhD student of his, Jerry Coonen, and Harold
Stone, to define a proposal for the IEEE p754 committee which became in
large part the IEEE 754 standard. One can read more about it in some notes,
for an IEEE Computing article in 1998, on Kahan's WWW site at
http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html
I was the Teaching Assistant for the graduate numerics course in the Math
Department at UCB at the time that Jerry took it. Assessing the assignments
was a breeze. One first looked at Jerry's solutions and those of Jamie
Sethian (now himself a math professor at U.C. Berkeley) to see how to do it
right. (Those are the advantages of graduate teaching-assisting at a place
such as U.C. Berkeley. You can always assume that there is at least one
student who is better than yourself, and sometimes more.) Jerry finished his
PhD, on the FP work, waaay before I finished mine. I remember him telling me
that the way to be certain of a good job was to become acquainted with every
line of the BSD source code. Those were the days. But even in those days it
was expanding faster than one could read it (besides, that was not the right
way to get a PhD in Logic and the Methodology of Science, for probably more
than one reason :-).
To my mind, IEEE 754 is one of the success stories in our efforts to reduce
mistakes in computing. It is a pity certain spreadsheet programmers didn't
emulate its example.
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: 5 Feb 2007 01:16:58 -0000
From: John Levine <johnl@private>
Subject: Re: Excel Date Bug (Winter, RISKS-24.56)
> The most obvious solution would be to decrement the day numbers before 1
> Mar 1900, effectively setting the epoch one day later...
That's what Open Office does. Dates in 1-2-3 and most spreadsheets are
internally represented as integers with 1-Jan-1900 as day 1. In Open
Office, day 1 is 31-Dec-1899, so dates before 1-Mar-1900 are off by one day.
This does not necessarily improve the situation. In spreadsheets I've seen,
it's quite common to enter dates simply as dates, to mark when something
happened, less common to do date arithmetic, and I've never seen anyone
doing date arithmetic as far back as 1900. So this change fixes the date
arithmetic, at the cost of making dates before March 1900 display wrong.
I am not a big fan of Microsoft, but in this case I have to agree with them
that there's no change to this bug that will make the situation better than
it is now. They clearly did think about this change, and rejected it for
sensible reasons.
John Levine, johnl@private, http://www.johnlevine.com
------------------------------
Date: Mon, 19 Feb 2007 20:05:57 -0500
From: Monty Solomon <monty@private>
Subject: Impact of DST changes on BlackBerry device users
Impact of North American Daylight Saving Time changes in 2007 on BlackBerry
device users:
http://www.blackberry.com/select/dst2007/
------------------------------
Date: Sun, 4 Feb 2007 18:43:21 -0500
From: Leonard Finegold <L@private>
Subject: Re: Digital cameras converted to weapons (R 24 54,56)
Everyone is right:
At $13.99 this "Digital" camera looks suspiciously like CVC's ye olde
chemical-type cameras of about the same price. I strongly suspect that what
CVC calls "Digital" on the box (note they say "Simple Digital Processing")
is what we mortals would call non-digital.
'The question is,' said Alice, 'whether you can make words mean so many
different things.' Alice in Wonderland, CL Dodgson
Leonard X. Finegold, Physics, Drexel University, Philadelphia PA 19104 USA
L@private Phone 215.895.2740
------------------------------
Date: Sun, 04 Feb 2007 21:32:24 -0800
From: Adam Abrams <adamabrams@private>
Subject: Re: Canadian coins containing tiny transmitters
There was a followup story in which the Defense Department reversed
themselves. There were no transmitters.
http://edition.cnn.com/2007/TECH/01/19/canada.spy.coins.ap/
I think some American contractors just thought the Canadian coins (probably
the thick two-dollar coin which has a gold inner part and a silver outer
part) looked funny and a wild idea became a rumour, which became a "reported
fact".
With field intelligence like that, the "war on terror" will be won any day
now, I'm sure...
Adam Abrams adamabrams@private (604) 685-7634 www.adamabrams.com
------------------------------
Date: Fri, 16 Feb 2007 21:13:01 -0800
From: Lauren Weinstein <lauren@private>
Subject: New Short Video: "Is Your Cell Phone Bugged?"
Greetings. I've been getting lots of continuing interest and queries in the
wake of my blog item from late last year: "How To Tell If Your Cell Phone Is
Bugged" ( http://lauren.vortex.com/archive/000202.html ).
In an effort to explain this issue in a more demonstrative and somewhat less
technical manner, I'm pleased to announce a short free video (under six
minutes): "Is Your Cell Phone Bugged?"
While I'll admit that the production values are much closer to those of Ed
Wood than of Cecil B. DeMille, I hope you'll still find this video to be
interesting, or at least amusing.
"Is Your Cell Phone Bugged?" Video Access Pages:
YouTube (Streaming):
http://www.vortex.com/cellbug-vid-youtube
Google Video (Streaming & Download):
http://www.vortex.com/cellbug-vid-google
Lauren Weinstein +1-818-225-2800 http://www.pfir.org http://www.vortex.com
http://daythink.vortex.com lauren@private or lauren@private
------------------------------
Date: Tue, 20 Feb 2007 10:40:40 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Code Quality: The Open Source Perspective", Spinellis
BKCQTOSP.RVW 20061229
"Code Quality: The Open Source Perspective", Diomidis Spinellis, 2006,
0-321-16607-8, U$54.99/C$73.99
%A Diomidis Spinellis www.spinellis.gr/codequality dds@private
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2006
%G 0-321-16607-8
%I Addison-Wesley Publishing Co.
%O U$54.99/C$73.99 416-447-5101 800-822-6339 bkexpress@private
%O http://www.amazon.com/exec/obidos/ASIN/0321166078/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321166078/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321166078/robsladesin03-20
%O Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 569 p.
%T "Code Quality: The Open Source Perspective"
The preface points out that it is easy to test for the functional
requirements of an application: either the program performs the function or
it doesn't. Nonfunctional requirements (including such characteristics as
reliability, portability, usability, interoperability, adaptability,
dependability, and maintainability) are much harder to assess, and yet may
be more important. (In an automated train system, for example, the lack of
a function to change the schedule from within a given train still allows you
to use the train within a given schedule. Unreliability of the braking
system means the system is worse than useless.) In addition, "Code Reading"
(the title of Spinellis' previous book) is pointed out as the most common
activity for developers, and yet is a skill seldom taught in the programming
curriculum. The author has avoided using fictional code for the examples in
this (and the prior) work by providing sample code from open source software
projects, thus using working (but available) source code for illustrations.
Chapter one introduces the structure of the text by mapping characteristics
from the ISO 9126 quality standard to the chapters and sections of the book.
Inherent conflicts between different aspects of quality are also noted.
(For example, large numbers of discrete operations enhance the functionality
of a system, but at some cost in terms of usability.) Reliability is
examined, in chapter two, in terms of common flaws. Examples of such flaws
are given, followed by an explanation of the specifics of the problem. This
is followed by samples of code that address the problem stated. Each point
and section is accompanied by questions and discussion points that could be
used in a course teaching the issues of code quality. (Unlike all too many
sets of questions these are rigorous and challenging. Sometimes they may be
a little bit too demanding: occasionally the discussion would require
intimate knowledge of the internals of a specific programming language.)
The chapter ends with a summary of the points and factors covered.
Various security vulnerabilities and coding points are illustrated in
chapter three, but, in comparison to the rest of the work, this material is
weak and disappointing. Performance issues in relation to time are reviewed
in chapter four, and to space in five. The different factors of latency and
bandwidth, and the trade-offs between memory and speed are noted. It is
rather odd that Spinellis is at pains to point out that time efficiencies
negatively affect simplicity and portability, while he goes to great lengths
to provide suggestions for space optimizations for a variety of specific
architectures (which wouldn't help portability either).
Chapter six looks at a number of factors relating to portability, between
both hardware and operating system platforms. Maintainability is the
longest chapter (seven) in the book, and bears the closest relation to
Spinellis' previous work on "Code Reading." There is a special section on
the characteristics of object-oriented code. Chapter eight, on floating
point arithmetic, notes the sometimes surprising sources of inaccuracy.
In the information technology and development fields we are constantly
obsessed with production of code and the speedy release of the next version.
We need to stop and take a good look at the quality of what we produce: as
it frequently stated, the greatest source of computer problems is computer
solutions. In regard to security, it is demonstrably true that the exploits
and difficulties that we find are those that would never have been created
if only programmers had paid a little more attention to the fundamental
concepts they were first taught. I believe Spinellis' text should be
required reading for all programming courses and programs. In addition,
those involved with analysis, maintenance, and change control should
consider it a bible to be read and re-read until the lessons are firmly
implanted.
copyright Robert M. Slade, 2007 BKCQTOSP.RVW 20061229
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. The mailman web interface can
be used directly to subscribe and unsubscribe:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
=> The complete INFO file (submissions, default disclaimers, archive sites,
copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in RISKS issues.
*** Contributors are assumed to have read the full info file for guidelines.
=> .UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
<http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
<http://www.csl.sri.com/illustrative.html> for browsing,
<http://www.csl.sri.com/illustrative.pdf> or .ps for printing
------------------------------
End of RISKS-FORUM Digest 24.57
************************
This archive was generated by hypermail 2.1.3 : Wed Feb 21 2007 - 09:26:44 PST