RISKS-LIST: Risks-Forum Digest Tuesday 13 March 2007 Volume 24 : Issue 59
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.59.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Errors down Canada's electronic income tax filing system (Paul Robinson)
Mega Millions Mess (Benjamin Jun)
PG&E sidesteps $38 million bill for daylight-saving patch (Paul Eggert)
FDA - DST and Medical Device Safety (Richard I. Cook)
Countdown to Confusion (Babington/Tse via Monty Solomon)
Insured car wrongly crushed? (Chris Drewe)
Two traffic engineers deny hacking into L.A.'s traffic system (PGN)
Hackers break into Harrisburgh water system network (PGN)
Trailing blank causes e-mail failure (Richard Karpinski)
Date arithmetic before 1900 (John Gilliver)
W2SP: Workshop on Web Security, call for papers (Dan Wallach)
Re: REVIEW: "Code Quality: ..." (Peter Mellor)
REVIEW: "FISMA Certification and Accreditation Handbook", Laura Taylor
(Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 08 Mar 2007 03:39:41 -0500
From: Paul Robinson <Paul@paul-robinson.us>
Subject: Errors down Canada's electronic income tax filing system
An article in the 7 Mar 2007 *Toronto Star* (1) states that due to errors in
the electronic filing system, Canada Revenue Agency will be unable to accept
any tax filings electronically or corrections to prior filings.
The Agency's electronic systems apparently transposed the birth date and the
user's Social Insurance Number (the Canadian equivalent to the U.S. Social
Security Number) and thus corrupted all electronic databases.
A reference to the incident in Slashdot (2) states that no returns - not
even paper ones - can be accepted, "based returns will be stacking up in the
mail room, as returns cannot be filed at all until the problem is fixed."
This could be inferred from the first paragraph of the article in the
*Star*, which reads "a problem with electronic filing is making it
impossible even to submit tax returns to the Canada Revenue Agency."
The remainder of the article in the *Star* says nothing about their system
for accepting paper returns, only about the on-line and telephone systems.
A check of the taxing authority's website(3) regarding the issue states "We
have temporarily shut down public access to electronic services to ensure
the integrity of taxpayer information." and that "We have now traced the
source of the problem to software maintenance conducted on 4 Mar 2007. We
are currently working to bring all systems back online gradually."
A CRA press release dated March 6 (4) states "Commissioner of the Canada
Revenue Agency (CRA) Michel Dorais today instructed some computer
applications related to personal income tax filing to be temporarily
halted."
Mr. Dorais also stated "there is no indication that this situation was
caused by intrusion, hacking, or computer virus", i.e. the agency messed
things up all by their lonesome, they didn't need any help from anyone else.
The press release also says, "These applications include online services
like Efile, Netfile, and My Account. Mr. Dorais said that he instructed that
this preventative measure be taken following indications that CRA computer
systems have run into infrastructure problems. In order to safeguard
existing systems and to maintain the integrity of CRA's taxpayer information
holdings, Mr Dorais ordered tax filing processes halted."
Again, while this may imply that the agency is unable to process all returns
- even ones filed on paper - that is not explicitly stated, e.g. don't get
your hopes up that you'll get away with a long delay in filing, considering
that Canada's tax deadline is April 30, Canadians have even more time than
people here in the U.S.
However, an article in *The Globe and Mail* (5) states that taxpayers "can
wait for Netfile to return to service, or they can print their returns and
mail them to the CRA" which indicates that the paper-based systems are
unaffected.
(1) http://www.thestar.com/News/article/189175
(2) http://it.slashdot.org/article.pl?sid=07/03/08/0417247
(3) http://www.cra-arc.gc.ca/agency/updates/eservices-e.html
(4) http://www.cra-arc.gc.ca/newsroom/releases/2007/march/nr070306-e.html
(5) http://www.theglobeandmail.com/servlet/story/RTGAM.20070307.wtaxes0307/BNStory/Technology/home
[Also noted by Henry Troup, who noted that 17 of 75 databases were
reportedly impacted. PGN]
------------------------------
Date: Wed, 07 Mar 2007 10:02:03 -0800
From: Benjamin Jun <ben@private>
Subject: Mega Millions Mess
A US networked lottery system was overtaxed by demand and had at least two
operational problems:
A record $370M jackpot in the US "Mega Millions" lottery overwhelmed systems
used for tracking lottery purchases and ticket numbers.
http://edition.cnn.com/2007/US/03/07/megamillions.ap/index.html
In one state (Ohio), the purchasing system went down 25 minutes before the
deadline. In another state (California), they could not confirm by the
morning after the draw if there were any winners. Loss of sales revenue is
one problem, but the delays in authentication open opportunities for more
serious fraud.
Benjamin Jun, Vice President of Technology, Cryptography Research, Inc.
[After California results were finally generated, no new winners were
discovered -- leaving the two East-coast winners to split the pot. PGN]
------------------------------
Date: Thu, 01 Mar 2007 16:38:45 -0800
From: Paul Eggert <eggert@private>
Subject: PG&E sidesteps $38 million bill for daylight-saving patch
In the 1 Mar 2007 *InformationWeek* Paul McDougall reports that utility
giant Pacific Gas & Electric says its meters won't work properly on 11 Mar
2007 because of this year's new daylight-saving rules and that reprogramming
them would cost $38 million. The problem is time-of-use billing, where the
end-user rates change depending on time of day.
PG&E has worked around the problem by getting permission from the California
Public Utilities Commission to change the cutover times instead of upgrading
its meters. For example, from 11 Mar through 31 Mar a peak usage period
that would ordinarily end at 6pm will instead end at 5pm to compensate for
the meters being off by an hour.
PG&E announced this workaround in April 2006. Presumably the workaround
will continue through the life of the existing meters.
The workaround encourages power usage in the 5pm-6pm hour. This undermines
a primary justification for the 2007 change to U.S. daylight-saving rules,
which is to conserve electricity by shifting consumption from late afternoon
to early morning.
Here's a reference:
Paul McDougall, "PG&E Says Patching Meters For An Early Daylight-Saving Time
Will Cost $38 Million", InformationWeek 1 Mar 2007
<http://www.informationweek.com/news/showArticle.jhtml?articleID=197700487>
------------------------------
Date: Sat, 03 Mar 2007 10:17:42 -0600
From: "Richard I. Cook" <ri-cook@private>
Subject: FDA - DST and Medical Device Safety
FYI: There are lots of dates in modern medical equipment including DST
changes, leap years, and device dependent dates, e.g. the next required
preventive maintenance. The alert was not issued because of a theoretical
possibility but because of actual user experience. Just when you thought
that Y2K was safely behind you...
Date: Fri, 2 Mar 2007 15:57:45 -0500
From: CDER MEDWATCH LISTSERV
Subject: FDA - MedWatch - Medical Device Safety - Change in Daylight
Savings Time May Affect Medical Equipment in Unpredictable Ways
FDA notified healthcare professionals and consumers of the possibility that
some medical devices/equipment, hospital networks and associated information
technology systems may generate adverse events because of the upcoming
change in the start and end dates for Daylight Savings Time (DST), and
suggested actions to prevent such occurrences. Medical equipment that uses,
creates or records time information about a patient's diagnosis or treatment
and has not been updated by the manufacturer, may not work properly when the
new DST starts three weeks earlier and ends one week later this
year. Medical equipment currently in use was likely made before the DST
rules were changed and may cause patient's equipment to register the wrong
dates for the start and end of daylight savings time this year.
Additionally, if a medical device or medical device network are adversely
affected by the new DST date changes, a patient's treatment or diagnostic
result could be:
* incorrectly prescribed
* provided at the wrong time
* missed
* given more than once
* given for longer or shorter durations than intended
* incorrectly recorded
Related CDRH release: Unpredictable Events in Medical Equipment due to New
Daylight Savings Time Change: http://www.fda.gov/cdrh/safety/030107-dst.html
[Also noted by Paul Eggert:]
http://www.fda.gov/cdrh/medicaldevicesafety/atp/030107-dst.html
------------------------------
Date: Sun, 4 Mar 2007 20:53:13 -0500
From: Monty Solomon <monty@private>
Subject: DST: Countdown to Confusion (Babington/Tse)
Perhaps the worst that will happen in millions of offices on the second
Monday in March is that caffeine-deprived workers will wonder why their
automatic coffeemakers failed to perk on schedule. In less lucky workplaces,
however, employees might miss meetings, overbook conference rooms or
inaccurately record the time or date of important financial transactions.
For the first time in 20 years, daylight saving time will not start on the
first Sunday in April. Instead, it will begin three weeks earlier, at 2
a.m. on the second Sunday in March, the 11th.
Devices from the tiniest BlackBerry to the largest mainframe computer must
be updated to ensure their internal clocks "spring forward" by one hour at
the right moment rather than on the old date, which has been written into
countless programs. Similarly, they must be reprogrammed to revert to
standard time a week later than usual, on Nov. 4. Congress decided in 2005
to expand daylight saving time by four weeks, starting this year, in hopes
of conserving energy by pushing more human activity into sunlit hours. ...
[Source: Charles Babington and Tomoeh Murakami Tse Countdown to Confusion:
Daylight Saving Time Comes Early This Year, But Will Your Computer Know When
to Switch?, *The Washington Post*, 3 Mar 2007]
http://www.washingtonpost.com/wp-dyn/content/article/2007/03/02/AR2007030201346.html
[Marc Sachs mentioned to me that Kerberos-based systems were subject to
failure on 11 March because of a maximum-permitted 10-minute clock
divergence. PGN]
------------------------------
Date: Sat, 24 Feb 2007 22:25:30 +0000
From: Chris Drewe <e767pmk@private>
Subject: Insured car wrongly crushed?
Background: In the UK, motor vehicle details have been stored on the Driver
& Vehicle Licensing Agency (DVLA) computer for decades. This includes a
record that the annual Vehicle Excise Duty ("tax disc") is current. For the
last year or two, the annual vehicle inspection ("MoT test") is captured
on-line as it's done, and insurance companies provide details for a database
of insured vehicles. These allow the police to do real-time road-side
checks on passing traffic. Drivers are not required to carry documents with
them, but the police can require them to be produced ("a producer") at a
police station nominated by the driver within 7 days.
In one case, a car was allegedly towed by police and crushed for having no
insurance, despite having a valid policy. There are questions about this
case, but here are some general comments on the matter from people at the
company where I work:
>> A police statement said: "It is the responsibility of insurance
>> companies, not police forces, to ensure that insurance policy details
>> are updated on the national motor insurance database. When deciding if a
>> car should be towed for insurance or licence violations, officers must
>> show `reasonable belief' that an offence has taken place. "Due to
>> inaccuracies on the motor insurance database officers should not only
>> rely on details held there to constitute `reasonable belief'".
>
> Having been involved in our attempts to keep the motor insurers database
> up to date with details of the company fleet, I can't say I'm surprised
> that it's sometimes out of date. It seems totally ridiculous that the
> police use this as the sole evidence that a vehicle should be towed away.
>
>> Gives you great confidence in the ability of the `authorities' to use
>> databases in he pursuit of their version of justice. Imagine them using a
>> database covering ID cards, they'd be hauling us off instead of cars
>> then....
>
> Can't help wondering why the police impounded the car instead of simply
> issuing a producer. Was there something else dodgy about the car or the
> driver that we weren't told about?
The idea is the computer says no, the journey ends there. The police will
not allow you to continue in an uninsured car.
There was something on one of those `fly on the wall' police programs that
made me wonder. They stopped someone because the computer said the car was
untaxed and uninsured and the driver tried to show them an insurance
certificate. The officers were singularly unimpressed saying anyone with a
computer can knock up a `valid' certificate of insurance preferring to
believe what the database told them. At the end of the program we were
updated and the driver was insured but his tax was 6 weeks out of date.
Looks like the (rather familiar) RISKs here are (a) ambiguity as to what is
regarded as the definitive record -- in this case, computer database or
paper insurance certificate? -- and (b) how individuals can find themselves
in trouble for others' errors and omissions, e.g. if your insurance company
makes a mistake in updating the database. Presumably you could prove in
court that you have a valid policy, but that's not much good if you're
detained by police at the side of the road a long way from home.
------------------------------
Date: Fri, 2 Mar 2007 13:01:52 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Two traffic engineers deny hacking into L.A.'s traffic system
Back in Aug 2006 there was a threat of a strike, which caused Los Angeles
officials to restrict access to traffic-control computers. However,
beginning on 21 Aug 2006, two traffic engineers were able to access those
computers anyway, lengthening the red light cycles on major routes, and
allegedly causing massive traffic tie-ups for several days at different
intersections (LAX Airport, Studio City, the Glendale Freeway, Little Tokyo,
and the L.A. Civic Center). Both men pleaded not guilty to felony charges
on 8 Jan 2007. [Source: Sharon Bernstein and Andrew Blankstein, Los Angeles
Times, 9 Jan 2007; PGN-ed]
http://www.latimes.com/news/local/state/la-me-trafficlights9jan09,1,899433.story?coll=la-news-state
[Clifford Neuman is quoted at the end of the article, saying that there
are two primary ways to design computers to guard against malicious
activity by insiders, but each can interfere with employees' ability to do
their tasks and would probably be prohibitively expensive for the city.]
------------------------------
Date: Wed, 28 Feb 2007 16:11:17 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Hackers break into Harrisburgh water system network
[Marcus H. Sachs sent this to me at the end of October, but it slipped
through the crack. It is never too late for such items to appear in
RISKS, even though some of them may have been overtaken by other events.]
An infected laptop gave hackers access to computer systems at a Harrisburg,
Pennsylvania, water treatment plant. The plant's systems were accessed in
early October 2006 after an employee's laptop computer was compromised via
the Internet (apparently from abroad), and then used as an entry point to
install a computer virus and spyware on the plant's computer system. The
FBI was investigating. The motive appears to have been the use of the
laptop as a zombie, rather than an attempt to subvert the water system.
However, more serious risks are obvious. [Source: Robert McMillan, Hackers
break into water system network, IDG News Service, 31 Oct 2006; PGN-ed]
http://www.networkworld.com/news/2006/110106-hackers-break-into-water-system.html
------------------------------
Date: Thu, 1 Mar 2007 22:27:53 -0800
From: Richard Karpinski <dick@private>
Subject: Trailing blank causes e-mail failure
When a system of components is under disparate control like the Internet, it
only works reliably when everybody plays by the rules. E-Mail behavior is
specified in rfc2822 and related documents maintained by the IETF. While I
can't find it clearly in that document, the general rule is that you should
be liberal in what you accept and strict in what you generate.
Here I report on an e-mail address which fails because of a trailing
blank. Notice that it can be difficult to see a blank by the naked eye when
it is followed by white space. It should not be there. There should be no
space after .COM or .NET in an e-mail address. Still, many e-mail programs
make it easy to put one there by mistake. In this case, the Apple Macintosh
OS X application Mail happily uses such an address and passes the blank
along.
No matter; the next recipient will trim it off and there will be no
problem. In my case, the e-mail went to the ISP supported by what used to be
Pacific Bell, which became SBC and then became AT&T by further corporate
manipulations. They use Yahoo to provide outgoing e-mail service for their
DSL customers. Yahoo, too, apparently passes the trailing blank along,
presumably to a Domain Name Server. No matter. The DNS will trim off the
blank and all will be well.
But no. MAILER-DAEMON@private says:
Sorry, I couldn't find any host named bzwebtech.com?. (#5.1.2)
And the mail is returned to the sender.
Perhaps the DNS is actually OK; I can't tell from the messages I get.
Still, I believe that at least Mail and Yahoo are not really playing by the
rules.
Now a nitpicker is fully equipped to track such a problem down, at least to
the point of discovering the unwanted blank, but other e-mail users may not
have the resources and may simply assume that the part to the left of the
.COM is in error and give up entirely on reaching that company or
person. Too bad, since that introduces unnecessary friction and loss in a
vital facility.
Surely Apple and Yahoo are wrong in their treatment of a problem originally
caused by my own mistake. If the DNS is also wrong, then we may have more to
worry about than I knew. The problem is exacerbated by the lack of any
convenient way to report problems to any of those entities.
Richard Karpinski, World Class Nitpicker, 148 Sequoia Circle, Santa Rosa,
CA 95401 dick@private Home +1 707-546-6760 Cell +1 707-228-9716
------------------------------
Date: Thu, 1 Mar 2007 19:31:40 -0000
From: "Gilliver, John \(UK\)" <John.Gilliver@private>
Subject: Date arithmetic before 1900 (Re: Excel, Levine, RISKS-24.57)
> less common to do date arithmetic, and I've never seen anyone doing date
> arithmetic as far back as 1900.
Genealogists -- or the software they use -- does it a lot; the one I use
(Brother's Keeper -- somewhat clunky by today's standards, but I have a *lot*
of records in it and am not translating it all now! It also is excellent at
encouraging you to record *source* and *quality* data for all your data),
for example, shows the age of anyone it can (by subtracting birth from death
if both are recorded, otherwise birth from today -- and no I don't know what
cutoff it imposes). It may do other date calculations too. OK, for giving
ages in years, this only has a 1 in (about) 365 chance of giving the wrong
answer if there's a day funny around 1900, but I just thought I'd mention it
as something which regularly does date calculations "as far back as" 1900.
------------------------------
Date: Fri, 9 Mar 2007 11:08:26 -0800
From: "Dan Wallach" <dwallach@private>
Subject: W2SP: Workshop on Web Security, call for papers
Larry Koved and I are co-chairing a workshop on 24 May 2007 on web security
(W2SP) that will be co-located with and following the IEEE Symposium on
Security & Privacy in Oakland, CA. We're asking for one-page position
papers, and our hope is to attract more industrial participation than you'd
otherwise get at an academic conference.
The goal is to bring together researchers and practitioners from academia
and industry to focus on understanding Web 2.0 security and privacy
issues, and establishing new collaborations in these areas.
Position papers are due March 23.
Here's the full CFP:
http://www.ieee-security.org/Calendar/cfps/cfp-W2SP.html
------------------------------
Date: Fri, 9 Mar 2007 14:12:40 EST
From: MellorPeter@private
Subject: Re: REVIEW: "Code Quality: ..." (Slade, RISKS-24.57)
Review by Rob Slade <rMslade@private> of "Code Quality:
The Open Source Perspective", Spinellis.
> 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. [...]
> 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.
ISO/IEC 9126 has now been superseded by a set of standards referred to as
SQuaRE, but the new standards are still flawed, in the same way that 9126
was (and are direct derivatives of it).
The problem arose back in 1992 when the joint technical committee (JTC1) set
up to ensure compatibility between ISO (International Standards
Organisation) and IEC (International Electrotechnical Commission) took on a
life of its own and began to write standards without reference to either of
its parent bodies.
In particular, ISO/IEC JTC1/SC7/WG6 began to draft standards (the ISO/IEC
9126 series) on "software quality" in which it misused terms defined by
IEC/TC56 (Technical Committee 56: Dependability). In particular, terms such
as "reliability", "availability" and "maintaintability" were defined as
"subcharacteristics" of "software quality" without any regard to the
standard definitions of these terms in the field of system dependability.
(At the time, the working group responsible had not even heard of the
standard definitions as stated in IEC 60050 (191): International
Electrotechnical Vocabulary Section 191: Dependability and Quality of
Service.)
I would advise anyone who is interested in the dependability of systems
(i.e., their reliability, availability and maintainability as correctly
defined) to take anything emanating from ISO/IEC JTC1/SC7 (Joint Technical
Committee 1, committee on "Software Quality") with a very large pinch of
salt.
Peter Mellor (UK Principal Expert on Dependability Terminology,
IEC/TC56/WG1: Working Group 1, Definitions of Terms.) +44 (0)20 8459 7669
------------------------------
Date: Fri, 09 Mar 2007 11:56:32 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "FISMA Certification and Accreditation Handbook", Laura Taylor
BKFISMAC.RVW 20070113
"FISMA Certification and Accreditation Handbook", Laura Taylor, 2007,
1-59749-116-0, U$69.95/C$90.95
%A Laura Taylor
%C 800 Hingham Street, Rockland, MA 02370
%D 2007
%G 1-59749-116-0 978-1-59749-116-7
%I Syngress Media, Inc.
%O U$69.95/C$90.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597491160/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597491160/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597491160/robsladesin03-20
%O Audience a- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 498 p.
%T "FISMA Certification and Accreditation Handbook"
The United States' Federal Information Systems Management Act mandates
certain standards of information security and controls for US federal
agencies. It extends to contractors and other sources that support the
assets of federal government departments. However, it may have wider
application yet, since it provides a solid basis for security management,
assessment, and assurance for large corporations as well.
Chapter one looks at definitions of various terms surrounding security and
controls. It is interesting to note that to the usual certification
(assessment) and accreditation (acceptance) phases the feds add an
audit/evaluation phase between the two. The National Information Assurance
Certification and Accreditation Process (NIACAP), National Institute of
Standards and Technology outline, Defense Information Technology Systems
Certification and Accreditation Process (DITSCAP), and Director of Central
Intelligence Directive 6/3 (DCID 6/3), all directions on how to follow
FISMA, are briefly compared in chapter two. A list of job descriptions, and
a brief outline of general project management steps makes up chapter three.
Chapter four examines components of a certification and accreditation
program, mostly in terms of documentation. Chapter five returns to project
management, with a quick look at the initiation phase. An even shorter
mention of creating a hardware and software inventory is in chapter six.
Chapter seven is nominally about determining the proper level for
certification (which is, again, primarily related to the number of documents
produced), but turns into an interesting and valuable outline of information
classification. Much of chapter eight, on self-assessment, is a reprinting
of the NIST 800-26 guideline on that topic. Security awareness and training
is touched on briefly in chapter nine. Chapter ten, on rules of behaviour,
is a terse mix of acceptable use and incident response, but it leads rather
nicely into the longer examination of incident response in chapter eleven.
Chapter twelve lists various types of assessment tools, such as
vulnerability scanners and code analyzers. I found the privacy impact
assessment, in chapter thirteen, to be an interesting perspective. Chapter
fourteen's material on business risk assessment is concise but reasonable.
Business impact assessment, in fifteen, is not quite as good, since it
neglects the analysis of criticality of operations. Contingency planning is
outlined well in chapter sixteen. Chapter seventeen takes a brief look at
risk assessment, but manages to hit all the high points. Change management
is reviewed in chapter eighteen. An overview system security plan document
is described in chapter nineteen. The certification package is detailed
from the perspective of those submitting it (in chapter twenty) and those
evaluating or auditing it (chapter twenty-one). Preparation of a plan to
correct residual weaknesses is addressed in chapter twenty-two. Chapter
twenty-three looks at improving the standings and grading on a Federal
Computer Security Report Card.
There is much that is useful and helpful in this book, both in terms of
general information security management structure and process, and in terms
of references for those involved with FISMA related programs. However, for
those who are new to the operation of US government certification and
accreditation, the basic requirements, and the relation of the ancillary
programs to FISMA itself, could have been more fully explained.
copyright Robert M. Slade, 2007 BKFISMAC.RVW 20070113
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 for current volume
or ftp://ftp.sri.com/VL/risks for previous VoLume
<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.59
************************
This archive was generated by hypermail 2.1.3 : Tue Mar 13 2007 - 16:13:24 PST