RISKS-LIST: Risks-Forum Digest Wednesday 10 August 2005 Volume 24 : Issue 01
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.01.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Russian remote controlled submarine failure (Martyn Thomas)
Caltrans screwup (PGN)
Lightning causing problems for lightning-detection system
(Klaus Johannes Rusch, PGN)
Navy jet has severe brake failure (PGN)
US Navy to drop paper charts (Scott Peterson, PGN, Scott Peterson)
Social Security Administration sends cards to the wrong place (Jonathan Kamens)
German social services software drops changes (Debora Weber-Wulff)
Hermann Chinery-Hesse and software in Ghana (James H. Haynes)
Greeting answering machine! (R H Draney via Mark Brader)
Every odd digit of number A, even digit of number B (Dan Jacobson)
The risks of cell-phone auto-spellers (William Colburn)
Credit-card obfuscation (William Colburn)
Re: Car computer systems at risk to viruses (Adam Laurie)
Re: Increasing sophistication of phishing spammers (Jonathan de Boyne Pollard)
Re: Timezones and appointments (Sean Smith, Przemek Klosowski)
Re: New Microsoft anti-piracy program circumvented (Peter Gregory)
REVIEW: "File System Forensic Analysis", Brian Carrier (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 9 Aug 2005 15:00:12 +0100
From: "Martyn Thomas" <martyn@thomas-associates.co.uk>
Subject: Russian remote controlled submarine failure
A British Royal Navy remotely operated vehicle cut free the Russian
submarine that was trapped 600 feet down. According to the British commander
of the rescue, interviewed by BBC Radio 4 on 8 Aug 2005, the Russians had
remote controlled vehicles of their own, but they failed because of a
software error.
------------------------------
Date: Mon, 8 Aug 2005 15:58:55 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Caltrans screwup
Lauren Weinstein reported that Caltrans has started a 6-month experiment to
put real-time travel times on freeway signs. The immediate result is
apparently that traffic is tied up all over, as people slow down to read the
signs!
------------------------------
Date: Wed, 03 Aug 2005 01:26:42 +0200
From: Klaus Johannes Rusch <KlausRusch@private>
Subject: Lightning causing problems for lightning-detection system
Fortunately there were only a few minor injuries when a plane overshot a
runway at Pearson International Airport. According to a CBC report
(http://www.cbc.ca/story/canada/national/2005/08/02/pearson-plane050802.html)
most operations on the airport had been suspended due to bad weather: "... a
spokesperson with the Greater Toronto Airports Authority said lightning was
causing technical problems with the airport's lightning-detection system."
Why would one expect that lightning-detection systems could cope with
lightning?
Klaus Johannes Rusch KlausRusch@private http://www.atmedia.net/KlausRusch/
------------------------------
Date: Wed, 3 Aug 2005 14:59:40 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Lightning causing problems for lightning-detection system
My favorite meta-lightning event occurred was when I was giving a lecture in
my Survivable Systems course at Maryland, and I was talking about the time
at Wallops Island where they had several missiles ready to launch because
they wanted to study the effects of lightning on the missile controls. As
some of you may remember, lightning hit the launch platform and triggered
the launching of one of the missiles (which I mentioned most recently in
RISKS-20.42). Just at that point in the lecture, lightning hit the lecture
room and took down the computer controlling the outfeeds to remote
classrooms and our own video monitors. Some of the students wondered how I
had managed such a theatrical effect.
------------------------------
Date: Fri, 5 Aug 2005 11:22:36 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Navy jet has severe brake failure
The F/A-18 Hornet has had a series of recent accidents many of which are
being attributed to a very thin $535 electrical cable that controls the
antiskid brakes. An investigation also concluded that cockpit procedures
were confusing when pilots were confronted with brake failures. The
U.S. military owns 561 Hornets, best known for their use by the Blue Angels.
[Source: AP report, 4 Aug 2005; PGN-ed]
http://www.rednova.com/news/general/197786/ap_navy_jet_has_severe_brake_problems/
------------------------------
Date: Wed, 03 Aug 2005 00:51:24 -0700
From: Scott Peterson <scottp4@private>
Subject: US Navy to drop paper charts
Given some of the stories that have been posted here about the problems with
electronic navigation systems, the mind boggles at the potential for
disaster in this decision. [SP]
The U.S. Navy has committed to replacing its traditional paper nautical
charts with advanced, interactive, electronic navigation systems throughout
the fleet. The Electronic Chart Display and Information System - Navy is
based on the voyage management system software programs developed by
Northrop Grumman's Sperry Marine business unit, and operates with digital
nautical charts -- a global database of digital charts produced by the
National Geospatial Intelligence Agency. The Navy plans to equip the entire
fleet of surface ships and submarines with Ecdis-N by the end of 2009,
and no longer use paper charts after the electronic system is certified.
[Source: Lloyds List, 2 Aug 2005; PGN-ed]
------------------------------
Date: Wed, 3 Aug 2005 14:55:04 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Re: US Navy to drop paper charts
Risks might occur when their Net connection is down and they cannot get
their updated maps online! Remember the sub that ran into a rock. I wonder
whether that rock has ever shown up on an online map since then?
------------------------------
Date: Wed, 03 Aug 2005 17:38:50 -0700
From: Scott Peterson <scottp4@private>
Subject: Re: US Navy to drop paper charts (RISKS-23.96)
> I wonder whether that rock has ever shown up on an online map since then?
Actually part of the report on why that happened was because they were using
the wrong paper charts and were not updating them properly. The correct
charts did show a navigation hazard in that area.
http://navysite.de/ssn/ssn711.htm
On 9 May 2005, the Navy announced the completion of the investigation into
the accident. The report states that "The findings of fact show that SAN
FRANCISCO, while transitting at flank (maximum) speed and submerged to 525
feet, hit a seamount that did not appear on the chart being used for
navigation," and that "Other charts in SAN FRANCISCO's possession did,
however, clearly display a navigation hazard in the vicinity of the
grounding. SAN FRANCISCO's navigation team failed to review those charts
adequately and transfer pertinent data to the chart being used for
navigation, as relevant directives and the ship's own procedures required."
The report continues "If SAN FRANCISCO's leaders and watch teams had
complied with requisite procedures and exercised prudent navigation
practices, the grounding would most likely have been avoided. Even if not
wholly avoided, however, the grounding would not have been as severe and
loss of life may have been prevented."
------------------------------
Date: Sun, 7 Aug 2005 22:30:35 -0400
From: Jonathan Kamens <jik@private>
Subject: Social Security Administration sends cards to the wrong place,
won't admit it's due to buggy software they need to fix
The following is the introduction to
http://www.mit.edu/~jik/ssa-zip.html
-- which tells the whole story in sordid detail.
* * * * * * * * *
The software that the Social Security Administration (SSA) uses to
canonicalize mailing addresses when sending out social security cards has a
bug which causes correct ZIP codes in some addresses to be replaced with
incorrect ZIP codes.
This bug has been present for at least five years and has caused the social
security cards for three of my children to be "lost" in the mail after their
births.
The first two times this happened to me, the SSA resent a duplicate card
when I contacted them and complained that the original had never arrived.
The first two times this happened to me, the SSA refused to investigate why
the original card never arrived.
The third time this happened to me, I finally convinced the SSA to
investigate, and the bug was exposed.
The SSA refuses to admit that the behavior of their software is a bug,
despite the fact that any competent software engineer familiar with
address-canonicalization technology would understand immediately that it is
after being given a test case illustrating it.
The SSA refuses to issue a duplicate card for my youngest child unless I
file a form SS-5, which requires that I either (a) send original, personal
identification documents through the mail, which I am unwilling to do
because of concerns about identity theft and document loss, or (b) submit
the form SS-5 in person at one of their offices, which I am unwilling to do
because I think it's entirely unreasonable for me to have to miss work to
correct the SSA's error.
The SSA has already admitted that my youngest child's card was lost in the
mail and that they know why this happened. They've been corresponding with
me at the address to which the card was supposed to have been sent, which is
in their records, which means that they know for a fact that I am the father
of the child whose card was lost and that I am legally allowed to receive a
copy of the card. That they nevertheless refuse to issue a duplicate card
has no legitimate justification and can be explained only as bureaucratic
inertia or a stubborn refusal to admit fault.
* * * * * * * * *
If there is anyone reading this who works for or has connections at the SSA
and who has the knowledge and experience to understand the bug I'm trying to
get them to fix (I've yet to reach anyone at the SSA who has admitted to
understanding it), please help!
------------------------------
Date: Tue, 09 Aug 2005 12:23:38 +0200
From: Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>
Subject: German social services software drops changes
http://www.heise.de/newsticker/meldung/62595
The online computer news service heise.de reports that an error in the
software system A2LL, which computes welfare and jobless subsidies as well
as administering the system, has dropped over 100.000 changes that should
have been reported to health insurance providers.
New registrants, people going off welfare, address changes and the like were
registered with the system and then the changes were automatically
rescinded.
The error cropped up after a new version of the software was installed on
the central servers. [Perhaps they installed a test system by mistake that
just pretends to accept changes? -dww]
The missed changes will not affect the insurance status of the people
involved, but staff at the insurance companies must take care of all of the
changes by hand.
Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik
10313 Berlin +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/
------------------------------
Date: Tue, 9 Aug 2005 13:58:34 -0500 (CDT)
From: jhhaynes@private
Subject: Hermann Chinery-Hesse and software in Ghana
There is an interesting article in the August 2005 issue of IEEE Spectrum
on the above subject. Mr. Chinery-Hesse runs a very successful software
business in Ghana. Some of the high points:
* Software that is lean and efficient, so it runs well on old PCs such as
386/486. These are affordable in Ghana.
* Software design for robustness under third-world conditions. For example,
frequent writes to disk to minimize work lost of the power goes off, as it
frequently does.
* Rather extreme measures to protect proprietary software, such as updates
installed in personal visits by software company employees. This to cope
with conditions in a country where any sense of ethics is practically
nonexistent.
* Shunning of open source software, on the grounds that having the source
makes it too easy for unscrupulous users to modify the code so as to line
their own pockets.
This last item could well be criticized as security through obscurity.
Surely the incentives are there for users to make a considerable effort to
tamper with closed source proprietary software. One could argue that open
source software would be easier to audit for unauthorized modifications.
But then who audits the auditors? And how can they be sure that the code
actually running in the machine is accurately represented by the source code
they can see.
This suggests a larger research topic: how can we make computer systems that
are guaranteed to "work right" when they are to be installed in a den of
thieves? Seems like this has applicability to the problem of electronic
voting systems in the U.S.
------------------------------
Date: Mon, 8 Aug 2005 01:56:48 -0400 (EDT)
From: msb@private (Mark Brader)
Subject: Greeting answering machine! (R H Draney)
* From: R H Draney <dadoctah@private>
* Newsgroups: alt.usage.english
* Subject: Re: greeting answering machine!
* Date: 6 Aug 2005 18:40:47 -0700
* Message-ID: <dd3oqv02rdc@private>
Tony Cooper filted:
> I am unconventional, though. Just yesterday I called a doctor's office
> and told them they'd left a message on my machine that was intended for
> someone else. Neither my (first) name nor number registered with the
> person in the doctor's office that left a message that "my" appointment
> had been canceled because the doctor would be out-of-town. I thought it
> was the considerate thing to do.
My mother has been getting a series of calls from some lawyer's office in
North Carolina, telling her (or rather someone whose name is unintelligible
on the message) to call back at such-and-such a number...she's tried calling
the number several times and they always start off by asking her to punch in
her case number...as she has no case to number, the attempt to straighten
out these people ends there, with (1) some lawyer's client wondering why his
counsel hasn't called him, (2) the lawyer raising the penalty to the next
level for failing to make contact, and (3) my mother getting more and more
recorded messages....r
------------------------------
Date: Thu, 04 Aug 2005 07:55:26 +0800
From: Dan Jacobson <jidanni@private>
Subject: Every odd digit of number A, even digit of number B
The Taiwan telephone company has done it again. On their work order
notification they only show every odd digit of the phone number to be
serviced, 2*8*4*8*, and then for extra security, only every even digit of
the contact number, *5*5*7*0. But if contact number == phone number, all is
revealed, 25854780.
------------------------------
Date: Thu, 4 Aug 2005 15:24:23 -0600
From: "Schlake (William Colburn)" <schlake@private>
Subject: The risks of cell-phone auto-spellers
(my phone made me look like an idiot)
The first time I tried sending an SMS message on my new phone, I was
horrified at what happened. Attempts to type in a word generated huge
blocks of garbage text, beeping, and a refusal of the phone to continue. I
was trying to do it the "old way", by hitting a key multiple times to tell
which of the three letters I meant.
"That would make me happy." -> "8442809666885553062553304427 79991"
The space represents a pause in my typing to wait for it to reset the letter
selector. The new phone has smart spelling, so I can type a single number
for each word and it will magically spell the word I want. I resisted, but
the lure of magic won me over, and now I can SMS faster with many less key
strokes. I'm very happy with it almost all the time. Magic is great stuff!
Today I sent an SMS message.
"That would make me happy." -> "8428096853062530630427791"
Except....
"8428096853062530630427791" -> "That would make if happy."
My cat is named "If", so now it suddenly looks like I'm talking about my cat
(and I misspelled his name), and not me.
I immediately sent a followup message where I manually corrected the
spelling of "me" and appended a second sentence: "I have to pay more
attention to the auto speller."
The reply was: "You mean pay more attention."
First thought: Oh no, what I did I send? Thankfully, I only sent "I must
pay more attention to the auto speller."
It is embarrassing that I made the same error in my message correcting
myself. The risks are that magic isn't a DWIM. If the phone could 'do what
I meant' then I could talk to my phone in plain english to transmit my
message to someone halfway across the country[1], and not have to manually
type my message into it. Another risk is complacency: I have grown to
depend on auto-spelling, which is right so often that I've stopped reading
what it is doing and I just continue merrily typing away assuming that
everything is golden.
[1] I find it surprising how many people I know who consider their phone to
be a text-messaging platform that happens to have voice-chat capabilities
instead of a voice-chat platform that happens to have text-messaging
capabilities.
------------------------------
Date: Tue, 9 Aug 2005 10:24:29 -0600
From: "Schlake (William Colburn)" <schlake@private>
Subject: Credit-card obfuscation
I made a purchase from Bibliomania! today. I wasn't able to get the book I
wanted through either amazon.com or ecookbooks.com, so I used the site
suggested by the author of the book. I'm pretty mistrustful of online
merchants, but this one had an SSL page for the credit card info and I
really wanted the cookbook, so I went for it. The confirmation page that
came up, that it encouraged me to print, obfuscated my credit card number by
"x"ing out the last four digits.
The risk is that the last four digits are normally the ones not "x"ed out by
every other credit card processor that I've ever seen, so this confirmation
plus any other confirmation gives you 20 digits of a 23 digit credit card
number, and most places don't ask for the last 3 digits yet (card number
yyyy yyyy yyyy yyyy expires yy/yy series zzz is 23 numbers).
Thankfully the unencrypted confirmation e-mail they sent didn't mention
anything about the credit card at all, and it came in plain text and not
HTML.
[Note: PGN changed occurrences of "x" to y and z, to avoid filtering.]
------------------------------
Date: Tue, 09 Aug 2005 11:19:13 +0100
From: Adam Laurie <adam.laurie@private>
Subject: Re: Car computer systems at risk to viruses (RISKS-23.96)
Car kits are not only vulnerable to viruses, but also to privacy invasion
through eavesdropping of audio via the telephony microphone, as well as
social engineering attacks or simple 'nuisance calls' by pushing audio into
the car speaker systems... The proof-of-concept tool "Car Whisperer" can be
found here, along with more details of the attack:
http://trifinite.org/trifinite_stuff_carwhisperer.html
Adam Laurie, The Bunker Secure Hosting Ltd., Shepherds Building, Rockley
Road, London W14 0DA UK http://www.thebunker.net +44 (0) 20 7605 7000
------------------------------
Date: Wed, 15 Dec 2004 20:47:28 +0000
From: Jonathan de Boyne Pollard <J.deBoynePollard@private>
Subject: Re: Increasing sophistication of phishing spammers (Wallach, RISKS-23.60)
W> ... should pay attention to referrer information to refuse images being
W> sent to pages other than their own.
Checking referrer headers at the content HTTP server is not necessarily the
wisest course of action. It is easy to do wrongly, has maintenance problems
for the publisher, and is conceptually shaky as well. And it isn't
addressing the issue actually at hand, in any event. The far better way to
address the issue at hand is one that many people have been advocating for
quite some time now, for this and other reasons: ensure that all MUAs are
designed *not to automatically fetch external content* when displaying
messages (with body parts of any sort, not just "text/html", moreover).
<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/gnksoa-mua.html#NoAutoFetchExternalContent>
The RISK? Thinking that RFC 2017 is a good idea. (-:
I'm not aware of anything as detailed as the GNKSoA and the GNKSoA:MUA for
web browsers and HTML display engines, but were there one, one of my
suggestions for inclusion in it, that pertains here, would be the display of
(CIS) URLs broken-down into their component pieces, preventing the confusion
between domain parts and usernames that is often also exploited by these
electronic mail scams.
W> Probably the only true answer is for eBay, my credit card company,
W> and all of these other vendors to start digitally signing their mail.
It is interesting to note how many of these same companies make a point of
noting that they provide end-to-end validation when one is accessing their
web sites (For the case of eBay, for example, see
<URL:http://pages.ebay.com./securitycenter/avoiding_fraud.html#secure>.),
and yet fail to do the same thing for their electronic mail communications.
However, one should always bear in mind that the architecture of SMTP-based
Internet electronic mail is the architecture of paper mail. The former is
simply, and solely, cheaper ("There are fewer electrons in an electronic
mail message than in a sheet of paper. So it's cheaper by weight."),
allowing the architectural flaws to be revealed more readily. Digital
signatures *are* the tool for determining whether a message came from whom
it purports to have come from. However, look at paper mail and consider:
When you last received a paper communication from such a company, was it on
mass-printed stationery with a computer-printed copy of someone's signature
at the end? How did you know that that was the correct signature? What
steps did you take to validate it? Do you even know what the person's
correct signature is supposed to look like? When you next contacted the
company, did you use the contact information (telephone number, et al.)
supplied at the bottom of such a letter? When you telephoned the company's
customer account line using the telephone number from the letter, did you
supply your account number and password to the complete stranger on the
other end of the line?
------------------------------
Date: Wed, 3 Aug 2005 19:22:52 -0400
From: Sean Smith <sws@private>
Subject: Re: Timezones and appointments (Rothwell, RISKS-23.96)
I've had the inverse happen: a timer program that allows me to turn my
laptop into an alarm clock insisted on working according to the local time
back home in the US, rather than local time in the UK where I was---even
though the system time zone had been changed to the UK.
Sean W. Smith, Ph.D. sws@private www.cs.dartmouth.edu/~sws/
Department of Computer Science, Dartmouth College, Hanover NH USA
------------------------------
Date: Thu, 04 Aug 2005 22:36:27 -0400
From: przemek klosowski <przemek.klosowski@private>
Subject: Re: Timezones and appointments (Rothwell, RISKS-23.96)
I suspect that Nr. Rothwell stored the appointments for his US trip in US
local time values, but didn't tell that to the computer. Consequently, the
PDA assumed that he meant UK times, and shifted the values.
My left or your left? or rather, my 6 PM or your 6 PM? Most people would
raise this issue when setting an appointment across time zones. What we need
is a good user interface that allows, but doesn't always force us, to
specify the time zone in which the event is being entered. Perhaps the UI
should put up a time zone wizard if it matches "airport,flight,travel,etc."
among proximate events.
------------------------------
Date: Wed, 3 Aug 2005 12:25:54 -0700 (PDT)
From: Peter Gregory <petergregory@private>
Subject: Re: New Microsoft anti-piracy program circumvented (RISKS-23.95)
In my opinion, the most amazing part is that Microsoft DOES NOT CONSIDER
THIS TO BE A SECURITY FLAW. Will they respond in like manner when large
numbers of cars fall victim to the first wide-spreading, car-infecting worm?
Peter Gregory, CISA, CISSP, Chief Security Strategist,
VantagePoint Security LLC, Bellevue, WA phg@private
[Source: Hackers break into Microsoft's anti-piracy system. PGN]
http://www.techworld.com/security/news/index.cfm?NewsID=4134
------------------------------
Date: Mon, 8 Aug 2005 08:09:38 -0800
From: Rob Slade <rslade@private>
Subject: REVIEW: "File System Forensic Analysis", Brian Carrier
BKFSFRAN.RVW 20050608
"File System Forensic Analysis", Brian Carrier, 2005, 0-321-26817-2,
U$49.99/C$69.99
%A Brian Carrier
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2005
%G 0-321-26817-2
%I Addison-Wesley Publishing Co.
%O U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@private
%O http://www.amazon.com/exec/obidos/ASIN/0321268172/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321268172/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321268172/robsladesin03-20
%O Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 569 p.
%T "File System Forensic Analysis"
The preface states, correctly, that there is little information for
the forensic investigator on the topic of file system structures and
internals that are useful for providing direction on tracing and
tracking information on the disk. The author also notes that there
are a number of worthwhile texts that address the general topic of
investigation. Therefore, the author intends to address the former
rather than the latter. At the same time, there is an implication in
the initial section that this work is only the merest introduction to
the subject of computer forensics.
Part one is aimed at providing foundational concepts. Chapter one, in
fact, does provide a quick review of the investigation process, and a
list of forensic software toolkits. A sort of "Computers 101" is in
chapter two, with a not-terribly-well structured collection of facts
about data organization, drive types, and so forth, with varying
levels of detail. Chapter three addresses different factors and
problems in hard disk data acquisition, although the inventory is
neither complete nor fully explained.
Part two deals with the analysis of drive volumes or partitions, with
chapter four outlining basic structures. DOS (FAT [File Allocation
Table] and NTFS) and Apple partition details are discussed in chapter
five. Chapter six reviews various UNIX partitions. Multi-disk
systems, such as RAID (Redundant Array of Inexpensive Disks) are
covered in chapter seven.
Part three delves into the data structures of the file system itself.
Chapter eight introduces concepts used in considering file systems. Details
of the FAT system are in chapters nine and ten. A very detailed explanation
of the disk and file structures of the NTFS system, as well as
considerations for analysis, is provided in chapters eleven to thirteen.
The Linux Ext2 and Ext3 structures are discussed in chapters fourteen and
fifteen. Chapters sixteen and seventeen cover the UFS1 and UFS2 schemes,
found primarily in BSD (Berkeley Systems Distribution) derived versions.
This book does provide a wealth of detail, once it gets into the
specifics of partitions and structures. The introductory material,
writing, and technical level are quite uneven, which makes it
difficult to use. Still, those seriously involved with the data
recovery aspect of digital forensics should consider this work a
valuable resource.
copyright Robert M. Slade, 2005 BKFSFRAN.RVW 20050608
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Mailman can let you subscribe directly:
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.
INFO [for unabridged version of RISKS information]
.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!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> 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.01
************************
This archive was generated by hypermail 2.1.3 : Wed Aug 10 2005 - 12:37:01 PDT